PolarDB:PolarDB\ for\ MySQL\ への自己管理\ MySQL\ データベースの移行

ステップ 1：データ移行ページを開く

以下のいずれかの方法を使用します。

DTS コンソール

1. DTS コンソール にログインします。

2. 左側のナビゲーションウィンドウで、データ移行 をクリックします。

3. 画面左上隅で、移行インスタンスを配置するリージョンを選択します。

DMS コンソール

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

2. 上部のナビゲーションバーで、データ開発 > DTS (DTS) > データ移行 の順にポイントします。

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

ステップ 2：移行タスクの作成

1. タスクの作成 をクリックします。

2. 右上隅に 新規設定ページ ボタンが表示された場合は、それをクリックして新規設定ページに切り替えます。

   説明

   代わりに 以前のバージョンに戻る ボタンが表示されている場合は、すでに新規設定ページにいます。このステップはスキップしてください。

ステップ 3：ソースおよびターゲットデータベースの構成

以下の表に従ってパラメーターを構成します。

ソースデータベース

ターゲットデータベース

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

ページ下部の 接続性のテストと続行 をクリックし、DTS サーバーの CIDR ブロック ダイアログボックスで 接続性のテスト をクリックします。

ステップ 5：移行対象および移行タイプの選択

オブジェクトの構成 ページで、以下のパラメーターを構成します。

パラメーター	説明
移行タイプ	一括移行の場合は、スキーマ移行 および 完全なデータ移行 を選択します。ダウンタイムを最小限に抑える移行を行う場合は、増分データ移行 も選択します。 増分データ移行 を選択しない場合、データ整合性を維持するため、移行中はソースデータベースへの書き込みをすべて停止する必要があります。
ソースデータベースのトリガーの移行方法	トリガーの移行方法を選択します。このパラメーターは スキーマ移行 が選択されている場合のみ利用可能です。「ソースデータベースからのトリガーの同期または移行」をご参照ください。
競合するテーブルの処理モード	事前チェックおよびエラー報告オブジェクト名マッピング（デフォルト）：ソースおよびターゲットに同一のテーブル名が存在する場合、事前チェックに失敗します。開始前に を使用して競合するテーブルをリネームしてください。エラーを無視して続行：チェックをスキップします。完全なデータ移行中は、ターゲットの既存レコードが保持され、増分データ移行中は上書きされます。慎重に使用してください。
イベントの移行の有無	イベントを移行するかどうかを指定します。移行する場合は、追加の手順を実行してデータの不整合を回避する必要があります。「イベントの同期または移行」をご参照ください。
ターゲットインスタンスにおけるオブジェクト名の大文字小文字の処理	宛先インスタンスにおけるデータベース名、テーブル名、および列名の大文字小文字のポリシーを設定します。デフォルト: DTS デフォルトポリシー。詳細については、「宛先インスタンスにおけるオブジェクト名の大文字小文字の指定」をご参照ください。
ソースオブジェクト	移行対象のオブジェクトを選択し、 アイコンをクリックして 選択済みオブジェクト に移動します。カラム、テーブル、またはスキーマを選択できます。テーブルまたはカラムのみを選択した場合、ビュー、トリガー、およびストアドプロシージャは除外されます。
選択済みオブジェクト	単一のオブジェクトの名前を変更するには、オブジェクトを右クリックします。複数のオブジェクトの名前を一度に変更するには、右上隅の [バッチ編集] をクリックします。「オブジェクト名のマッピング」をご参照ください。条件でデータをフィルターするには、テーブルを右クリックして WHERE 句を指定します。「フィルター条件の指定」をご参照ください。

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

次へ：高度な設定 をクリックし、以下のパラメーターを構成します。

ステップ 7：データ検証の構成（任意）

[データ検証] へ進む をクリックして、ソースと送信先間のデータ整合性を確認するデータ検証タスクを設定します。詳細については、「データ検証タスクの設定」をご参照ください。

ステップ 8：事前チェックの実行およびインスタンスの購入

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

   説明

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

2. 事前チェックの完了を待ちます。いずれかの項目が失敗した場合は、詳細の表示 をクリックして原因を確認し、問題を修正してから再度事前チェックを実行します。事前チェック項目が無視可能なアラートをトリガーした場合は、アラートの詳細の確認 をクリックし、その後 無視、OK の順にクリックしてから、再度事前チェックを実行します。アラートを無視すると、データの不整合が発生する可能性があります。

