時点に基づくMySQLクイックリカバリソリューション

なぜこのような記事を書いたかというと、数日前の夜、仕事が終わろうとしていたときに、業務側で突然、テーブル内のデータを復元する要求が出たからです。 当時の状況を聞いてみると、大体次のような感じでした。業務側が誤ってテーブル内で更新操作を実行しました。 where 条件が正しく記述されていなかったため、テーブル内のデータが破損していました。 ただし、データはまだディスクに書き込まれておらず、メモリ内の値のみが変更されており、以前のデータに復元する必要があります。幸いなことに、このデータはプラットフォーム上の特定の商品の価格です。基本的に、商品の数は限られており、価格の値はすべて固定されています。この価格表は以前にバックアップされていたため、新しい価格表のコピーのデータが直接インポートされ、この問題が解決されました。

その時、バックアップがなく、binlog しかない場合、この問題を回復する必要があるとしたら、もっと良い方法はないだろうかと考えていました。新しいインスタンスを作成し、データベース全体を復元してから、バックアップされたバイナリログを適用し、データが破損した時点まで遡ります。

トランザクションを再生するには、mysqlbinlog ツールを使用します。この方法には、次のような多くの落とし穴があります。

1. 一度に 1 つの binlog ファイルを再生するには、一度に 1 つの mysqlbinlog コマンドのみ実行できます。再生時に一時テーブルが生成され、競合や障害が発生するため、複数のコマンドを並行して実行することはできません。

2. これはアトミック操作です。実行の途中で失敗した場合、どこで失敗したかを把握し、以前の時点から再開することが困難になります。失敗の理由は多数あります。同時トランザクションによる Innodb ロック待機タイムアウト、サーバーとクライアントの max_allowed_pa​​cket 設定の違い、クエリ中の MySQL サーバーとの接続の喪失などです。

そこで、Percona さんのブログをパラパラと見て、方法を見つけ、エッセンスを読んで、ざっくりと記録しました。この方法はまだ自分では実装していませんが、ここに記録しておきました。今後時間ができたら、自分で試して、この問題をより効率的に解決できるかどうか確認してみます。

一般的な考え方は次のとおりです。

2 台の追加のマシン。1 台目はバックアップ結果データを復元するために使用され、もう 1 台は元のマスターの binlog をインスタンスにコピーして元のマスターをシミュレートするために使用されます。次に、1 台目のマシンと 2 台目のマシンはマスターとスレーブの関係を確立し、マスターを 2 台目のマシンに変更し、バックアップ結果 (xtrabackup_binlog_info の binlog 名と pos) を配置し、エラー操作ポイントに同期し、復元されたテーブルをエクスポートして、本番の元のマスターに復元します。

具体的な手順は次のとおりです。

1. インスタンスの最新のバックアップ結果データをバックアップおよび復元するためのマシンを準備します。

2. 別のマシン (新しいインスタンス) を準備し、元のマスターの binlog ファイルをインスタンスのデータ ディレクトリにコピーし、空のインスタンスを起動します (server-id は元のマスターと同じ、--log_bin=master-bin binlog ファイル名は元のマスターと同じままです)。次に、インスタンスを停止し、自動的に作成されたすべての binlog を削除し、必要なすべての binlog (元の運用インスタンスから) を解凍してデータ ディレクトリにコピーし、再起動します。

最新のバックアップデータの場所:

起動が正常であれば、MySQL に接続して binlog 関連情報を表示します。

3. 同期関係を確立し、誤った操作の位置の前で停止する

 マスターを変更 

MASTER_HOST='127.0.0.1',

マスターポート=3307、

MASTER_USER='root'、

MASTER_PASSWORD='秘密',

MASTER_LOG_FILE='master-bin.000007'、MASTER_LOG_POS=1518932;

スレーブを開始するまで 

MASTER_LOG_FILE = 'ログ名'、 

MASTER_LOG_POS = ログ位置

または

スレーブSQL_THREADを開始する

 SQL_AFTER_GTIDS =

 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56

スレーブステータスを表示します。

これは、インスタンスを 1 つ追加するのと同じであり、バイナリ ログの使用率とバイナリ ログの使用成功率が向上します。この方法が実行可能かどうかはまだ検証されていません。記事で著者が説明したアイデアによると、この方法は、binlog を単一のインスタンスに適用する方法よりも優れています。binlog を適用するプロセスでエラーが発生すると、エラーが発生したポイントをすぐに特定できるため、問題を迅速に解決するのに役立ちます。

上記は、MySQL の時間ベースのクイックリカバリソリューションの詳細です。MySQL クイックリカバリの詳細については、123WORDPRESS.COM の他の関連記事に注目してください。