ApsaraDB RDS:RDS for MySQL Enterprise Edition インスタンスから RDS for MySQL Cluster Edition インスタンスへのデータ移行

移行アプローチの選択

(増分移行なしで) 完全データ移行のみを実行する場合は、データ不整合を防ぐため、移行中はソースデータベースへのすべての書き込みを停止してください。

増分データ移行でサポートされるSQL操作

ソースデータベース

• ソースサーバーには、十分なアウトバウンド帯域幅が必要です。 帯域幅が不足すると、移行速度が低下します。

• テーブルには PRIMARY KEY または UNIQUE 制約が必要で、すべてのフィールドが一意である必要があります。 これらの制約がないテーブルでは、移行先で重複レコードが生成されることがあります。

• テーブルを移行オブジェクトとして選択し、移行先でテーブルまたは列の名前を変更する必要がある場合、制限は 1 タスクあたり 1,000 テーブルです。 より大規模な移行の場合は、複数のタスクに分割するか、データベース全体を移行オブジェクトとして選択してください。

• バイナリログの保持要件：

  • 増分移行のみ：バイナリログを24時間以上保持する必要があります

  • 完全移行 + 増分移行：バイナリログを7日間以上保持する必要があります

  • 完全移行が完了した後、保持期間を 24 時間以上に短縮できます。 これらのしきい値を下回ると、DTS がバイナリログを取得できなくなり、タスクの失敗やデータ損失につながる可能性があります。 これらの要件が満たされていない場合、DTS のサービスレベルアグリーメント (SLA) はサービスの信頼性を保証しません。

• スキーマ移行および完全データ移行中：データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。 タスクが失敗します。

• 完全データ移行のみの場合：ソースデータベースにデータを書き込まないでください。 書き込みを継続する必要がある場合は、増分データ移行を含めてください。

全般

• 互換性を確保するため、ソースインスタンスと移行先インスタンスでは同じ MySQL エンジンバージョンを使用してください。

• 移行はオフピーク時にスケジュールしてください。 完全データ移行では、両方のインスタンスで読み取りおよび書き込みリソースが使用されるため、サーバーの負荷が増加します。

• 完全データ移行後、同時 INSERT 操作による断片化のため、移行先のテーブルスペースがソースよりも大きくなる場合があります。

• DTS は、FLOAT 型および DOUBLE 型の列から値を読み取る際に ROUND(COLUMN, PRECISION) を使用します。精度を指定しない場合、デフォルトで FLOAT は 38 桁、DOUBLE は 308 桁になります。開始する前に、これらのデフォルト値がお客様の要件を満たしていることをご確認ください。

• DTS は、失敗したタスクを最大 7 日間自動的に再試行します。ワークロードを移行先に切り替える前に、失敗したタスクを停止または解放するか、REVOKE を実行して移行先への DTS の書き込みアクセス権を削除してください。そうしないと、失敗したタスクが再開されると、移行元のデータが移行先のデータを上書きする可能性があります。

• ソースデータベース名が無効な場合は、タスクを設定する前に移行先データベースを手動で作成してください。 詳細については、「データベースの管理」をご参照ください。 ソースデータベース名が有効な場合、DTS は移行先データベースを自動的に作成します。

ステップ 1：データ移行タスクページへの移動

1. Data Management (DMS) コンソール にログインします。

2. 上部メニューで、DTS にポインターを移動し、[DTS] > [データ移行] を選択します。

   手順は DMS コンソールのモードによって異なる場合があります。 詳細については、「シンプルモード」および「DMSコンソールのレイアウトとスタイルのカスタマイズ」をご参照ください。 または、新しいDTS コンソールのデータ移行ページに直接移動することもできます。

ステップ 2：リージョンの選択

データ移行タスク の右側にあるドロップダウンリストから、データ移行インスタンスが存在するリージョンを選択します。

新しい DTS コンソールでは、左上の隅でリージョンを選択します。

ステップ 3：ソースデータベースと移行先データベースの設定

[タスクの作成] をクリックします。 データ移行タスクの作成ページで、ソースデータベースと移行先データベースを設定します。

ソースデータベース

移行先データベース

ステップ 4：接続のテスト

[接続をテストして次へ] をクリックします。

DTS は、DTS サーバーの CIDR ブロックを ApsaraDB RDS インスタンスの IP アドレスホワイトリストに自動的に追加します。 Elastic Compute Service (ECS) インスタンス上の自己管理型データベースの場合、DTS はその CIDR ブロックを ECS セキュリティグループルールに追加します。 データベースが複数の ECS インスタンスで実行されている場合は、各インスタンスのセキュリティグループに DTS の CIDR ブロックを手動で追加する必要があります。 データセンターやサードパーティクラウド上の自己管理型データベースの場合、DTS の CIDR ブロックをデータベースの IP アドレスホワイトリストに手動で追加する必要があります。 CIDR ブロックの完全なリストについては、「DTSサーバーのCIDRブロックの追加」をご参照ください。

ステップ 5：オブジェクトの選択と移行設定の構成

次のパラメーターを設定します。

オブジェクトの名前を変更すると、依存するオブジェクトの移行が失敗することがあります。

ステップ 6：詳細設定の構成

[次へ：詳細設定] をクリックします。

データ検証設定：データ検証を有効にするには、「データ検証タスクの設定」をご参照ください。

詳細設定：

ステップ 7：事前チェックの実行

[次へ：タスク設定の保存と事前チェック] をクリックします。

DTS が自動的に事前チェックを実行します。 すべての事前チェック項目に合格するまで、タスクを開始できません。

• 事前チェック項目が失敗した場合は、[詳細の表示] をクリックして問題を修正し、[再度事前チェック] をクリックします。

• アラートがトリガーされ、無視できる場合は、[アラート詳細の確認] をクリックし、次に 無視、OK の順にクリックし、[再度事前チェック] をクリックします。 アラートを無視すると、データ不整合につながる可能性があります。

API パラメーターを表示するには、次へ：タスク設定の保存と事前チェック にカーソルを合わせ、[OpenAPI パラメーターのプレビュー] をクリックします。

ステップ 8：移行インスタンスの購入

成功率 が 100% に達するまで待ってから、[次へ：インスタンスの購入] をクリックします。

[インスタンスの購入] ページで、以下を設定します。

ステップ 9：移行の開始

1. チェックボックスをオンにして、Data Transmission Service (従量課金) 利用規約 を読み、同意します。

2. [購入して開始] をクリックし、確認メッセージで [OK] をクリックします。

[データ移行] ページで移行の進捗状況を追跡します。