分割バックアップ

データベースサーバーは大きいが個々のデータベースは小さい – データベースサーバーの合計サイズは数 TB であるが、個々の独立したユーザーデータベースのサイズは 1 TB 未満の場合に適しています。移行期間全体を短縮するために、個々のデータベースを個別に移行することも並行して移行することもできます。

オンプレミスの 2 TB データベースサーバーの例を見てみましょう。このサーバーは、それぞれ 0.5 TB の 4 つのデータベースで構成されています。個々のデータベースのバックアップは個別に作成できます。バックアップを復元するときは、インスタンス上のすべてのデータベースを並行して復元するか、データベースが独立している場合は、各バックアップを個別のインスタンスで復元できます。ベストプラクティスは、独立したデータベースを同じインスタンスで復元するのではなく、別のインスタンスで復元することです。詳細については、このガイドの「ベストプラクティス」を参照してください。

データベースサーバーは大きいが個々のデータベーステーブルは小さい – データベースサーバーの合計サイズが複数 TB であるが、個々の独立したデータベーステーブルのサイズが 1 TB 未満の場合に適しています。移行期間全体を短縮するために、独立したテーブルを個別に移行できます。

1 TB の単一のユーザーデータベースが、オンプレミスデータベースサーバー内の唯一のデータベースである例を見てみましょう。データベースには 10 個のテーブルがあり、それぞれが 100 GB です。個々のテーブルのバックアップはそれぞれ個別に作成できます。バックアップを復元するときは、インスタンス上のすべてのテーブルを並行して復元できます。

データベースにトランザクションワークロードテーブルと非トランザクションワークロードテーブルの両方が含まれている – 前のユースケースと同様に、同じデータベース内にトランザクションワークロードテーブルと非トランザクションワークロードテーブルの両方がある場合、分割バックアップアプローチを使用できます。

オンライントランザクション処理 (OLTP) に使用される 0.5 TB の重要なワークロードテーブルと、古いデータのアーカイブに使用される単一の 1.5 TB テーブルで構成される、2 TB のデータベースの例を見てみましょう。アーカイブテーブルを除くすべてのデータベースオブジェクトのバックアップを、単一トランザクションの一貫性のあるバックアップとして取得できます。次に、もう 1 つアーカイブテーブルのみの個別のバックアップを取ります。アーカイブテーブルのバックアップでは、条件を使用してバックアップファイルの行数を分割することで、複数の並列バックアップを取ることも検討できます。以下に例を示します。

mysqldump -p your_db1 --tables your_table1 --where="column1 between 1 and 1000000 " > your_table1_part1.sql
mysqldump -p your_db1 --tables your_table1 --where="column1 between 1000001 and 2000000 " > your_table1_part2.sql
mysqldump -p your_db1 --tables your_table1 --where="column1 > 2000000 " > your_table1_part3.sql

バックアップファイルを復元するときは、トランザクションワークロードのバックアップとアーカイブテーブルのバックアップを並行して復元できます。

コンピューティングリソースの制限事項 – CPU、メモリ、ディスク I/O など、オンプレミスサーバー内のコンピューティングリソースが限られている場合、バックアップを取る際の安定性とパフォーマンスが影響を受ける可能性があります。完全なバックアップを取る代わりに、パーツに分割できます。

例えば、オンプレミスの本番稼働用サーバーで、ワークロードの負荷が大きく、CPU リソースが限られているとします。このサーバーでマルチテラバイトデータベースのバックアップを一度に実行すると、CPU リソースの消費量が増え、本番稼働用サーバーに悪影響を及ぼす可能性があります。データベース全体のバックアップを取る代わりに、テーブル 2～3 個ずつなど、複数のパーツに分割してバックアップを取ります。