MySQL のバックアップとリカバリの設計アイデア

背景

まず、背景を説明します。ある制約により、当社の現在のバックアップ戦略では、1 日おきにフル バックアップ ソリューションを採用し、増分バックアップは binlog サーバー方式を使用しています。そのため、いかに迅速に復元するかが、検討すべき問題となります。

回復のニーズ

私のこれまでの経験によると、バックアップからデータを復元する必要があるシナリオは通常、次のとおりです。

1. ライブラリが誤って削除されました

2. テーブルが誤って削除されました。タイプは TRUNCATE または DROP です。

3. 列が誤って削除されました。タイプは ALTER ... DROP COLUMN です。

4. データが誤って削除されました。タイプは DELETE、UPDATE、または REPLACE です。

5. テーブルスペースが破損しているか、不良ブロックが発生している

シナリオに応じて、大まかに 2 つのカテゴリに分けることができます。

• 最初のタイプは不可逆的な回復であり、これは上記の1、2、3、5などのシナリオなどの通常のDDLです。
• 2 番目のタイプは可逆リカバリであり、通常は binlog を使用してロールバックできます (binlog 形式が ROW で、binlog_image が FULL である必要があります)。これは上記のシナリオ 4 に相当します。
  

2 番目のタイプのリカバリ要件は、一般的に扱いやすいものです。業界でよく知られている binlog2sql や MyFlash などの binlog ロールバック ツールを使用できます。ここでは詳細には触れず、最初のタイプの要件に焦点を当てます。

迅速な復旧という目標を達成するために、業界の DBA が頻繁に採用するアプローチは、遅延スレーブ データベースを導入して問題を解決することです。現在、当社のすべてのコア DB には遅延スレーブ データベースが導入されています。しかし、遅延スレーブであっても、遅延時間を逃したり、後で回復するために遅延スレーブを使用するときに間違った場所を指定したりして、誤って削除された DDL がスレーブにも適用されてしまうと、遅延スレーブをライフラインとして使用できなくなります。

完全リカバリ（異なるマシンでのリカバリ）

現時点では、バックアップを通じてのみデータを復元できます。まず、完全バックアップ（通常は xtrabackup によってバックアップされた物理バックアップ）を復元する必要があります。バックアップがリモート マシン上にあると仮定すると、完全なバックアップ回復を実行するには次の手順を実行する必要がある場合があります。

1. バックアップをターゲットインスタンスマシンにscpまたはrsyncする
2. バックアップ ファイルが圧縮されている場合は、解凍する必要があります。
3. 解凍後、REDOログを適用する必要があります
4. ファイル権限の変更
5. ファイルをターゲット インスタンスの datadir ディレクトリに直接コピーした場合、この手順で mysqld を直接起動できます。そうでない場合は、データ ファイルをターゲット インスタンスの datadir ディレクトリに移動またはコピーバックする必要もあります。
6. インスタンスの起動
   

バックアップとリカバリの追加

この時点で、完全バックアップが復元され、次のステップは増分リカバリです。以前のバックアップ計画によれば、増分データの回復を完了するには binlog を使用する必要があります。バイナリログのリカバリには通常、次の手順が必要です。

1. 復元する必要がある開始点である、フルバックアップに対応するバイナリログの場所を決定します。
2. マスターデータベースのバイナリログを解析し、誤って削除されたデータの場所を特定して、リカバリの終了点とする
3. mysqlbinlog —start-position —stop-position+pipeline を使用して、ターゲットインスタンスにbinlogを復元します。

binlog を復元する方法は多数あります。元のマスター上の binlog または binlogserver 上の binlog を使用できます。必要なのは、binlog リカバリのエンドポイントを見つけることだけです。

バックアップとリカバリの最適化

この時点で、binlog リカバリを使用するのは少し面倒だと思うかもしれません。確かにその通りです。mysqlbinlog コマンドでは、どの GTID に復元するかを指定する方法はありません。復元する必要のある GTID に対応する POS 位置を見つけるには、binlog を解析することしかできませんが、これを自動的に実装するのは面倒です。また、mysqlbinlog コマンドを使用してリストアする場合は、シングルスレッドのリカバリになります。リストアする必要がある binlog の量が比較的多い場合は、この増分リカバリにかかる時間が想像できます。

では、binlog アプリケーションを高速化する方法はありますか?ここで、MySQL 5.7 の並列レプリケーションについて考えます。SQL スレッドの並列レプリケーションを使用できれば、この問題は解決されるでしょうか?

マスターでのバイナリログのリカバリ

完全復旧の時点に戻り、新しいインスタンスを元のマスターのスレーブにして、指定された GTID 位置に復元しますか?はい、これは非常に単純で簡単、かつエラーが発生しやすい方法です。また、並列レプリケーションの原理を使用して、binlog アプリケーションを高速化することもできます。ただし、この方法の要件の 1 つは、元のマスターの最も古いバイナリログに必要な開始リカバリ ポイントが含まれていることです。これは簡単に考えられるため、これが推奨されるリカバリ方法になります。

binlogserver での Binlog リカバリ

マスター上の元の binlog が消去されていると仮定すると、binlog から復元する必要があります。 binlogserver 上の binlog を元のマスターにコピーし、その後 binlog インデックスを変更して登録の目的を達成することを考える人もいるかもしれません。実際には、これはお勧めできません。具体的な理由については、「binlog ファイルを手動で登録すると、マスターとスレーブの異常が発生する」を参照してください。

どのようなアプローチを取ることができますか?これは、binlogserver を使用してマスターのふりをし、スレーブ ライブラリを変更することです。スレーブを欺き、スレーブの io_thread に不足している binlog をプルさせ、sql_thread に binlog イベントを並列に適用させるというアイデアです (この方法については、次のセクションで詳しく説明します)。

最適化された回復プロセス

最適化後、バックアップ回復プロセスは次のようになりました。まず、マスターの binlog を介して回復します。マスターの binlog が消去されたことが判明した場合は、binlogserver の binlog を介して回復します。これは、より科学的で合理的な回復プロセスだと思います。

さまざまな回復方法の適時性の比較

事業回復

この時点で、フル+増分バックアップのデータ復旧が完了しました。この時点で、R＆Dでデータを確認する必要があります。確認後、対応するテーブルを元のマスターに復元します。よく使用される方法は次のとおりです。

1. mysqldump エクスポート + インポート対象インスタンス
2. テーブルスペーストランスポート
   

要約する

このセクションでは、主にバックアップとリカバリの設計プロセスを紹介します。完全なリカバリを最適化する方法がない場合、増分バックアップの方法とプロセスを最適化することで、リカバリ時間を短縮できます。説明する必要があるのは、このセクションで紹介されている内容はまだ完全にテストされておらず、すべての点が正しいことを保証できないということです。さらなる検証が必要です。検証に合格したら、お知らせし、既存のデータベース運用保守プラットフォームと組み合わせて自動回復を実現します。

最後に、いくつか注意事項があります。

1. データは無形財産ですので、必ずバックアップして検証してください。
2. 条件が許せば、遅延スレーブを展開してみる
3. 回復時に慌てないように回復計画を立ててください。
4. シナリオに応じて適切な回復方法を選択し、回復時間を短縮するようにしてください。

上記は、MySQL バックアップとリカバリの設計アイデアの詳細な内容です。MySQL バックアップとリカバリの詳細については、123WORDPRESS.COM の他の関連記事に注目してください。