MySQL :: MySQL 5.6 リファレンスマニュアル :: 7.5 バイナリログを使用したポイントインタイム (増分) リカバリ

MySQL 5.6 リファレンスマニュアル / バックアップとリカバリ / バイナリログを使用したポイントインタイム (増分) リカバリ

7.5 バイナリログを使用したポイントインタイム (増分) リカバリ

7.5.1 イベント時間を使用したポイントインタイムリカバリ
7.5.2 イベントの位置を使用したポイントインタイムリカバリ

ポイントインタイムリカバリは、特定の時点以降に行われたデータ変更のリカバリを表します。一般に、この種類のリカバリは、サーバーをバックアップが行われた時点の状態にする完全バックアップのリストア後に実行されます。(完全バックアップは、セクション7.2「データベースバックアップ方法」に示すものなど、いくつかの方法で行うことができます。)さらに、ポイントインタイムリカバリは、完全バックアップの時点からより最近の時点まで、増分的にサーバーを最新にします。

ポイントインタイムリカバリは、これらの原則に基づきます。

ポイントインタイムリカバリの情報のソースは、完全バックアップ操作のあとに生成されたバイナリログファイルによって表される一連の増分バックアップです。そのため、サーバーを --log-bin オプションで起動して、バイナリロギングを有効にする必要があります (セクション5.2.4「バイナリログ」を参照してください)。

バイナリログからデータをリストアするには、現在のバイナリログファイルの名前と場所を知っている必要があります。デフォルトで、サーバーはデータディレクトリにバイナリログファイルを作成しますが、--log-bin オプションでパス名を指定して、別の場所にファイルを配置できます。セクション5.2.4「バイナリログ」。

すべてのバイナリログファイルのリストを表示するには、次のステートメントを使用します。
```
mysql> SHOW BINARY LOGS;
```
現在のバイナリログファイルの名前を判断するには、次のステートメントを発行します。
```
mysql> SHOW MASTER STATUS;
```
mysqlbinlog ユーティリティーは、バイナリログファイル内のイベントを、実行したり、表示したりできるように、バイナリフォーマットからテキストに変換します。mysqlbinlog には、イベント時間やログ内のイベントの位置に基づいて、バイナリログのセクションを選択するためのオプションがあります。セクション4.6.8「mysqlbinlog — バイナリログファイルを処理するためのユーティリティー」を参照してください。
バイナリログからイベントを実行すると、それらが表すデータの変更が再実行されます。これにより、特定の期間のデータの変更のリカバリが可能です。バイナリログからイベントを実行するには、mysql クライアントを使用して、mysqlbinlog 出力を処理します。
```
shell> mysqlbinlog binlog_files | mysql -u root -p
```
ログの内容を表示すると、イベントを実行する前に、イベントの時間や位置を特定して、ログの内容の一部を選択する必要がある場合に役立つことがあります。ログからイベントを表示するには、mysqlbinlog 出力をページングプログラムに送信します。
```
shell> mysqlbinlog binlog_files | more
```
または、出力をファイルに保存し、テキストエディタでファイルを表示します。
```
shell> mysqlbinlog binlog_files > tmpfile
shell> ... edit tmpfile ...
```
ファイルに出力を保存することは、予期しない DROP DATABASE など、特定のイベントが削除されたログの内容を実行する場合の予備として役立ちます。ファイルの内容を実行する前に、実行されないステートメントをファイルから削除できます。ファイルの編集後、次のように内容を実行します。
```
shell> mysql -u root -p < tmpfile
```

MySQL サーバーに実行する複数のバイナリログがある場合、安全な方法は、サーバーへの 1 つの接続を使用して、それらすべてを処理することです。これは、安全でない可能性があることを示す例です。

shell> mysqlbinlog binlog.000001 | mysql -u root -p # DANGER!!
shell> mysqlbinlog binlog.000002 | mysql -u root -p # DANGER!!

最初のログファイルに CREATE TEMPORARY TABLE ステートメントが含まれており、2 番目のログに一時テーブルを使用するステートメントが含まれている場合、サーバーへの異なる接続を使用して、このようにバイナリログを処理すると問題が発生します。最初の mysql プロセスが終了すると、サーバーは一時テーブルを削除します。2 番目の mysql プロセスでテーブルの使用を試みると、サーバーは「不明なテーブル」と報告します。

このような問題を回避するには、1 つの接続を使用して、処理するすべてのバイナリログの内容を実行します。これはそれを実行する 1 つの方法です。

shell> mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p

もう 1 つのアプローチは、すべてのログを 1 つのファイルに書き込み、次にそのファイルを処理することです。

shell> mysqlbinlog binlog.000001 >  /tmp/statements.sql
shell> mysqlbinlog binlog.000002 >> /tmp/statements.sql
shell> mysql -u root -p -e "source /tmp/statements.sql"

GTID (セクション17.1.3「グローバルトランザクション識別子を使用したレプリケーション」を参照) を含むバイナリログから読み取りながら、ダンプファイルに書き込む場合、次のように、mysqlbinlog で --skip-gtids オプションを使用します。

shell> mysqlbinlog --skip-gtids binlog.000001 >  /tmp/dump.sql
shell> mysqlbinlog --skip-gtids binlog.000002 >> /tmp/dump.sql
shell> mysql -u root -p -e "source /tmp/dump.sql"

PREV HOME UP NEXT