Database Backup:バックアップと復元のパフォーマンステスト

バックアップと復元のパフォーマンステストの注意

次のパフォーマンステストの結果は、参考用であり、SLA のパフォーマンスを評価するために使用しないでください。

はじめに

このセクションでは、複数のインスタンスタイプのバックアップと復元のパフォーマンスをテストします。結果は選択する際の参考としてください。

用語

1. タイプ：DBS は、複数のインスタンスタイプをサポートしています。バックアップサーバーのCPU、メモリ、およびネットワーク帯域幅の設定に基づき、さまざまなパフォーマンスを提供します。
2. RPS：バックアップと復元での、ソースデータベースの 1 分単位のレコード変更数を表します。これらのレコードの変更は、挿入、更新、削除などのデータ変更操作によって発生します。1 つの SQL 文に複数のデータ行に対する操作が含まれる場合、複数のレコードの変更が記録されます。同じレコードに対して繰り返し操作が実行されると、複数のレコードの変更が記録されます。各コミット操作も、1 回のレコード変更と見なされます。

テストモデル

テスト手順：テストデータベースとして、ApsaraDB for MySQL インスタンスを作成します。バックアップ計画を作成し、完全バックアップと増分バックアップを有効にします。テストデータベースをバックアップし、バックアップセットを OSS に保管します。バックアップセットを使用して、テストデータベースを復元します。

テスト環境：

テストデータ：

1. データベースサイズ: 102 GB
2. 総レコード数：1.5 億
3. 各レコードのサイズ: 100〜1 K
4. フィールド数: 3〜22 列
5. フィールド型：基本的な MySQL データ型

テスト結果

完全バックアップ

注意：バックアップソースデータベースに含まれるテーブルが多すぎると、テーブル構造の復元に時間がかかることがあります。各データベースには、最大で 10,000 テーブルを保持することを推奨します。また、バックアップソースデータベースに、プライマリキーのないテーブル、文字列型プライマリキー、または複合キーのテーブルが含まれていると、バックアップ処理が遅くなる可能性があります。

増分バックアップ

完全復元

注意：ターゲットデータベースに含まれるテーブルが多すぎると、テーブル構造の復元に時間がかかることがあります。各データベースには、最大で 10,000 テーブルを保持することを推奨します。

増分復元