時点別のMySQLデータベース復旧実績

はじめに: 時間ポイントによる MySQL データベースの復旧

どの企業にとっても、データは最も価値のある資産です。

データの整合性をどのように保護し、データが破損するのを防ぐか、障害が発生した場合にどのようにデータを保持するか、誤操作、ハッカーの侵入、データの改ざんなどが発生した場合にバックアップに基づいてどのようにデータを復元するかは、すべての技術者が注意を払う必要がある重要なポイントです。

Alibaba Cloud は、顧客へのサービス提供と、顧客データベースの継続的なデータ保護と低コストのバックアップ サービスの実現に尽力しています。さまざまな環境でデータに対して強力な保護と強力な回復を提供できます。極端なデータ損失やデータ破損の場合でも、RDS 管理および制御プラットフォームにはワンクリック復元機能があり、顧客が設定した時点に基づいて包括的なデータ復旧を実行できます。

1. ポイントインタイムリカバリの技術的実装

ある時点での誤った操作により顧客がデータを失った場合、RDS 管理サービスはどのようにデータを回復しますか?

ポイントインタイムリカバリの全体的な考え方は次のとおりです。完全なデータリカバリは、物理バックアップ + バイナリログリカバリ + バイナリログプルーニングで構成されます。

図1

まず、利用可能なバックアップ セットを取得し、そのバックアップ セットをターゲット インスタンスに適用し、次にターゲット インスタンスで復元する必要がある binlog ファイルを再生し、最後に binlog トリミングの形式で SQL ファイルを適用して、全体的なリカバリを実現します。

2. ポイントインタイムリカバリの管理および制御プロセス

1. リカバリ用のインスタンスを作成する

ソースデータベースのデータ全体を復元する必要がある場合、まずソースインスタンスと同じ仕様とネットワーク環境を持つターゲットインスタンスを作成する必要があります。

なぜこれをするのですか?

バックアップとリカバリはリスクの高い操作であるため、ソースインスタンスに直接復元すると、バックアップセットが利用できない、バイナリログが見つからないなどの問題が発生すると、失われたデータを回復できないだけでなく、元のデータも完全には保存されない可能性があります。したがって、リカバリには新しいインスタンスを使用することを強くお勧めします。

2. バックアップとリカバリの時点を指定する

お客様が意図せずデータベースの削除や変更などの一連の操作を行ってしまい、業務に支障が出たり障害が発生したりした場合、データ復旧のために操作の正確な時刻を特定するにはどうすればよいでしょうか。

方法 1: ログ監査機能を使用して、対応するエラー操作の時点を見つけることができます。

方法 2: バイナリログをテキストに解析し、対応するエラー操作の時点を照会できます。

3. バックアップ履歴から利用可能なバックアップセットを取得する

一般的に、ビジネスの重要性に基づいて、顧客はクラウド上で独自のデータベース バックアップ サイクルを計画し、RDS 管理はユーザーが選択したリカバリ時点に基づいて利用可能な物理バックアップ セットを自動的に検索します。

データベースの高可用性と災害復旧にはバックアップが最も重要であることがわかります。

4. バックアップセットに対応するバイナリログポイントを取得する

プライベート クラウドのバックアップは、通常、xtrabackup ツールに基づいています。 Xtrabackup はホット バックアップと高速リカバリという特徴があり、同時に、バックアップの最後に適用された binlog のファイルとポイントを対応するファイルに書き込みます。 RDS コントロールは、 binlogfile 、 binlogposなどの情報をデータベースに書き込みます。バックアップとリカバリが必要な場合は、リカバリのポイントが直接取得されます。

次の図に示すように:

図2

5. バックアップセットを宛先インスタンスに復元する

ステップ 1 ～ 4 は準備です。これでデータの復旧を開始します。データを復元する最初の手順は、利用可能な完全な物理バックアップ セットを宛先インスタンスにダウンロードし、xtrabackup ツールを使用して復元することです。

//​​まず、ターゲットインスタンス上のmysqlプロセスを停止します​

​systemctl を停止 mysql​

