このページは機械翻訳したものです。

7.3.1 バックアップポリシーの確立

役に立つように、バックアップは定期的にスケジュールする必要があります。 完全バックアップ (特定の時点でのデータのスナップショット) は、MySQL でいくつかのツールを使用して実行できます。 たとえば、MySQL Enterprise Backup は、InnoDB データファイルのバックアップ時にオーバーヘッドを最小にし、中断を防ぐ最適化を伴うインスタンス全体の物理バックアップを実行できます。mysqldump はオンライン論理バックアップを提供します。 この説明では mysqldump を使用します。

負荷が少ない日曜日の午後 1 時に、次のコマンドを使用して、すべてのデータベースのすべての InnoDB テーブルの完全バックアップを作成するとします。

shell> mysqldump --all-databases --master-data --single-transaction > backup_sunday_1_PM.sql

mysqldump によって生成される結果の .sql ファイルには、あとでダンプしたテーブルのリロードに使用できる SQL INSERT ステートメントのセットが含まれます。

このバックアップ操作では、ダンプの最初ですべてのテーブルに対するグローバル読み取りロックを取得します (FLUSH TABLES WITH READ LOCK を使用して)。 このロックが取得されるとすぐに、バイナリログの座標が読み取られ、ロックが解除されます。 FLUSH ステートメントが発行されたときに長い更新ステートメントが実行中の場合、バックアップ操作はそれらのステートメントが終了するまで停止する可能性があります。 その後、ダンプはロックフリーとなり、テーブルの読み取りと書き込みを妨げません。

先に、バックアップするテーブルは InnoDB テーブルであるとしたため、--single-transaction は、一貫性読み取りを使用し、mysqldump によって表示されたデータが変更されないことを保証します。 (ほかのクライアントによる InnoDB テーブルへの変更は、mysqldump プロセスによって表示されません)。 バックアップ操作に非トランザクションテーブルが含まれる場合、一貫性には、バックアップ中にそれらが変更されない必要があります。 たとえば、mysql データベース内の MyISAM テーブルの場合、バックアップ中に、MySQL アカウントへの管理上の変更があってはなりません。

完全バックアップが必要ですが、それらを作成するために常に都合がよいとは限りません。 それらは大きなバックアップファイルを生成し、生成に時間がかかります。 それらは、連続した各完全バックアップに、前回の完全バックアップから変更されていない部分でもすべてのデータが含まれるという点で、最適ではありません。 初期完全バックアップを作成し、次に増分バックアップを作成するほうが効率的です。 増分バックアップは小さく、生成にかかる時間が少なくなります。 このトレードオフは、リカバリ時に、完全バックアップをリロードするだけではデータをリストアできないことです。 増分バックアップを処理して、増分の変更もリカバリする必要があります。

増分バックアップを作成するには、増分の変更を保存する必要があります。 MySQL では、これらの変更はバイナリログで表されるため、MySQL サーバーを常に --log-bin オプションで起動して、そのログを有効にしてください。 バイナリロギングが有効にされていると、サーバーはデータの更新中に、各データの変更をファイルに書き込みます。 数日間実行されている MySQL サーバーのデータディレクトリを調べると、次の MySQL バイナリログファイルが見つかります:

-rw-rw---- 1 guilhem  guilhem   1277324 Nov 10 23:59 gbichot2-bin.000001
-rw-rw---- 1 guilhem  guilhem         4 Nov 10 23:59 gbichot2-bin.000002
-rw-rw---- 1 guilhem  guilhem        79 Nov 11 11:06 gbichot2-bin.000003
-rw-rw---- 1 guilhem  guilhem       508 Nov 11 11:08 gbichot2-bin.000004
-rw-rw---- 1 guilhem  guilhem 220047446 Nov 12 16:47 gbichot2-bin.000005
-rw-rw---- 1 guilhem  guilhem    998412 Nov 14 10:08 gbichot2-bin.000006
-rw-rw---- 1 guilhem  guilhem       361 Nov 14 10:07 gbichot2-bin.index

MySQL サーバーは再起動するたびに、シーケンスの次の番号を使用して、新しいバイナリログファイルを作成します。 サーバーが実行している間、FLUSH LOGS SQL ステートメントを発行するか、mysqladmin flush-logs コマンドによって、手動で、それに現在のバイナリログファイルをクローズし、新しいファイルを開始するように伝えることもできます。mysqldump にはログをフラッシュするオプションもあります。 データディレクトリ内の .index ファイルには、ディレクトリ内のすべての MySQL バイナリログのリストが含まれます。

MySQL バイナリログは、増分バックアップのセットを形成するため、リカバリに重要です。 完全バックアップの作成時にログをフラッシュさせる場合、その後作成されるバイナリログファイルには、バックアップ以降に行われたすべてのデータの変更が含まれます。 ここで、前述の mysqldump コマンドを少し修正して、完全バックアップの時点で MySQL バイナリログをフラッシュするようにし、ダンプファイルに新しい現在のバイナリログの名前が含まれるようにします。

shell> mysqldump --single-transaction --flush-logs --master-data=2 \
         --all-databases > backup_sunday_1_PM.sql

このコマンドの実行後、--flush-logs オプションによって、サーバーにそのログをフラッシュさせるため、データディレクトリには新しいバイナリログファイル gbichot2-bin.000007 が格納されます。 --master-data オプションは mysqldump でその出力にバイナリログ情報を書き込ませるため、結果の .sql ダンプファイルにはこれらの行が含まれます。

-- Position to start replication or point-in-time recovery from
-- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;

mysqldump コマンドで完全バックアップを作成しているため、これらの行は 2 つのことを意味します。

• ダンプファイルには、gbichot2-bin.000007 バイナリログファイル以上に書き込まれた変更の前に行われたすべての変更が含まれます。

• バックアップ後に記録されたすべてのデータ変更はダンプファイルには存在しませんが、gbichot2-bin.000007 バイナリログファイル以上に存在します。

月曜日の午後 1 時に、ログをフラッシュし、新しいバイナリログファイルを開始することによって、増分バックアップを作成できます。 たとえば、mysqladmin flush-logs コマンドを実行すると、gbichot2-bin.000008 が作成されます。 日曜日の午後 1 時から月曜日の午後 1 時までのすべての変更は、gbichot2-bin.000007 に書き込まれます。 この増分バックアップは重要であるため、それを安全な場所にコピーすることをお勧めします。 (たとえば、それをテープや DVD にバックアップするか、別のマシンにコピーします。) 火曜日の午後 1 時に、さらに mysqladmin flush-logs コマンドを実行します。 月曜日の午後 1 時から火曜日の午後 1 時までのすべての変更は、gbichot2-bin.000008 で書き込まれます (これも安全な場所にコピーする必要があります)。

MySQL バイナリログはディスク領域を占有します。 領域を解放するため、ときどきそれらをパージします。 これを実行する 1 つの方法は、完全バックアップを作成したときなど、必要なくなったバイナリログを削除することです。

shell> mysqldump --single-transaction --flush-logs --master-data=2 \
         --all-databases --delete-master-logs > backup_sunday_1_PM.sql

注記

サーバーがレプリケーションソースサーバーである場合、レプリカがまだバイナリログの内容を完全に処理していない可能性があるため、mysqldump --delete-master-logs で MySQL バイナリログを削除すると危険になる可能性があります。 PURGE BINARY LOGS ステートメントの説明では、MySQL バイナリログを削除する前に確認すべきことを説明しています。 セクション13.4.1.1「PURGE BINARY LOGS ステートメント」を参照してください。