| カテゴリ | 説明 |
| ソースデータベースの制限 | - 帯域幅要件: ソースデータベースが属するサーバーには、十分な出力帯域幅が必要です。 そうしないと、データ移行速度が影響を受けます。
- 移行するテーブルには、PRIMARY KEYまたはUNIQUE制約が必要であり、すべてのフィールドが一意である必要があります。 そうでない場合、宛先データベースは重複するデータレコードを含み得る。
- 移行するオブジェクトとしてテーブルを選択し、テーブルを編集する必要がある場合 (テーブルまたは列の名前の変更など) 、1回のデータ移行タスクで最大1,000のテーブルを移行できます。 タスクを実行して1,000を超えるテーブルを移行すると、リクエストエラーが発生します。 この場合、移行するテーブルを分割するか、テーブルを移行するために複数のタスクを構成するか、データベース全体を移行するようにタスクを構成することをお勧めします。
- 操作の制限:
- スキーマ移行中および完全データ移行中は、データベースまたはテーブルのスキーマを変更するためのデータ定義言語 (DDL) 操作を実行しないでください。 それ以外の場合、データ移行タスクは失敗します。
- このシナリオでは、DTSは増分データ移行をサポートしていません。 データの一貫性を確保するため、データ移行中はソースインスタンスにデータを書き込まないことを推奨します。
|
| その他の制限 | - このシナリオでは、DTSはスキーマ移行と完全データ移行のみをサポートします。 DTSは増分データ移行をサポートしていません。
- ソースオブジェクトの文字は、英数字 (aからz、AからZ、および0から9) のみです。 オブジェクトに他の種類の文字が含まれている場合、スキーマの移行は失敗します。
- AnalyticDB for MySQLには、ディスク容量の使用に制限があります。 AnalyticDB for MySQLクラスター内のノードのディスク領域使用量が80% に達すると、ターゲットデータベースへのデータ書き込みのパフォーマンスが低下し、DTSタスクが遅延します。 使用量が90% に達すると、データをターゲットデータベースに書き込むことができず、エラーメッセージが返されます。 移行するオブジェクトに基づいて、必要なディスク容量を見積もることを推奨します。 移行先クラスターに十分なストレージ容量があることを確認する必要があります。
- データを移行する前に、移行元データベースと移行先データベースのパフォーマンスに対するデータ移行の影響を評価します。 オフピーク時にデータを移行することを推奨します。 完全データ移行中、DTSはソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。 これは、データベースサーバの負荷を増加させる可能性がある。
- 完全データ移行中、同時INSERT操作により、ターゲットデータベースのテーブルが断片化されます。 完全データ移行が完了すると、移行先データベースのテーブルスペースは移行元データベースのテーブルスペースよりも大きくなります。
- DTSは、過去7日以内に失敗したデータ移行タスクを再開しようとします。 ワークロードを移行先クラスターに切り替える前に、データ移行タスクを停止またはリリースします。
revokeコマンドを実行して、移行先クラスターへのアクセスにDTSが使用するアカウントの書き込み権限を取り消すこともできます。 そうしないと、タスクの再開後、ソースデータベースのデータがターゲットクラスターのデータを上書きします。
|