Data Transmission Service (DTS) を使用して、PolarDB-X 2.0 インスタンスから PolarDB for MySQL クラスターへデータを移行します。DTS はスキーマ移行、完全なデータ移行、および増分データ移行をサポートしているため、切り替え完了までソースとターゲットの両方のデータベースを同期した状態に保つことで、ゼロダウンタイムでの移行が可能です。
前提条件
開始する前に、以下の条件を満たしていることを確認してください。
MySQL 5.7 と互換性のある PolarDB-X 2.0 インスタンス
PolarDB for MySQL クラスター（従量課金クラスターの購入 または サブスクリプションクラスターの購入）
移行先の PolarDB for MySQL クラスターに、移行元の PolarDB-X インスタンス上の全データサイズを超える十分なストレージ容量が確保されていること
制限事項
ソースデータベース
| 制約 | 詳細 |
|---|---|
| 帯域幅 | ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。帯域幅が不足していると、移行速度が低下します。 |
| プライマリキー | 移行対象のテーブルには、PRIMARY KEY または一意制約（UNIQUE constraint）が設定されており、すべてのフィールド値が一意である必要があります。これを満たさない場合、ターゲットデータベースに重複レコードが生成される可能性があります。 |
| テーブル数（名前変更あり） | テーブルを選択して移行対象とし、ターゲットでテーブル名またはカラム名の変更を行う場合、1 つのタスクで最大 1,000 テーブルまでサポートされます。1,000 テーブルを超える場合は、複数のタスクを構成するか、スキーマレベルでの移行を実施してください。 |
| バイナリログ（増分移行） | バイナリログが有効化されており、binlog_row_image の値が full に設定されている必要があります。この条件を満たさないと、事前チェックが失敗し、タスクを開始できません。 |
| バイナリログの保持期間 | 増分のみの移行の場合：ログを 24 時間以上保持してください。完全移行＋増分移行の場合：ログを最低 7 日間保持してください。保持期間が短すぎると、DTS がバイナリログを読み取れず、タスクの失敗やデータ損失を引き起こす可能性があります。完全移行が完了した後は、保持期間を 24 時間以上に短縮できます。保持要件を満たさない場合、DTS のサービスレベルアグリーメント（SLA）は適用されません。 |
| MySQL 互換性 | PolarDB-X インスタンスは MySQL 5.7 と互換である必要があります。 |
その他の制約
| 制約 | 詳細 |
|---|---|
| 移行ウィンドウ | 完全なデータ移行では、ソースから読み取り、ターゲットへ書き込みを行うため、両方のデータベースサーバーの負荷が高まります。非ピーク時間帯に移行を実施してください。 |
| ターゲットの表領域 | 完全なデータ移行中の同時 INSERT 操作により、ターゲット側のテーブルが断片化（fragmentation）します。完全移行完了後のターゲットの表領域は、ソースよりも大きくなります。 |
| 失敗したタスクの再開 | DTS は失敗したタスクを最大 7 日間自動的に再試行します。ワークロードをターゲットに切り替える前に、失敗した DTS タスクを停止またはリリースしてください。あるいは、ターゲット側の DTS データベースアカウントに対して REVOKE を実行し、書き込み権限を削除してください。切り替え後に失敗したタスクが再開された場合、ソースデータがターゲットデータを上書きする可能性があります。 |
| ハートビート更新 | DTS は定期的にソースデータベース内の dts_health_check.ha_health_check テーブルを更新し、バイナリログの位置を進めます。 |
| ターゲットデータベースの作成 | DTS は、移行先の PolarDB for MySQL クラスター内にデータベースを自動的に作成します。ソースデータベース名が無効な場合、タスク設定前に手動でデータベースを作成してください。詳細については、「データベース管理」をご参照ください。 |
移行中に避けるべき操作
タスクの失敗を防ぐため、移行タスク実行中は以下の操作を行わないでください。
スキーマ移行または完全なデータ移行中に、DDL 操作（スキーマ変更など）を実行しないでください。
完全なデータ移行のみを実行している場合、ソースデータベースへのデータ書き込みを行わないでください。この段階での書き込みは、ソースとターゲット間の不整合を引き起こす可能性があります。
移行中に PolarDB-X インスタンスのネットワークタイプを変更した場合、DTS タスクのネットワーク接続設定を適宜更新してください。
課金
| 移行タイプ | インスタンス構成料金 | インターネットトラフィック料金 |
|---|---|---|
| スキーマ移行と完全なデータ移行 | 無料 | データが Alibaba Cloud からインターネット経由で転送される場合にのみ課金されます。「課金概要」をご参照ください。 |
| 増分データ移行 | 課金されます。「課金概要」をご参照ください。 |
移行タイプ
| タイプ | 移行対象 |
|---|---|
| スキーマ移行 | データベースオブジェクトのスキーマ（テーブル、インデックスなど） |
| 完全なデータ移行 | 選択したオブジェクトに存在するすべての既存データ |
| 増分データ移行 | 完全なデータ移行完了後、DTS はソースデータベースからターゲットデータベースへ増分データを移行します。増分データ移行により、データ移行中に自己管理アプリケーションのサービスを中断することなく、スムーズなデータ移行が可能です。DML 操作（INSERT、UPDATE、DELETE）がサポートされています。 |
必要なデータベースアカウント権限
| データベース | スキーマ移行 | 完全なデータ移行 | 増分データ移行 |
|---|---|---|---|
| PolarDB-X インスタンス | SELECT | SELECT | REPLICATION SLAVE、REPLICATION CLIENT、移行対象オブジェクトに対する SELECT |
| PolarDB for MySQL クラスター | 読み取りおよび書き込み | 読み取りおよび書き込み | 読み取りおよび書き込み |
PolarDB-X インスタンスへの権限付与
PolarDB-X の権限管理の詳細については、「PolarDB-X のデータ同期ツール」をご参照ください。
PolarDB for MySQL クラスターへの権限付与
読み取りおよび書き込み権限を持つデータベースアカウントの作成手順については、「データベースアカウントの作成」をご参照ください。
移行タスクの作成
ステップ 1：データ移行タスクページを開く
Data Management (DMS) コンソール にログインします。
トップナビゲーションバーで、DTS をクリックします。
左側のナビゲーションウィンドウで、DTS (DTS) ＞ データ移行 を選択します。
コンソールのレイアウトは異なる場合があります。詳細については、「シンプルモード」および「ビジネス要件に応じて DMS コンソールを設定する」をご参照ください。または、「新しい DTS コンソールのデータ移行タスクページ」に直接アクセスしてください。
ステップ 2：リージョンの選択
データ移行タスク の横にあるドロップダウンリストから、データ移行インスタンスが配置されているリージョンを選択します。
新しい DTS コンソールでは、左上隅のリージョンを選択します。
ステップ 3：ソースおよびターゲットデータベースの設定
タスクの作成 をクリックし、以下のパラメーターを設定します。
ソースおよびターゲットデータベースの設定後は、ページ上部に表示される制限事項を必ずご確認ください。このステップを省略すると、タスクが失敗したり、データの不整合が発生したりする可能性があります。
ソースデータベース
| パラメーター | 説明 |
|---|---|
| タスク名 | DTS が自動的に名前を生成します。タスクを識別しやすいように、意味のある名前を指定してください。名前は一意である必要はありません。 |
| 既存の DMS データベースインスタンスを選択 | 任意項目です。既存のインスタンスを選択すると、パラメーターが自動的に入力されます。手動で設定することもできます。 |
| データベースタイプ | PolarDB-X 2.0 を選択します。 |
| アクセス方法 | Alibaba Cloud インスタンス を選択します。 |
| インスタンスリージョン | ソース PolarDB-X インスタンスが配置されているリージョン。 |
| インスタンス ID | ソース PolarDB-X インスタンスの ID。 |
| データベースアカウント | ソースインスタンスのデータベースアカウント。詳細については、「必要なデータベースアカウント権限」をご参照ください。 |
| データベースパスワード | データベースアカウントのパスワード。 |
宛先データベース
| パラメーター | 説明 |
|---|---|
| 既存の DMS データベースインスタンスを選択 | 任意項目です。既存のインスタンスを選択すると、パラメーターが自動的に入力されます。手動で設定することもできます。 |
| データベースタイプ | PolarDB for MySQL を選択します。 |
| アクセス方法 | Alibaba Cloud インスタンス を選択します。 |
| インスタンスリージョン | ターゲット PolarDB for MySQL クラスターが配置されているリージョン。 |
| PolarDB クラスター ID | ターゲット PolarDB for MySQL クラスターの ID。 |
| データベースアカウント | ターゲットクラスターのデータベースアカウント。詳細については、「必要なデータベースアカウント権限」をご参照ください。 |
| データベースパスワード | データベースアカウントのパスワード。 |
ステップ 4：接続性のテスト
接続性のテストと続行 をクリックします。
DTS は、そのサーバーの CIDR ブロックを、Alibaba Cloud データベースインスタンスの IP アドレスホワイトリストと、自己管理データベースをホストしている Elastic Compute Service (ECS) インスタンスのセキュリティグループルールに自動的に追加します。 オンプレミスまたはサードパーティプロバイダーでホストされているデータベースの場合、DTS サーバーの CIDR ブロックをデータベースの IP アドレスホワイトリストに手動で追加してください。 CIDR ブロックのリストについては、「オンプレミスデータベースのセキュリティ設定に DTS サーバーの CIDR ブロックを追加する」をご参照ください。
DTS の CIDR ブロックをホワイトリストまたはセキュリティグループルールに追加すると、セキュリティリスクが生じる可能性があります。DTS を使用する前に、アカウント認証情報の保護、公開ポートの制限、API 呼び出しの検証、ホワイトリストルールの定期的な監査、Express Connect、VPN Gateway、または Smart Access Gateway 経由での DTS とデータベースの接続など、適切なセキュリティ対策を講じてください。
ステップ 5：移行対象および移行タイプの選択
以下のパラメーターを設定します。
移行タイプ
| オプション | 使用タイミング |
|---|---|
| スキーマ移行 ＋ 完全なデータ移行 | サービス継続性を要求しない、一度限りのオフライン移行に使用します。移行中は、ソースデータベースへの書き込みを行わないでください。 |
| スキーマ移行 ＋ 完全なデータ移行 ＋ 増分データ移行 | ゼロダウンタイム移行に使用します。DTS は切り替え完了までターゲットを同期した状態に保ちます。 |
増分データ移行 を選択しない場合、移行中はソースデータベースへのデータ書き込みを行わないでください。これにより、データの不整合を防止できます。
競合するテーブルの処理モード
| オプション | 動作 |
|---|---|
| 事前チェックおよびエラー報告 | ソースと送信先で同じ名前のテーブルをチェックします。重複が存在する場合、事前チェックが失敗し、タスクを開始できません。競合するテーブルの名前を変更するには、オブジェクト名マッピング機能を使用します。「オブジェクト名をマップする」をご参照ください。 |
| エラーを無視して続行 | 同名チェックをスキップします。スキーマが一致する場合、重複するプライマリキーを持つレコードはスキップされます。スキーマが異なる場合、特定のカラムが移行されなかったり、タスクが失敗したりする可能性があります。慎重に使用してください。 |
エラーを無視して続行 を選択すると、データの不整合が発生する可能性があります。
ソースオブジェクトおよび選択済みオブジェクト
ソースオブジェクト からカラム、テーブル、またはスキーマを選択し、選択済みオブジェクト に移動します。
テーブルまたはカラムを選択すると、ビュー、トリガー、ストアドプロシージャは移行対象から除外されます。
送信先でオブジェクトの名前を変更するには、[選択済みオブジェクト] でそのオブジェクトを右クリックします。複数のオブジェクトを一度に名前を変更するには、[一括編集] を [選択済みオブジェクト] の右上隅でクリックします。詳細については、「オブジェクト名のマッピング」をご参照ください。
オブジェクト名の変更により、依存オブジェクトの移行が失敗する可能性があります。SQL 条件を使用して行をフィルターするには、選択済みオブジェクト 内で該当オブジェクトを右クリックし、フィルター条件を指定してください。詳細については、「SQL 条件を使用したデータのフィルタリング」をご参照ください。
ステップ 6：高度な設定の構成
次へ：高度な設定 をクリックし、以下のパラメーターを設定します。
| パラメーター | 説明 |
|---|---|
| アラートの設定 | いいえ: アラートを無効化します。はい: アラートを有効化します。アラートのしきい値と連絡先を指定します。詳細については、「DTS タスクを作成するときにモニタリングとアラートを設定する」をご参照ください。 |
| 失敗した接続の再試行時間 | 接続失敗後の DTS の再試行持続時間です。範囲：10～1,440 分。デフォルト：720 分。少なくとも 30 分に設定してください。この時間内に DTS が再接続できた場合、タスクは自動的に再開されます。この時間を超えた場合は、タスクが失敗します。同じソースまたはターゲットを共有するタスク間では、最も短い再試行時間が適用されます。再試行中も DTS インスタンスの課金が発生します。 |
| ETL の構成 | はい: 抽出・変換・書き出し (ETL) 機能を有効にします。コードエディタに処理文を入力します。詳細については、「データ移行またはデータ同期タスクで ETL を設定する」をご参照ください。いいえ: ETL を無効にします。 |
| フォワードおよびリバースタスクのハートビートテーブルに対する SQL 操作の削除有無 | はい：DTS はソースデータベースにハートビート SQL 操作を書き込みません。移行遅延が表示される場合があります。いいえ：DTS はハートビート SQL 操作を書き込みます。ソースデータベースの物理バックアップおよびクローン作成に影響を与える可能性があります。 |
ステップ 7：事前チェックの実行
次へ：タスク設定の保存および事前チェック をクリックします。
このタスク設定の OpenAPI パラメーターを表示するには、次へ：タスク設定の保存および事前チェック 上にカーソルを合わせ、OpenAPI パラメーターのプレビュー をクリックします。
タスクは事前チェックに合格しなければ開始できません。事前チェックが失敗した場合：
各失敗項目の横にある 詳細の表示 をクリックします。
報告された問題を修正します。
再チェック をクリックします。
事前チェック項目でアラートが発生した場合：
無視できないアラートの場合は、問題を修正して再チェックを実行してください。
無視できるアラートの場合は、アラートの詳細の確認 をクリックし、無視 ＞ OK ＞ 再チェック の順にクリックします。アラートを無視すると、データの不整合が発生する可能性があります。
ステップ 8：移行インスタンスの購入
成功率 が 100% になるまで待機し、次へ：インスタンスの購入 をクリックします。
インスタンスの購入 ページで、以下のパラメーターを設定します。
| セクション | パラメーター | 説明 |
|---|---|---|
| 新規インスタンスクラス | リソースグループ | 移行インスタンスのリソースグループ。デフォルト：デフォルトリソースグループResource Management とは。詳細については、「」をご参照ください。 |
| インスタンスクラス | インスタンスクラスによって移行速度が決まります。データ量と時間要件に基づいて選択してください。詳細については、「データ移行インスタンスの仕様」をご参照ください。 |
Data Transmission Service（従量課金）利用規約 を読み、同意のうえ、購入して開始 をクリックします。
タスクはタスクリストに表示されます。完全移行の進行状況はパーセンテージで表示されます。増分移行では、ソースとターゲット間の遅延が表示されます。