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

移行方式の選択

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

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

ソースデータベース

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

• テーブルには PRIMARY KEY または一意制約 (UNIQUE constraint) が設定されている必要があり、すべてのフィールドが一意である必要があります。これらの制約が設定されていないテーブルを使用すると、宛先で重複レコードが生成される可能性があります。

• テーブルを移行対象として選択し、宛先でテーブル名またはカラム名を変更する必要がある場合、1 タスクあたりの上限は 1,000 テーブルです。大規模な移行を行う場合は、複数のタスクに分割するか、データベース全体を移行対象として選択してください。

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

  • 増分移行のみの場合：バイナリログを 24 時間以上保持する

  • 完全移行 ＋ 増分移行の場合：バイナリログを 最低 7 日間保持する

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

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

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

一般

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

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

• 完全なデータ移行完了後、宛先の表領域 (tablespace) は、同時 INSERT 操作による断片化 (fragmentation) の影響で、ソースよりも大きくなる可能性があります。

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

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

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

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

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

2. トップナビゲーションバーで DTS にポインターを合わせ、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 ブロックを手動で追加する必要があります。 データセンターまたはサードパーティのクラウドにある自己管理データベースの場合、データベースの IP アドレスホワイトリストに DTS の CIDR ブロックを手動で追加する必要があります。 CIDR ブロックの完全なリストについては、「DTS サーバーの CIDR ブロックを追加する」をご参照ください。

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

以下のパラメーターを構成します。

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

ステップ 6：高度な設定の構成

次へ：高度な設定 をクリックします。

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

高度な設定：

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

次へ：タスク設定の保存および事前チェック をクリックします。

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

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

• アラートがトリガーされ、無視できる場合、アラートの詳細の確認 をクリックし、無視、OK の順にクリックした後、再チェック をクリックします。アラートを無視すると、データの不整合が発生する可能性があります。

この設定の API パラメーターを表示するには、次へ：タスク設定の保存および事前チェック 上にポインターを合わせ、OpenAPI パラメーターのプレビュー をクリックします。

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

成功率 が 100 % になるまで待機し、次へ：インスタンスの購入 をクリックします。

[インスタンスの購入] ページで、以下の項目を構成します。

ステップ 9：移行の開始

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

2. 購入および開始 をクリックし、確認メッセージで OK をクリックします。

移行の進行状況は、データ移行 ページで確認できます。