このセクションでは、バイナリログを使用してポイントインタイムリカバリを実行する一般的な概念について説明します。 次のセクション セクション7.5.2「イベントの位置を使用したポイントインタイムリカバリ」 では、操作の詳細を例とともに説明します。

point-in-time リカバリの情報のソースは、全体バックアップ操作の後に生成されるバイナリログファイルのセットです。 したがって、サーバーを point-in-time にリストアできるようにするには、MySQL 8.0 のデフォルト設定であるバイナリロギングを有効にする必要があります (セクション5.4.4「バイナリログ」 を参照してください)。

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

mysql> SHOW BINARY LOGS;

現在のバイナリログファイルの名前を判断するには、次のステートメントを発行します。

mysql> SHOW MASTER STATUS;

mysqlbinlog ユーティリティーは、バイナリログファイル内のイベントをバイナリ形式からテキストに変換して、それらを表示または適用できるようにします。mysqlbinlog には、イベント時間またはログ内のイベントの位置に基づいてバイナリログのセクションを選択するためのオプションがあります。 セクション4.6.8「mysqlbinlog — バイナリログファイルを処理するためのユーティリティー」を参照してください。

バイナリログからイベントを適用すると、それらが表すデータ変更が再実行されます。 これにより、特定の期間のデータの変更のリカバリが可能です。 バイナリログからイベントを適用するには、mysql クライアントを使用して mysqlbinlog 出力を処理します:

shell> mysqlbinlog binlog_files | mysql -u root -p

バイナリログファイルが暗号化されている場合 (MySQL 8.0.14 以降で実行可能)、mysqlbinlog は前述の例のようにそれらを直接読み取ることはできませんが、--read-from-remote-server (-R) オプションを使用してサーバーから読み取ることはできます。 例:

shell> mysqlbinlog --read-from-remote-server --host=host_name --port=3306  --user=root --password --ssl-mode=required  binlog_files | mysql -u root -p

ここでは、バイナリログファイルのデータが暗号化されていない形式で mysqlbinlog に送信されるため、バイナリログファイルのデータが転送中に保護されるように --ssl-mode=required オプションが使用されています。

ログの内容を表示すると、イベントを実行する前に、イベントの時間や位置を特定して、ログの内容の一部を選択する必要がある場合に役立つことがあります。 ログからイベントを表示するには、mysqlbinlog 出力をページングプログラムに送信します。

shell> mysqlbinlog binlog_files | more

または、出力をファイルに保存し、テキストエディタでファイルを表示します。

shell> mysqlbinlog binlog_files > tmpfile
shell> ... edit tmpfile ...

出力をファイルに保存すると、誤った DROP TABLE などの特定のイベントを削除してログの内容を実行するための予備として役立ちます。 ファイルの内容を実行する前に、実行されないステートメントをファイルから削除できます。 ファイルを編集した後、次のように内容を適用します:

shell> mysql -u root -p < tmpfile

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

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 プロセスでテーブルの使用を試みると、サーバーは「不明なテーブル」と報告します。

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

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

別の方法として、ログ全体を単一のファイルに書き込み、そのファイルを処理する方法があります:

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"