Data Transmission Service (DTS) を使用して、ダウンタイムを最小限に抑えながら PolarDB for MySQL クラスター間でデータを移行します。DTS では、スキーマ移行、完全なデータ移行、増分データ移行の 3 種類の移行タイプがサポートされており、アプリケーションを移行中にオンラインで稼働させる必要があるかどうかに応じて、これらのタイプを組み合わせて使用できます。
PolarDB for MySQL クラスターは、直接バージョン 8.0 へアップグレードできません。アップグレードするには、新しいバージョン 8.0 のクラスターを作成し、そのクラスターへデータを移行してください。メジャーバージョン間の移行を行う前に、互換性テスト用に従量課金クラスターを作成し、テスト完了後にリリースしてください。
移行戦略の選択
要件に応じて、以下の移行タイプの組み合わせを選択してください。
| 目的 | 選択する移行タイプ | 必要なダウンタイム |
|---|---|---|
| アプリケーションをオフラインにしてデータを移行する | スキーマ移行 ＋ 完全なデータ移行 | あり — 移行開始前にソースへの書き込みを停止する必要があります |
| アプリケーションをオンラインのままデータを移行する | スキーマ移行 ＋ 完全なデータ移行 ＋ 増分データ移行 | なし — 増分移行により送信先が常に同期状態に保たれます |
移行タイプ
スキーマ移行
DTS は、ソースクラスターから送信先クラスターへ、テーブル、ビュー、トリガー、ストアドプロシージャ、ストアドファンクションのスキーマを移行します。
DTS は、ビュー、ストアドプロシージャ、ストアドファンクションの SECURITY 属性を DEFINER から INVOKER に変更します。
DTS はユーザー情報を移行しません。送信先クラスターでビュー、ストアドプロシージャ、またはストアドファンクションを呼び出すために、INVOKER に対して読み取りおよび書き込み権限を付与してください。
外部キーはスキーマ移行時に移行されます。完全なデータ移行および増分データ移行中、DTS はセッションレベルで一時的に外部キー制約チェックおよびカスケード操作を無効化します。移行中にソースでカスケード操作または削除操作を実行すると、データの不整合が発生する可能性があります。
完全なデータ移行
DTS は、ソースクラスターから送信先クラスターへ既存のすべてのデータを移行します。このフェーズ中に並列で INSERT 操作が実行されると、テーブルの断片化が発生するため、移行完了後の送信先の表領域はソースよりも大きくなります。
増分データ移行
完全なデータ移行が完了した後、DTS はソースからの変更を継続的に送信先へ適用します。これにより、両方のクラスターが常時同期状態に保たれ、アプリケーションを移行全体を通してオンラインで稼働させることができます。
増分移行でサポートされる SQL 操作
| 操作タイプ | サポートされる SQL ステートメント |
|---|---|
| DML | INSERT、UPDATE、DELETE |
| DDL | ALTER TABLE、ALTER VIEW、CREATE FUNCTION、CREATE INDEX、CREATE PROCEDURE、CREATE TABLE、CREATE VIEW、DROP INDEX、DROP TABLE、RENAME TABLE、TRUNCATE TABLE |
RENAME TABLE 操作はデータの不整合を引き起こす可能性があります。移行中にテーブル名を変更し、タスクの対象範囲がそのテーブル（データベースではなく）である場合、DTS は当該テーブルのデータ移行を停止します。これを回避するには、個別のテーブルではなくデータベース全体を移行対象として選択し、名前変更前および名前変更後のデータベース名の両方が選択対象に含まれていることを確認してください。
課金
| 移行タイプ | インスタンス構成料金 | インターネットトラフィック料金 |
|---|---|---|
| スキーマ移行 ＋ 完全なデータ移行 | 無料 | Alibaba Cloud 内からインターネット経由で移行する場合に課金されます。詳細については、「課金概要 |
| 増分データ移行 | 課金概要 | — |
制限事項
ソースデータベースの制限事項
| 制限事項 | 詳細 | 回避策 |
|---|---|---|
| アウトバウンド帯域幅 | ソースサーバーには十分なアウトバウンド帯域幅が必要です。帯域幅が不足していると、移行速度が低下します。 | 帯域幅をアップグレードするか、速度制限を有効化してください。 |
| プライマリキーまたは一意制約 | 移行対象のテーブルには、すべてのフィールドが一意となる PRIMARY KEY または UNIQUE 制約が必要です。これを満たさない場合、送信先に重複レコードが含まれる可能性があります。 | 移行前に、各テーブルにプライマリキーまたは一意キーを追加してください。 |
| タスクごとのテーブル数（名前の変更あり） | テーブル（データベースではなく）を移行対象として選択し、送信先でテーブルまたはカラムの名前を変更する場合、1 つのタスクで最大 1,000 個のテーブルをサポートします。1,000 個を超えるとリクエストエラーが発生します。 | 移行を複数のタスクに分割するか、データベース全体を移行対象として選択してください。 |
| バイナリロギング（増分移行） | バイナリロギングを有効化し、loose_polar_log_bin を on に設定する必要があります。設定されていない場合、事前チェックに失敗し、タスクを開始できません。バイナリロギングを有効化すると、ログファイルの保存に伴う課金が発生します。 | 「バイナリロギングを有効化する」および「パラメーターの変更」をご参照ください。 |
| バイナリログの保持期間 | 増分のみのタスクの場合：バイナリログを 24 時間以上保持してください。完全 ＋ 増分のタスクの場合：バイナリログを最低 7 日間保持してください。完全移行が完了した後は、保持期間を 24 時間以上に短縮できます。保持期間が不足していると、タスクの失敗またはデータ損失を引き起こす可能性があり、この要件を満たさない場合、DTS のサービスレベル合意（SLA）保証は適用されません。 | 移行タスクの開始前に、ログの保持期間を設定してください。 |
| スキーマ ＋ 完全移行中の DDL | スキーマ移行または完全なデータ移行中に、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。このような操作はタスクの失敗を引き起こします。 | スキーマ変更は移行ウィンドウ外で実行するようスケジュールしてください。 |
| 完全移行のみ時の書き込み | 完全なデータ移行のみのタスク実行中に、ソースデータベースへデータを書き込まないでください。これにより、ソースと送信先の間にデータの不整合が発生する可能性があります。 | 両方のクラスターを同期状態に保つために増分データ移行を追加するか、開始前にアプリケーションの書き込みを停止してください。 |
その他の制限事項
| 制限事項 | 詳細 |
|---|---|
| MySQL バージョン | 互換性の問題を回避するために、ソースおよび送信先のクラスターで同じ MySQL バージョンを使用してください。 |
| 読み取り専用ノード | ソースクラスター上の読み取り専用ノードは移行できません。 |
| 移行タイミング | 完全なデータ移行では、両方のクラスターの読み取りおよび書き込みリソースが使用され、サーバー負荷が増加する可能性があります。開始前にパフォーマンスへの影響を評価し、非ピーク時間帯に移行を実行してください。 |
| FLOAT および DOUBLE の精度 | DTS は FLOAT および DOUBLE の値を ROUND(COLUMN, PRECISION) を使用して取得します。精度を指定しない場合、DTS は FLOAT に対してデフォルトで 38 桁、DOUBLE に対して 308 桁を使用します。これらのデフォルト値が要件を満たすことを確認してください。 |
| 失敗したタスクの再開 | DTS は失敗したタスクを最大 7 日間自動的に再試行します。アプリケーションを送信先クラスターへ切り替える前に、または直後に、DTS タスクを停止またはリリースしてください。あるいは、追加の保護措置として、送信先に対する DTS の書き込み権限を削除するために REVOKE を実行してください。切り替え後に失敗したタスクが再開された場合、ソースのデータが送信先のデータを上書きします。 |
| オンライン DDL ツール | ソースでオンライン DDL 操作に pt-online-schema-change を使用しないでください。これにより DTS タスクが失敗します。代わりに DMS または gh-ost を使用してください。 |
必要な権限
必要な権限は、選択する移行タイプによって異なります。
| データベース | 完全なデータ移行のみ | 完全なデータ移行 ＋ 増分データ移行 |
|---|---|---|
| ソース PolarDB for MySQL クラスター | 移行対象オブジェクトに対する読み取り権限 | 移行対象オブジェクトに対する読み取り権限 |
| 送信先 PolarDB for MySQL クラスター | 送信先データベースに対する読み取りおよび書き込み権限 | 送信先データベースに対する読み取りおよび書き込み権限 |
送信先クラスターには特権アカウントを使用してください。データベースアカウントの作成手順については、「データベースアカウントの作成」をご参照ください。
増分データ移行の場合、ソースデータベースアカウントにはバイナリロギングへのアクセス権限も必要です。開始前に、バイナリロギングが有効化され、loose_polar_log_bin が on に設定されていることを確認してください。
PolarDB for MySQL クラスター間でのデータ移行
前提条件
開始する前に、以下の条件を満たしていることを確認してください。
ソースおよび送信先の PolarDB for MySQL クラスター。詳細については、「従量課金クラスターの購入」および「サブスクリプションクラスターの購入」をご参照ください。
送信先クラスターに、ソースクラスターのすべてのデータを格納できるだけの空きストレージ容量があること
必要な権限を持つデータベースアカウント（「必要な権限」を参照）
増分データ移行を実行する予定がある場合：ソースクラスターでバイナリロギングが有効化されており、
loose_polar_log_binがonに設定されている必要があります。詳細については、「バイナリロギングの有効化」および「パラメーターの変更」をご参照ください。
ステップ 1：データ移行タスクページへ移動
Data Management (DMS) コンソール にログインします。
トップナビゲーションバーで、DTS をクリックします。
左側のナビゲーションウィンドウで、DTS (DTS) ＞ データ移行 を選択します。
DMS コンソールのナビゲーションは、モードとレイアウトによって異なります。『シンプルモード』および『DMS コンソールのレイアウトとスタイルのカスタマイズ』をご参照ください。また、新しい DTS コンソールで直接『データ移行タスクページ』にアクセスすることもできます。
ステップ 2：リージョンの選択
データ移行タスク の横にあるドロップダウンリストから、データ移行インスタンスが配置されているリージョンを選択します。
新規 DTS コンソールでは、左上隅のリージョンを選択します。
ステップ 3：ソースおよび送信先データベースの構成
タスクの作成 をクリックします。[タスクの作成] ページで、以下のパラメーターを構成します。
ソースおよび送信先の構成後、ページ上部に表示される制限事項を必ずご確認ください。これをスキップすると、タスクが失敗したりデータの不整合が発生したりする可能性があります。
タスク設定
| パラメーター | 説明 |
|---|---|
| タスク名 | タスクの名前です。DTS が自動的に名前を割り当てますが、識別しやすいように意味のある名前を指定することを推奨します。名前は一意である必要はありません。 |
ソースデータベース
| パラメーター | 説明 |
|---|---|
| 既存の DMS データベースインスタンスの選択 | DTS がパラメーターを自動入力できるように、既存のインスタンスを選択するか、空白のままにして手動でパラメーターを構成してください。 |
| データベースタイプ | PolarDB for MySQL を選択します。 |
| アクセス方法 | Alibaba Cloud インスタンス を選択します。 |
| インスタンスリージョン | ソース PolarDB for MySQL クラスターが配置されているリージョンです。 |
| PolarDB クラスター ID | ソース PolarDB for MySQL クラスターの ID です。 |
| データベースアカウント | ソースクラスターのアカウントです。「必要な権限」をご参照ください。 |
| データベースパスワード | データベースアカウントのパスワードです。 |
| 暗号化 | 接続を暗号化するかどうかを指定します。要件に応じて構成してください。「SSL 暗号化の構成」をご参照ください。 |
送信先データベース
| パラメーター | 説明 |
|---|---|
| 既存の DMS データベースインスタンスを選択 | 既存のインスタンスを選択すると、DTS がパラメーターを自動入力します。空白のままにして、パラメーターを手動で設定することもできます。 |
| データベースタイプ | PolarDB for MySQL[PolarDB for MySQL] を選択します。 |
| アクセス方式 | Alibaba Cloud インスタンス[Alibaba Cloud インスタンス] を選択します。 |
| インスタンスリージョン | 送信先の PolarDB for MySQL クラスターが存在するリージョンです。 |
| PolarDB クラスター ID | 送信先の PolarDB クラスターの ID です。 |
| データベースアカウント | 送信先クラスターのアカウントです。特権アカウントを使用してください。「必要な権限」をご参照ください。 |
| データベースパスワード | データベースアカウントのパスワードです。 |
| 暗号化 | 接続を暗号化するかどうかです。要件に基づいて設定します。「SSL 暗号化の設定」をご参照ください。 |
ステップ 4：接続性のテスト
接続性のテストと続行 をクリックします。
DTS は、そのサーバーの CIDR ブロックを、Alibaba Cloud のデータベースインスタンス（例：ApsaraDB RDS for MySQL または ApsaraDB for MongoDB）の IP アドレスホワイトリストおよび、自己管理データベースをホストする Elastic Compute Service (ECS) インスタンスのセキュリティグループルールに自動的に追加します。複数の ECS インスタンスにまたがって展開された自己管理データベースの場合、各インスタンスのセキュリティグループルールに DTS の CIDR ブロックを手動で追加します。オンプレミスデータベースまたはサードパーティのクラウドプロバイダーのデータベースの場合、データベースの IP ホワイトリストに DTS の CIDR ブロックを手動で追加します。CIDR ブロックの完全なリストについては、「オンプレミスデータベースのセキュリティ設定への DTS サーバーの CIDR ブロックの追加」をご参照ください。
DTS サーバーの CIDR ブロックを IP ホワイトリストまたはセキュリティグループに追加すると、セキュリティリスクが発生します。続行する前に、アカウントおよびパスワードのセキュリティ強化、公開ポートの制限、API 呼び出しの認証、ホワイトリストおよびセキュリティグループルールの定期的な監査、およびパブリックインターネットではなく Express Connect、VPN Gateway、または Smart Access Gateway を介して DTS をデータベースに接続するなどの予防措置を講じてください。
ステップ 5：移行対象および移行タイプの選択
移行タイプ
| パラメーター | 説明 |
|---|---|
| 移行タイプ | オフライン移行の場合は、スキーマ移行 および 完全なデータ移行 を選択します。アプリケーションを移行中にオンラインで稼働させるには、増分データ移行 を追加します。 |
| ソースデータベース内のトリガーの移行方法 | トリガーの移行方法です。スキーマ移行 が選択されている場合にのみ表示されます。「ソースデータベースからのトリガーの同期または移行」をご参照ください。 |
競合処理
| オプション | 動作 |
|---|---|
| 事前チェックおよびエラー報告 | 移行が開始される前に、DTS は送信先にソースと同じ名前のテーブルがあるかどうかをチェックします。名前の競合がある場合、事前チェックは失敗し、タスクは開始されません。必要に応じて、オブジェクト名マッピング機能を使用してオブジェクトの名前を変更します。詳細については、「オブジェクト名のマッピング」をご参照ください。 |
| エラーを無視して続行 | 名前競合の事前チェックをスキップします。ソースと送信先のスキーマが同一の場合、DTS は主キー値が一致する行をスキップします。スキーマが異なる場合、特定のカラムのみが移行されるか、タスクが失敗します。慎重に使用してください。 |
オブジェクトの選択
[ソースオブジェクト] セクションで、移行するオブジェクトを選択し、
をクリックして [選択済みオブジェクト] に移動します。 カラム、テーブル、またはスキーマを選択できます。 テーブルまたはカラムを選択すると、ビュー、トリガー、およびストアドプロシージャが移行から除外されます。
[選択されたオブジェクト]では、次の操作が可能です：
単一オブジェクトの名前変更: オブジェクトを右クリックして名前を変更します。詳細については、「単一のオブジェクトの名前をマップする」をご参照ください。
複数のオブジェクトの名前を変更するには、[一括編集] をクリックします。「複数のオブジェクト名を一度にマッピングする」をご参照ください。
条件による行のフィルタリング：オブジェクトを右クリックして WHERE 句を指定します。「SQL 条件を使用したデータのフィルタリング」をご参照ください。
移行対象の SQL 操作の制限：オブジェクトを右クリックして、含める SQL 操作を選択します。
オブジェクトの名前変更により、ビューまたはストアドプロシージャなどの依存オブジェクトが移行中に失敗する可能性があります。
ステップ 6：高度な設定の構成
次へ：高度な設定 をクリックし、以下の設定を構成します。
データ検証
ソースと送信先間のデータ整合性を検証するには、データ検証機能を設定します。詳細については、「データ検証を有効にする」をご参照ください。
高度な設定
| パラメーター | 説明 |
|---|---|
| タスクのスケジュールに使用する専用クラスターの選択 | デフォルトでは、DTS は共有クラスターを使用します。タスクのリソースを分離するには、専用クラスターを購入してください。詳細については、「DTS 専用クラスターとは |
| アラートの設定 | タスクの失敗またはレイテンシーしきい値の超過に対するアラート機能を設定します。[はい] を選択して、アラートのしきい値と連絡先を指定します。詳細については、「モニタリングとアラートの設定」をご参照ください。 |
| 送信先データベースのエンジンタイプの選択 | 送信先クラスターのストレージエンジン：InnoDB（デフォルト）または X-Engine（オンライントランザクション処理（OLTP）エンジン）。 |
| ソーステーブルで生成されたオンライン DDL ツールの一時テーブルを送信先データベースへコピーする。 | オンライン DDL ツールによって生成された一時テーブルを DTS が移行するかどうかを制御します。 重要 pt-online-schema-change はサポートされていません — 使用するとタスクが失敗します。選択肢： はい（一時テーブルのデータを移行；移行時間が延長される可能性あり）、いいえ、DMS オンライン DDL に準拠（一時テーブルをスキップ；DMS から元の DDL のみを移行 — 送信先テーブルがロックされる可能性あり）、いいえ、gh-ost に準拠（一時テーブルをスキップ；gh-ost から元の DDL のみを移行 — 送信先テーブルがロックされる可能性あり；シャドウテーブルをフィルタリングするためのカスタム正規表現をサポート）。 |
| 失敗した接続の再試行時間 | タスク開始後に、DTS が失敗した接続を再試行する時間です。範囲：10～1,440 分。デフォルト：720 分。少なくとも 30 分に設定してください。複数のタスクが同じソースまたは送信先を共有する場合、最も短い再試行時間が優先されます。再試行期間中は、DTS インスタンスに対して課金されます。 |
| ソースおよび送信先データベースでその他の問題が発生した際の再試行待ち時間。 | DTS が失敗した DDL または DML 操作を再試行する時間です。範囲：1～1,440 分。デフォルト：10 分。少なくとも 10 分に設定してください。この値は、失敗した接続の再試行時間 の値より小さくする必要があります。 |
| 完全なデータ移行の速度制限の有効化 | 完全なデータ移行中に、ソースおよび送信先の読み取り／書き込み負荷を制限します。ソースデータベースへのクエリ数（QPS）、完全なデータ移行の RPS、および 完全移行のデータ移行速度（MB/s） を構成します。完全なデータ移行 が選択されている場合にのみ表示されます。 |
| 増分データ移行の速度制限の有効化 | 増分移行中の負荷を制限します。増分データ移行の RPS および 増分移行のデータ移行速度（MB/s） を構成します。増分データ移行 が選択されている場合にのみ表示されます。 |
| 環境タグ | DTS インスタンスを識別するためのタグです。要件に応じて選択してください。 |
| ETL の構成 | ETL（抽出・変換・書き出し）変換を適用するかどうか。[はい] を選択して、データ処理文を入力します。「ETL とは何か」および「データ移行またはデータ同期タスクで ETL を設定する」をご参照ください。 |
| 転送および逆再生タスクのハートビートテーブルに対する SQL 操作の削除の有無 | DTS がソースデータベースのハートビートテーブルへ書き込むかどうかを制御します。はい：DTS はハートビートテーブルへ書き込みません。コンソールに移行遅延が表示される可能性があります。いいえ：DTS はハートビートテーブルへ書き込みます。ソースデータベースの物理バックアップおよびクローン作成に影響を与える可能性があります。 |
ステップ 7：設定の保存および事前チェックの実行
次へ：タスク設定の保存および事前チェック をクリックします。
クリックする前に、ボタンにカーソルを合わせて OpenAPI パラメーターのプレビュー をクリックすると、このタスク構成に対応する API パラメーターを確認できます。
DTS はタスク開始前に事前チェックを実行します。事前チェックに失敗した場合：
失敗した項目の横にある 詳細の表示 をクリックし、報告された問題を修正した後、再び事前チェック をクリックします。
事前チェック項目で無視可能な警告が発生した場合：警告の詳細の確認 をクリックし、[詳細の表示] ダイアログボックスで 無視 ＞ OK ＞ 再び事前チェック をクリックします。警告を無視すると、データの不整合が発生する可能性があります。
ステップ 8：事前チェックの完了を待機
成功率が 100% になるまで待機し、その後 次へ：インスタンスの購入 をクリックします。
ステップ 9：インスタンスクラスの選択
[インスタンスの購入] ページで、移行タスク用のインスタンスを構成します。
| パラメーター | 説明 |
|---|---|
| リソースグループ | 移行インスタンスのリソースグループ。 デフォルト： デフォルトリソースグループ。 詳細については、「Resource Management とは |
| インスタンスクラス | インスタンスクラスによって移行速度が決まります。 データ量と時間要件に基づいて選択してください。 詳細については、「データ移行インスタンスの仕様」をご参照ください。 |
ステップ 10：サービス利用規約の承諾
Data Transmission Service（従量課金）サービス利用規約 を読み、チェックボックスをオンにして承諾してください。
ステップ 11：タスクの開始
購入および開始 をクリックします。タスクリストで進行状況を監視できます。
移行後のタスク
移行タスクが完了後：
データ整合性の確認: データ検証機能を使用して、ソースと送信先間のデータ整合性を確認します。「データ検証の有効化」を参照してください。
DTS タスクの停止またはリリース：アプリケーションを送信先クラスターへ切り替える前、または直後に、移行タスクを停止またはリリースしてください。DTS は失敗したタスクを最大 7 日間自動的に再試行します — 切り替え後に再開されたタスクが実行されると、ソースのデータが送信先のデータを上書きします。あるいは、追加の保護措置として、送信先から DTS の書き込み権限を削除するために
REVOKEを実行してください。アプリケーションの切り替え：アプリケーションの接続文字列を更新し、送信先クラスターを指すようにしてください。
クリーンアップ：バージョン互換性テスト用に従量課金クラスターを作成した場合は、現在リリースしてください。
注意事項
DTS は、バイナリログ位置を進めるために、ソースデータベースで定期的に CREATE DATABASE IF NOT EXISTS \`test\` を実行します。