3. 成功率 が 100% に達した場合、次へ：インスタンスの購入 をクリックします。

4. インスタンスの購入 ページで、以下のパラメーターを構成します。

   パラメーター	説明
   リソースグループ	移行インスタンスのリソースグループです。デフォルト値：デフォルトリソースグループResource Management とは
   インスタンスクラス	インスタンスクラスによって移行速度が決まります。要件に基づいて選択してください。詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。

5. Data Transmission Service（従量課金）サービス利用規約 をお読みになり、同意した上で、購入および開始 > OK をクリックします。

移行タスクが開始されます。データ移行 ページで進行状況を監視できます。

ソースデータベースの制限事項

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

• 移行対象のテーブルには、プライマリキーまたはすべてのフィールドが一意である一意制約（UNIQUE constraint）が必要です。これらの制約がない場合、ターゲットデータベースに重複レコードが含まれる可能性があります。

• テーブルを移行対象として選択し、ターゲットでテーブル名またはカラム名を変更する予定がある場合、1 つのタスクで移行できるテーブル数は最大 1,000 個です。この制限を超えるタスクはリクエストエラーを返します。大規模な移行は複数のタスクに分割するか、データベース全体を移行してください。

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

• 完全なデータ移行のみを実行する場合、移行中はソースデータベースへの書き込みを停止してください。これによりデータ整合性が確保されます。最良の結果を得るには、スキーマ移行、完全なデータ移行、および増分データ移行を同時に選択することを推奨します。

外部キーの動作

• スキーマ移行中、DTS はソースからターゲットへ外部キーを移行します。

• 完全なデータ移行および増分データ移行中、DTS はセッションレベルで外部キー制約チェックおよびカスケード操作を一時的に無効化します。この期間中にソースデータベースで実行されたカスケード更新および削除操作は、データの不整合を引き起こす可能性があります。

一般的な制限事項

• 互換性を確保するため、ソースおよびターゲットの MySQL バージョンは一致している必要があります。

• ピーク時間帯を避けて移行を行ってください。完全なデータ移行では、両方のデータベースの読み取りおよび書き込みリソースが使用され、データベースサーバーの負荷が増加します。

• 完全なデータ移行中の同時 INSERT 操作により、ターゲットでテーブルの断片化が発生します。完全なデータ移行後、ターゲットの表領域はソースよりも大きくなります。

• FLOAT または DOUBLE 型のカラムについては、DTS が ROUND(COLUMN, PRECISION) を使用して値を取得します。精度が指定されていない場合、DTS は FLOAT に対して 38 桁、DOUBLE に対して 308 桁を使用します。開始前に、これが要件を満たしていることを確認してください。

• DATETIME 型から VARCHAR 型へのデータ変換はできません。

• ターゲットデータベースで DDL 文が失敗した場合でも、DTS タスクは実行を継続します。失敗した DDL 文は、タスクログ で確認できます。

• EncDB 機能が有効化された ApsaraDB RDS for MySQL インスタンスをソースデータベースとして使用する場合、完全なデータ移行はサポートされていません。

特殊なケース

• プライマリ/セカンダリ スイッチオーバー — 移行タスク実行中にソースデータベースでプライマリ/セカンダリ スイッチオーバーが発生した場合、タスクが失敗します。

• DML 活動が少ない場合 — 長期間にわたりソースで DML 操作が実行されない場合、移行遅延が不正確になる可能性があります。遅延表示を更新するには、DML 操作を実行してください。データベース全体を移行対象として選択した場合は、1 秒ごとに更新されるハートビートテーブルを作成してください。

• ApsaraDB RDS for MySQL の読み取り専用インスタンス — トランザクションログを記録しない ApsaraDB RDS for MySQL V5.6 の読み取り専用インスタンスは、増分データ移行のソースデータベースとして使用できません。

• PolarDB for MySQL をターゲットとして使用する場合 — ソースデータベース名が PolarDB の命名規則に準拠している場合、DTS はターゲットクラスターにデータベースを自動的に作成します。命名規則に準拠していない場合は、移行タスクの構成前に手動でデータベースを作成してください。「データベースの管理」をご参照ください。PolarDB for MySQL クラスターへの完全なデータ移行では、レート制限はサポートされていません。