ApsaraDB RDS for MySQLインスタンスの仕様を変更する場合、このトピックで説明されている要因に基づいて必要な時間を見積もることができます。 仕様には、RDSエディション、インスタンスタイプ、およびストレージ容量が含まれます。
必要な時間はいくつかの要因に基づいて異なります。 RDSインスタンスに少量のデータしか書き込まれない場合は、仕様を変更することを推奨します。 または、仕様を変更する前に、RDSインスタンスへのデータの書き込みを停止することを推奨します。
RDSインスタンスがローカルディスクを使用している場合、仕様の変更により、元のRDSインスタンスから新しいRDSインスタンスへのデータ移行がトリガーされる場合があります。 この場合、仕様変更に長時間を要する。 次の表に、必要な時間に影響を与える重要な要素を示します。
データ移行プロセス中、ApsaraDB RDSは元のRDSインスタンスのデータをバックアップし、データを新しいRDSインスタンスに復元します。
ストレージタイプ | クロスインスタンスデータ移行が必要 | ファクター | 説明 |
ローカルディスク | 必須 | フルデータのサイズ | フルデータのサイズは、データ移行に必要な時間に影響します。 データ移行に必要な時間は、バックアップ速度とネットワーク帯域幅の影響も受けます。 |
redoログのサイズ | redoログのサイズが大きい場合、推定量で示されるよりも多くのデータをバックアップする必要があります。 この場合、新しいRDSインスタンスにデータを復元するには長い時間がかかります。 | ||
ロック | データ移行プロセス中にApsaraDB RDSが元のRDSインスタンスのデータをバックアップすると、関連オブジェクトがロックされます。 これはバックアップ速度に影響します。 | ||
テーブルの数 | - | ||
増分データのサイズ | 完全なデータが新しいRDSインスタンスに移行された後、ApsaraDB RDSは、データ移行プロセス中に生成された増分データも移行する必要があります。 これは、仕様変更に要する時間に影響する。 | ||
増分データの書き込み速度 | 増分データの書き込み速度は、いくつかの要因の影響を受けます。 要因には、記録されたSQLステートメントの再生速度、記録されたSQLステートメントが個々のテーブルで実行されるかどうか、元のRDSインスタンスでデータ定義言語 (DDL) ステートメントが実行されるかどうかが含まれます。 | ||
データ同期レイテンシ | 増分データを新しいRDSインスタンスに書き込む前に、新しいRDSインスタンスと元のRDSインスタンスの間に同期リンクを確立する必要があります。 ApsaraDB RDSは、データ同期が完了した後にのみ、ワークロードを元のRDSインスタンスから新しいRDSインスタンスに切り替えます。 仕様変更に必要な時間は、データ同期レイテンシの影響を受けます。 レイテンシは、いくつかの要因によってさらに影響を受ける。 要因には、元のRDSインスタンスの書き込み負荷、元のRDSインスタンスでDDLステートメントが実行されるかどうか、複数のテーブルで共同クエリが実行されるかどうかが含まれます。 | ||
任意 | - | RDSインスタンスがローカルディスクを使用していて、インスタンス間のデータ移行が不要な場合、仕様の変更には短時間で済みます。 この場合、前の要因を考慮する必要はありません。 | |
クラウドディスク | 任意 | - | RDSインスタンスがクラウドディスクを使用している場合、元のRDSインスタンスのデータを新しいRDSインスタンスに移行する必要はありません。 仕様変更には短時間で済む。 この場合、前の要因を考慮する必要はありません。 |