☰

mysql、個々のデータベースの再配置とデータディレクトリ全体の再配置

tag-icon • tag-icon mysql data-recovery database-administration database-backup
mysql、個々のデータベースの再配置とデータディレクトリ全体の再配置

次の目的のため、mysql 顧客データベースを別のディスクに再配置する必要があります。

 1. Separation of user data from system files
 2. Ease of backing up system and user data separately
 3. Ease of upgrading the system

以下の記事が役に立ちました:

  [how-to-move-mysql-datadir-to-another-drive][1]
  [move-a-mysql-database-to-another-location][2]

ubuntu-18 システムで実行している場合、innodb_file_per_table 変数がデフォルトで設定されているようです。

mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_%';
...
| innodb_file_per_table                    | ON 
...

(GLOBALなしでも同じ結果)

見つからないどれでもあらゆる設定ファイルにおけるinnodb_file_per_tableへの参照。内容が豊富なファイルは

  /etc/mysql/mysql.conf.d/mysqld.cnf

ファイルに何が保存されているのか心配です

  /var/lib/mysql/ibdata1
                /ib_logfileN

データベースにアクセスするだけでこれらが更新されることに気付きました。

私の質問は次のとおりです:

  1. 顧客データベースのみを（別のディスクに）移動し、システム ディスクが失われて最初から再作成する必要がある場合、何かが失われますか?

  2. (mysql、performance_schema、sys) を含むすべてのデータベースを別のディスクに移動したほうがよいでしょうか?

  3. データ ディレクトリ全体を別のディスクに移動し、/etc/mysql/mysql.conf.d/mysqld.cnf の「datadir」変数を介してそれを指定する方がよいでしょうか?

  4. どのような影響があるのでしょうかないシステム ディスクが失われた場合、オプション 3 を使用しますか?

答え1

MySQL のすべてのテーブルを別のディスクに移動するのが最善です。「顧客」を分割しようとすると、複雑さが増し、目標の達成が難しくなります。(それが要件になった場合は、さらに話し合うことができます。)

基本的に、このような移動によって残されるファイルは設定ファイルのみです。 とおっしゃいました/etc/mysql/mysql.conf.d/mysqld.cnfが、他にも設定ファイルがある可能性があります。

別の場所には、多数のファイルと、作成した「データベース」に対応するサブディレクトリを含む、より大きなディレクトリがあります。そのツリー全体を移動するだけです。Linux ベースの OS を使用している場合は、古い場所から新しい場所へのシンボリック リンクを使用します。明示的な構成変更は必要ありません。

そうすると、どちらかのディスクがクラッシュすると、データにアクセスできなくなります。私が言いたいのは、ファイルやディレクトリをいじっても、必ずしも「セキュリティ」に近づくわけではないということです。

代わりに、バックアップや「レプリケーション」に重点を置きましょう。後者には追加のサーバデータの完全なコピーが提供されます。どちらかのサーバーがクラッシュしても、何も失われません。

LVM は別のバックアップ手法であり、データベース用のディスクを持つことでメリットを得られます。ただし、これにより複雑さが増します。

もう少し読んで、心を開いてみてください。あなたの考えとぴったり一致するものがたくさん見つかるでしょう。

関連情報