mysqlbinlogリカバリテーブルワイズ
ログファイルを使用してMySQLデータベーステーブルを復元します。私のデータベース名は「decsys」です。
私はすでにログファイルを使用してSQLを作成しました
C:\wamp\bin\mysql\mysql5.5.8\bin>mysqlbinlog -d decsys C:\wamp\bin\mysql\mysql5.5.8\data\mysql-bin.0000xx > sql1.sql (file size 8GB)
データベース全体ではなく、単一のテーブルのみをリカバリしたい。 （テーブル名：cm）。
最もエラーのないアプローチは、バックアップ（ダンプ）ファイルをロードして適切なログを再生することにより、すべてのデータベース（サーバー全体）を別のマシンに復元することです。ダンプが開始されたbinlog座標から開始し、次にmysqldumpを使用して対象の1つのテーブルを抽出し、目的の宛先にコピーします。
いずれにせよ、最初にバックアップから何かを復元する必要があります。これは理解していると思いますが、言及していません。バイナリログを再生すると、復元されたバックアップからログの終わりまでの間に発生したイベントをキャプチャできます。
単一のテーブルの行イベントの再生は、私の知る限り、サポートされていません。ただし、この方法で単一のデータベース（スキーマ）を復元する場合でも、複雑な操作になります。
--databaseまたは-dmysqlbinlogのオプションは、ログエントリを作成したサーバーのbinlog_formatがに設定されている場合にのみ、十分な精度で目的のデータベースを明確に識別できます。 ROW、またはlog_slave_updatesが有効になっているレプリカによってbinlogが生成された場合、最後のサーバーを含むカスケード内のサーバーの少なくとも1つでbinlog_formatがROWに設定されました。これにより、レプリケーションイベントがROW形式に強制変換されます。これは一方向のプロセスです。
イベントがROW形式でログに記録されなかった場合、サーバー上の他のすべてのデータも存在しない限り、バイナリログの再生が正しく機能することは保証されません。 ROWステートメントとの相互作用やその他の複雑な方法のため、--databaseまたは-dオプションがUSE形式でログに記録されていない場合、すべてのステートメントをキャッチすることを確認することもできません。 MySQLはレプリケーションイベントを解釈します。
これは、mysqlbinlogが壊れていることを意味するのではなく、レプリケーションの動作方法の制約内でのみ使用できる高度なツールであることを意味します。
バイナリログ形式は、あるサーバーから別のサーバーに変更を複製するために設計されており、問題の2つのサーバーが同じデータセットで始まる場合にそれを行うのに十分な情報のみが含まれています。したがって、バックアップからの復元への参照です。
また、本番システムにバイナリログを再生することは、本番システムがひどく損傷していて、バックアップから完全にリロードして再生したい場合を除いて、実際にはやりたくないことです。失われるデータの量を最小限に抑えるために利用可能なログ。