分割バックアップ

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

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

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

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

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

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

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 個のテーブルなど、複数の部分に分割します。