//​​次に、データをマージします。バックアップが /root/backup/ ディレクトリに解凍されていると仮定すると、復元するインスタンス ポートを指定できます。指定するには、--defaults-file パラメータを追加する必要があります。デフォルトは 3306 です。​

innobackupex --apply-log /root/backup/

​//​​元のディレクトリファイルを削除します​

rm -rf /データ/mysql

// データ セットを復元します。データが復元されるディレクトリは、構成ファイル my.cnf の datadir によって決まります。このフィールドの正確性を確認する必要があります。

innobackupex --copy-back /root/backup/

​//​​ディレクトリ認証​

chown ​​-​​R mysql:mysql ​​/​​data​​/​​mysql

6. 復元が成功したことを確認する

管理サービスは、続行するかどうかを決定する前に、復元が成功したかどうかを確認する必要があります。検証手順も非常に単純で大まかです。バックアップ回復ログに ERROR があるかどうか、最後の行が正常に完了しているかどうかを確認するだけです。

次の図は、成功したバックアップとリカバリを示しています。

図3

7. リカバリ用のbinlogログを取得する

この手順は、回復の成功とデータの整合性にとって重要です。

では、RDS 管理サービスはどのようにしてリカバリ用の正しいバイナリログを取得するのでしょうか?下の写真を見てみましょう。

図4

たとえば、現在のバックアップには合計 8 つのバイナリログ バックアップ (000-008) があります。まず、物理バックアップに記録されたバイナリログのファイル名と位置 (上図の binlog004 など) から最初のバイナリログを取得します。次に、お客様が復元するように設定した時点のタイムスタンプ (上図の binlog007 など) から対応する最後のバイナリログを見つけます。最後に、4 つのバイナリログ バックアップ (binlog004、binlog005、binlog006、binlog007) を復元先のインスタンスにダウンロードします。

リカバリ時に誤ったバイナリログを取得した場合、例えば、binlog003/binlog005 を誤って最初のバイナリログに設定した場合、binlog003/binlog005 で実行された DML 文が新しいインスタンスで再実行され、リカバリされたデータが増加したり、欠落したりします。例えば、binlog0006 や binlog0008 を誤って最後のバイナリログに設定した場合、リカバリされたデータが欠落し、期待した効果が得られません。

8. リプレイリレーログ

ダウンロードしたバイナリログを新しいインスタンスの logdir にコピーし、最後のバイナリログ (リカバリ時点をカバーするバイナリログ) を除くバイナリログの名前を relaylog に変更し、新しいインスタンスを使用してこれらのリレーログを再生します。

​//​​binlog の名前を変更します。relaylog ファイル名は、mysql インスタンスで '%relay%' などの show variables を実行することで表示できます。​

mysql​​-​​bin を MySQL2​​-​​relay​​-​​bin に名前変更 mysql​​-​​bin​​*​

​//​​リレー情報をインデックスファイルに初期化します​

​ls .​​/​​MySQL2​​-​​relay​​-​​bin.​​0000​​*​​​​>​​MySQL2​​-​​relay​​-​​bin.index​

​//​​これらのファイルをデータファイルにコピーします​

​cp MySQL2-relay-bin.*/data/mysql/​

​//​​ファイル認証​

chown ​​-​​R mysql:mysql ​​/​​data​​/​​mysql​

​//​​mysqlインスタンスを起動します​

​systemctl で MySQL を起動します​

// マスターを存在しないインスタンスに変更し、このインスタンスをスタンバイ データベースとしてシミュレートし、空のマスター データベースを指定して、SQL スレッドを作成し、バックアップ レコードの binlogfile と binlogpos に従って設定します。スレーブのsql_threadを開始します

​マスターを MASTER_HOST​​=​​'1.1.1.1'​​、RELAY_LOG_FILE​​=​​'MySQL2-relay-bin.000011'​​、RELAY_LOG_POS​​=​​160338​​ に変更します。​

​スレーブSQL_THREADを開始します。

​スレーブステータスを表示\G

9. リレーログの再生が成功したことを確認する

show slave status\G を実行して確認します。この手順は、データベース バイナリログの数とサイズに応じて、通常、回復に時間がかかります。

