MySQLデータのバックアップ方法の選択と考え方

私は DBA 業界で 2 年以上働いており、理論と実践の両方でデータ バックアップの経験を積んできました。しかし、この 2 日間でデータ バックアップに関する問題が発生しました。ここでは、これまでに遭遇したデータ バックアップ方法を簡単にまとめます。

データベースの安定した、安全で効率的な運用を確保することが DBA の職務であることは誰もが知っています。 DBA にとって、データのバックアップはデータ セキュリティを実現するための重要な要素となります。

かつて、ビジネス側が誤ってデータを削除し、障害が発生したケースに遭遇しました。DBA にデータの復元を依頼したところ、その日のデータがバックアップされていなかったことが判明しました。状況は非常に恥ずかしいものでした。もともと障害の原因はビジネス側でしたが、データのバックアップがなかったため、最終的にはビジネス側と DBA の両方に責任が問われました。ビジネスで DBA がデータを復元する必要がない場合は、DBA は後でこっそりとデータをバックアップして、最終的に関与を回避できます。もちろん、実稼働環境では「もしも」は存在しません。

バックアップの重要性は明らかです。では、一般的なバックアップのアイデアにはどのようなものがあるでしょうか?バックアップがオンライン環境に影響を与えるかどうかによって、コールドバックアップとホットバックアップの2つの方法に大別できます。コールドバックアップはオンライン業務に影響を与え、オフラインバックアップが必要であると理解できますが、ホットバックアップはオンライン業務に影響を与えないか、比較的影響が小さいです。

以下の方法をまとめました。

1. rsync、cpでファイルをコピーする

この方法はより強力です。MySQL データベースを直接停止し、cp や rsync などの Linux 物理ファイル コピー コマンドを使用してデータをバックアップします。

で：

cpは、現在のサーバー上の他のディレクトリへのバックアップを指します。

Rsyncは特に他のサーバーへのバックアップを指します

この方法では、次の点に注意する必要があります。

a. オンライン環境では、サーバーがダウンすると cp 方式のバックアップも利用できなくなるため、rsync 方式の方が適しています。

b. rsync と cp の両方のメソッドは、マスター/スレーブ アーキテクチャのスレーブ データベース、または指定されたバックアップ データベースで実行する必要があります。 (ここでは、オンライン環境には 1 つのマスター、1 つのスレーブ、1 つのバックアップのレプリケーション アーキテクチャを使用することをお勧めします)

コールド バックアップの最大の利点は、速度が速く、操作が簡単なことです。

大規模データベースの毎日のバックアップに適しています。

2. xxxをoutfile構文に選択する

この方法は、1 つのテーブルのデータのみをバックアップするため、バックアップとは呼ばれないことが多いですが、非常に便利です。

ビジネス側から数百のデータ項目の更新を依頼されたが、テーブルには数千万のデータ項目があるというシナリオを想像してください。このとき、テーブル全体をバックアップすると柔軟性が低下し、時間もかかります。最初に select 構文を使用して、変更が必要なデータを txt ファイルに保存しておけば、更新後にビジネス フィードバックが期待どおりに行われなかったとしても、更新前の状態をすぐに見つけることができるため、データの回復時間を大幅に短縮できます。

このバックアップ方法は、変更される前に単一のテーブル内のデータの一部をバックアップするのに適しています。

3. 遅延スレーブ

MySQL では、このタイプのバックアップ ソリューションは比較的まれですが、MongoDB では遅延スレーブは非常に一般的です。ただし、遅延スレーブはオンライン バックアップのより優れた手段であり、その最も重要な機能は回復の可能性が高いことです。

時には、さまざまな依存関係やバージョンの問題により、苦労してバックアップしたデータが他のサーバーに復元できないことがあります。これは非常に厄介なことですが、遅延スレーブ ライブラリを使用すると、この問題をうまく解決できます。スレーブ ライブラリ自体は実行されているため、ライブラリが起動できないことを心配する必要はありません。

遅延スレーブバックアップ計画では、スレーブの遅延時間を制御する必要があります。設定が短すぎると、マスターで問題を引き起こす可能性のある SQL がスレーブで実行されている可能性があり、遅延効果が得られず、遅延スレーブの意味がなくなります。

4. 論理バックアップ mysqldump

これはおそらく、MySQL をバックアップする最も一般的な方法です。公式バックアップ ツール mysqldump を使用すると、特定の時点での一貫したスナップショットを提供できます。現在の時点と、MySQL データベースが実行されたバイナリ ログの場所を明確に把握でき、リカバリの精度も非常に高くなります。さらに、指定したライブラリやテーブルなどのバックアップもサポートしており、その機能は非常に強力です。

データ量が 50G 未満のデータベースのバックアップに適しています。50G を超えると、リカバリが非常に遅くなります。

これについてはこれ以上言う必要はありません、誰もが知っています。

--single-transaction を追加することを忘れないでください。そうしないと、テーブルがロックされ、ビジネスが書き込まれない可能性があります。小さな兄弟がかつてここに落ちました。

その特徴は、特定の時点でのデータベースのスナップショットを提供できることであり、バックアップ ファイルは一般に小さいです。

5. xtrabackup バックアップ

これは別のホット バックアップ方法です。xtrabackup バックアップ方法では、データベースの書き込みに影響を与えずにデータベースのホット バックアップを実行できます。本質的には、これは依然として物理ファイルのコピーであり、mysqldump よりも高速です。

メイン データベースの読み取りおよび書き込み負荷が比較的小さい場合は、メイン データベースに直接バックアップできます。ただし、オンライン マスター データベースに大きな書き込み負荷がかかり、xtrabackup によってマスター データベースのバックアップが直接クラッシュするケースがあるため、マスター データベースでは使用しないことをお勧めします。データベースを停止せずにスレーブ データベースで xtrabackup を実行する方が比較的安全な方法です。

バックアップ速度が速く、オンラインバックアップへの影響が比較的小さいのが特徴です。

6. バイナリログのバックアップ

Binlog バックアップは、基本的に、mysqldump の結果に似た SQL ステートメントのバックアップですが、binlog は mysqldump よりも多くのデータを保持します。

このデータベースの起動以降のすべてのバイナリログがあれば、間違いなくこのデータベースを復元できます。ただし、すべてのバイナリログは比較的大量のデータである必要があり、完全なログを保持することは通常困難であるため、バイナリログのバックアップはスナップショットのバックアップと組み合わせる必要があります。

スレーブ ライブラリがオンラインのときにレプリケーション関係を停止し、ログをフラッシュして新しい binlog を生成し、それを binlog0 として記録してから、スレーブ ライブラリの完全バックアップをコピーし、binlog0 以降のすべての binlog を保存します。このようにして、スレーブ ライブラリの完全バックアップ + binlog 方式を使用して、スレーブ ライブラリのデータを復元できます。

バイナリログ バックアップは、バイナリログ書き込み速度が平均的なデータベースに適しています。データベースのバイナリログが非常に速く更新される場合、データ容量がボトルネックになる可能性があります。

7. プラグインのクローン

クローン プラグインは 8.0 の目玉機能です。ローカル データのバックアップとデータベース スレーブの迅速なリモート プルアップの両方をサポートできます。検討する価値のあるバックアップ方法です。これについては以前の記事で詳しく説明されているので、興味があれば読んでみてください。公式ドキュメントを参照することもできます。

しかし、現在国内のデータベースのほとんどがMySQLバージョン5.7であるため、オンライン環境ではあまり使用されていません。もちろん、8.0がトレンドですので、まだアップグレードしていない場合は、できるだけ早くアップグレードしてください。

上記は、MySQL データのバックアップ方法を選択する方法の詳細です。MySQL データのバックアップの詳細については、123WORDPRESS.COM の他の関連記事に注目してください。