検証 1: relay_log_file フィールドの値が、MySQL2-relay-bin.index ファイルに保持されている最大値であるかどうかを確認します。そうであれば、すべてのバイログが正常に再生されたことが証明されます。

検証 2: Slave_SQL_Running フィールドが YES かどうかを確認します。

次の図に示すように:

図5

10. mysqlbinlog関数を使用して、リカバリ時点でのbinlogをトリミングし、sqlファイルを生成します。

この時点で、手順 1 ～ 9 でほとんどのデータが回復されましたが、回復時点をカバーする binlog が 1 つ残っていますが、まだ回復されていません。

それで、どうやってやるのでしょうか?

次の図に示すように:

図6

お客様の時点（15:00 に復元する必要があるデータなど）に応じて、RDS 管理は、リカバリ時間に応じてリカバリ時点をカバーするバイナリログをトリミングする必要があります。つまり、12:00 から 15:00 のデータのみが適用されます。15:00 から 18:00 のデータはエラー操作時間に属しているため、使用しないでください。

//​​mysqlbinlogツールのプルーニング機能を使用して、binlogをプルーニングします

mysqlbinlog ​​--​​start​​-​​position​​=​​4​​​​--​​stop​​-​​datetime​​=​​'2021-04-23 15:00:00'​​​​-​​R ​​-​​h127.​​0.0​​.​​1​​​​-​​uroot ​​-​​pxxxx ​​-​​P3306 mysql​​-​​bin.​​007​​​​>​​​​/​​tmp​​/​​mysql​​-​​bin.​​007.​​sql

11. ターゲットインスタンスはSQLファイルを通じて復元するデータを実行します。

ターゲットインスタンスで SQL ファイルを実行します。

//​​エンパワーメント​

chown mysql:mysql ​​/​​tmp​​/​​mysql​​-​​bin.​​007.​​sql​

​//​​データを回復する​
mysql -uroot -pxxxx -h127.0.0.1-P3306 -f --max_allowed_pa​​cket=1073741824 </root/mysql-bin.007.sql

12. データの検証

この時点で、全体的なバックアップとリカバリは完了しています。次に、お客様はデータを検証し、宛先インスタンスのデータをソース インスタンスに復元する必要があります。

私たちは、Alibaba Cloud Intelligent Global Technical Service-SRE チームです。ビジネスシステムの高可用性を保証する、テクノロジーベースのサービス指向のエンジニアリングチームになることを目指しています。私たちは、お客様がクラウドをより有効に活用し、クラウドに基づいてより安定した信頼性の高いビジネスシステムを構築し、ビジネスの安定性を向上させるために、専門的で体系的な SRE サービスを提供しています。私たちは、企業のお客様がクラウドに移行し、クラウドを有効に活用し、お客様のクラウドビジネス運営の安定性と信頼性を高めるのに役立つテクノロジーをさらに共有したいと考えています。DingTalkを使用して以下のQRコードをスキャンすると、Alibaba Cloud SRE Technology Academy DingTalkサークルに参加し、クラウド上のより多くの人々とクラウドプラットフォームについてコミュニケーションをとることができます。

元のリンク: https://developer.aliyun.com/article/784887?

著作権に関する声明:この記事の内容は、Alibaba Cloud の実名登録ユーザーによって寄稿されたものです。著作権は原作者に帰属します。Alibaba Cloud Developer Community は著作権を所有しておらず、対応する法的責任を負いません。具体的なルールについては、「Alibaba Cloud Developer Community ユーザーサービス契約」および「Alibaba Cloud Developer Community 知的財産保護ガイドライン」を参照してください。このコミュニティで盗作の疑いのあるコンテンツを見つけた場合は、著作権侵害の苦情フォームに記入して報告してください。確認後、このコミュニティは著作権侵害の疑いのあるコンテンツを直ちに削除します。

これで、時点別のMySQLデータベースの実用的復旧に関するこの記事は終了です。MySQLデータベース復旧に関するより関連性の高いコンテンツについては、123WORDPRESS.COMの以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも123WORDPRESS.COMをよろしくお願いいたします。