Data Transmission Service (DTS) を使用して、ApsaraDB RDS for MySQL インスタンスから PolarDB for MySQL クラスターへ、ダウンタイムを最小限に抑えながらデータを移行します。DTS はスキーマ移行、完全なデータ移行、および増分データ移行をサポートしているため、アプリケーションの稼働を継続したまま移行を実行できます。
本トピックでは、ApsaraDB RDS for MySQL インスタンスをソースとして使用します。他のサポート対象 MySQL ソースについても、同様の手順で実行できます。
サポート対象のソースデータベース
ApsaraDB RDS for MySQL インスタンス
自己管理データベース：
パブリック IP アドレスを持つデータベース
Elastic Compute Service (ECS) 上でホストされているデータベース
Express Connect、VPN Gateway、または Smart Access Gateway 経由で接続されたデータベース
Database Gateway 経由で接続されたデータベース
前提条件
開始する前に、以下の条件を満たしていることを確認してください。
ApsaraDB RDS for MySQL インスタンス。詳細については、「ApsaraDB RDS for MySQL インスタンスの作成」をご参照ください。
PolarDB for MySQL クラスター。詳細については、「従量課金クラスターの購入」または「サブスクリプションクラスターの購入」をご参照ください。
移行先の PolarDB for MySQL クラスターに、ソースインスタンスからのすべてのデータを格納できる十分な空きストレージ容量があること。
必要な権限
移行タスクの設定前に、DTS で使用するデータベースアカウントに以下の権限を付与してください。
| データベース | スキーマ移行 | 完全なデータ移行 | 増分データ移行 |
|---|---|---|---|
| ApsaraDB RDS for MySQL | SELECT | SELECT | REPLICATION SLAVE、REPLICATION CLIENT、SHOW VIEW、SELECT |
| PolarDB for MySQL クラスター | 読み取りおよび書き込み権限 | — | — |
データベースアカウントの作成および権限付与の詳細については、以下のトピックをご参照ください。
ApsaraDB RDS for MySQL インスタンス：「ApsaraDB RDS for MySQL インスタンス上のアカウント作成」および「ApsaraDB RDS for MySQL インスタンス上の標準アカウントの権限変更」
PolarDB for MySQL クラスター：「データベースアカウントの作成」
移行タイプ
DTS では、ニーズに応じて組み合わせ可能な 3 種類の移行タイプがサポートされています。
| 移行タイプ | 機能概要 | 課金対象？ |
|---|---|---|
| スキーマ移行 | スキーマ（テーブル、ビュー、トリガー、ストアドプロシージャ、関数）を移行先にコピーします。 | 無料 |
| 完全なデータ移行 | 既存のすべてのデータを移行先にコピーします。 | 無料 |
| 増分データ移行 | 完全移行完了後、ソースから移行先へ変更を継続的にレプリケートします。 | はい |
推奨： すべての 3 種類を選択してください。この方法により、移行中もアプリケーションを中断することなく継続して稼働させることができます。
スキーマ移行の動作に関する注意事項：
DTS はソースから外部キーを移行先へ移行します。完全移行および増分移行中、DTS はセッションレベルで外部キー制約チェックおよびカスケード操作を一時的に無効化します。この期間中にソースでカスケード操作または削除操作を実行すると、データの不整合が発生する可能性があります。
ビュー、ストアドプロシージャ、および関数については、DTS は SECURITY 属性を DEFINER から INVOKER に変更します。DTS はユーザー情報を移行しません。移行先データベースでビュー、ストアドプロシージャ、または関数を呼び出すには、INVOKER に対して必要な読み取りおよび書き込み権限を付与してください。
増分移行でサポートされる 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 |
課金
| 移行タイプ | インスタンス構成料金 | インターネットトラフィック料金 |
|---|---|---|
| スキーマ移行 ＋ 完全なデータ移行 | 無料 | Alibaba Cloud からインターネット経由で移行する場合にのみ課金されます。詳細については、「課金概要」をご参照ください。 |
| 増分データ移行 | 課金済み。「課金概要」を参照してください。 | — |
制限事項
ソースデータベースの要件
ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。帯域幅が不足していると、移行速度が低下します。
テーブルには PRIMARY KEY または一意制約（すべてのフィールドが一意であるもの）が必要です。これらの制約がないテーブルを使用すると、移行先に重複レコードが生成される可能性があります。
テーブルを移行オブジェクトとして選択し、移行先データベースでテーブル名またはカラム名を変更する必要がある場合、1 つのタスクで最大 1,000 個のテーブルをサポートします。1,000 個を超える場合は、複数のタスクに分割するか、代わりにデータベース全体を移行してください。
スキーマ移行または完全なデータ移行中に、データベースまたはテーブルに対して DDL 操作を実行しないでください。移行中にスキーマが変更されると、タスクが失敗します。
完全なデータ移行のみ（増分データ移行なし）を実行する場合、移行中にソースデータベースへの書き込みを行わないでください。データ整合性を保証するためには、スキーマ移行、完全なデータ移行、および増分データ移行を併用してください。
増分データ移行を含める場合、ソースデータベースはさらに以下の要件を満たす必要があります。
バイナリログが有効化されており、
binlog_formatがrowに設定され、binlog_row_imageがfullに設定されていること。これらの条件を満たさない場合、事前チェックでエラーが返され、タスクを開始できません。重要： デュアルプライマリクラスター内のセルフマネージド MySQL の場合、DTS がすべてのバイナリログをキャプチャできるよう、
log_slave_updatesをONに設定してください。
バイナリログの保持期間：ログ保持期間が短すぎると、DTS がバイナリログを取得できず、タスク失敗やデータ損失につながる可能性があります。サービスレベルアグリーメント（SLA）保証を達成するには、これらの保持期間要件を満たす必要があります。
増分移行のみの場合：24 時間以上保持してください。
完全移行＋増分移行の場合：最低 7 日間保持してください。完全移行完了後は、保持期間を 24 時間以上に短縮できます。
移行先データベースの要件
DTS は PolarDB for MySQL クラスター内に移行先データベースを自動的に作成します。ソースデータベース名が無効な場合、タスク設定前に手動でデータベースを作成してください。詳細については、「データベース管理」をご参照ください。
完全なデータ移行では、スロットリングはサポートされていません。
その他の制限事項
互換性を確保するため、ソースおよび移行先データベースで同じエンジンバージョンを使用してください。
完全なデータ移行では、ソースおよび移行先データベースの読み取り／書き込みリソースが使用されるため、負荷が増加します。ピーク時間帯を避けて移行を実行してください。
同時 INSERT 操作を伴う完全なデータ移行では、移行先でテーブルの断片化が発生します。移行完了後、移行先の表領域はソースよりも大きくなります。
DTS は FLOAT および DOUBLE カラムの読み取りに
ROUND(COLUMN, PRECISION)を使用します。精度を指定しない場合、FLOAT には 38 桁、DOUBLE には 308 桁が使用されます。これらの精度設定が要件を満たすことを確認してください。DTS は失敗したタスクを最大 7 日間再試行します。ワークロードを移行先に切り替える前に、移行タスクを停止またはリリースするか、DTS アカウントの書き込み権限を
REVOKEで削除してください。これを実行しない場合、タスクが自動的に再開され、ソースからのデータが移行先のデータを上書きする可能性があります。
セルフマネージド MySQL ソース専用の制限事項
移行タスク実行中にプライマリ／セカンダリのフェールオーバーが発生すると、タスクが失敗します。
DTS は、移行先で最新に移行されたデータのタイムスタンプとソースの現在時刻との差分に基づいて移行遅延を算出します。ソースで長期間 DML 操作が実行されない場合、報告される遅延が不正確になる可能性があります。遅延を更新するには、ソースで任意の DML 操作を実行してください。データベース全体を移行する場合は、1 秒ごとに更新されるハートビートテーブルを作成してください。
DTS は定期的にソースで
CREATE DATABASE IF NOT EXISTS `test`を実行し、バイナリログファイルの位置を進めます。
移行タスクの作成
ステップ 1：データ移行タスクページへ移動
Data Management (DMS) コンソール にログインします。
トップナビゲーションバーで、DTS をクリックします。
左側ナビゲーションウィンドウで、DTS (DTS) ＞ データ移行 を選択します。
コンソールのレイアウトは異なる場合があります。「シンプルモード」および「ビジネス要件に基づいて DMS コンソールを設定する」をご参照ください。または、直接「データ移行タスクページ」にアクセスしてください。
ステップ 2：リージョンの選択
データ移行タスク の横にあるドロップダウンリストから、移行インスタンスが配置されているリージョンを選択します。
新しい DTS コンソールでは、左上隅のリージョンを選択してください。
ステップ 3：ソースおよび移行先データベースの設定
タスクの作成 をクリックし、以下のパラメーターを設定します。
ソースおよび移行先インスタンスを選択した直後にページ上部に表示される制限事項を必ず確認してください。これにより、タスク失敗およびデータの不整合を防止できます。
タスク設定
| パラメーター | 説明 |
|---|---|
| タスク名 | DTS が自動的に名前を生成します。タスクを識別しやすいように、意味のある名前を指定してください。名前は一意である必要はありません。 |
ソースデータベース
| パラメーター | 説明 |
|---|---|
| 既存の DMS データベースインスタンスの選択 | 設定を再利用するため既存のインスタンスを選択するか、パラメーターを手動で設定してください。 |
| データベースタイプ | MySQL を選択します。 |
| アクセス方法 | Alibaba Cloud インスタンス を選択します。 |
| インスタンスリージョン | ソース ApsaraDB RDS for MySQL インスタンスが配置されているリージョンを選択します。 |
| Alibaba Cloud アカウント間でのデータ複製 | 同一 Alibaba Cloud アカウント内で移行する場合は、いいえ を選択します。 |
| RDS インスタンス ID | ソース ApsaraDB RDS for MySQL インスタンスを選択します。 |
| データベースアカウント | データベースアカウントを入力します。詳細については、「必要な権限」をご参照ください。 |
| データベースパスワード | データベースアカウントのパスワードを入力します。 |
| 暗号化 | [非暗号化] または [SSL 暗号化] を選択します。[SSL 暗号化] を選択した場合は、まずソースインスタンスで SSL を有効にします。「ApsaraDB RDS for MySQL インスタンスの SSL 暗号化を設定する」をご参照ください。 |
宛先データベース
| パラメーター | 説明 |
|---|---|
| 既存の DMS データベースインスタンスの選択 | 設定を再利用するため既存のインスタンスを選択するか、パラメーターを手動で設定してください。 |
| データベースタイプ | PolarDB for MySQL を選択します。 |
| アクセス方法 | Alibaba Cloud インスタンス を選択します。 |
| インスタンスリージョン | 移行先 PolarDB for MySQL クラスターが配置されているリージョンを選択します。 |
| PolarDB クラスターアイディー | 移行先 PolarDB for MySQL クラスターを選択します。 |
| データベースアカウント | データベースアカウントを入力します。詳細については、「必要な権限」をご参照ください。 |
| データベースパスワード | データベースアカウントのパスワードを入力します。 |
ステップ 4：接続性のテスト
ページ下部の 接続性のテストと続行 をクリックします。
DTS は、自動的にそのサーバーの CIDR ブロックを Alibaba Cloud データベースインスタンスのホワイトリストおよび ECS でホストされるデータベースのセキュリティグループルールに追加します。データセンター内またはサードパーティのクラウドプロバイダー上の自己管理データベースの場合、DTS の CIDR ブロックをデータベースのホワイトリストに手動で追加します。詳細については、「オンプレミスデータベースのセキュリティ設定に DTS サーバーの CIDR ブロックを追加する」をご参照ください。
DTS の CIDR ブロックをデータベースのホワイトリストまたはセキュリティグループルールに追加すると、セキュリティリスクが高まります。実行前に、強力な認証情報の使用、公開ポートの制限、API 呼び出しの認証、ホワイトリストエントリの定期監査、および可能であればインターネット接続ではなく Express Connect、VPN Gateway、または Smart Access Gateway の使用など、予防措置を講じてください。
ステップ 5：移行オブジェクトおよび高度な設定の構成
移行タイプ
| 目的 | 選択内容 |
|---|---|
| ダウンタイムありの完全移行 | スキーマ移行 ＋ 完全なデータ移行 |
| ゼロダウンタイム移行（推奨） | スキーマ移行 ＋ 完全なデータ移行 ＋ 増分データ移行 |
増分データ移行を選択しない場合、データ整合性を維持するため、移行中にソースインスタンスへの書き込みを行わないでください。
競合するテーブルの処理モード
| モード | 動作 |
|---|---|
| 事前チェックおよびエラー報告 | ソースと送信先で名前が同じテーブルをチェックします。競合が存在する場合、事前チェックに失敗します。開始前に競合するテーブルの名前を変更するには、オブジェクト名マッピング を使用します。 |
| エラーを無視して続行 | 同名チェックをスキップします。スキーマが一致する場合、同一のプライマリキーを持つレコードはスキップされます。スキーマが異なる場合、一部のカラムのみが移行されるか、タスクが失敗します。 |
エラーを無視して続行 を選択すると、データの不整合が発生する可能性があります。
オブジェクトの選択
ソースオブジェクト セクションから 1 つ以上のオブジェクトを選択し、
をクリックして 選択済みオブジェクト セクションに追加します。
カラム、テーブル、またはスキーマを選択できます。テーブルまたはカラムを選択した場合、ビュー、トリガー、およびストアドプロシージャは移行されません。
単一オブジェクトの名前を変更するには、[選択されたオブジェクト] でそのオブジェクトを右クリックします。詳細については、「単一オブジェクトの名前をマップする」をご参照ください。
複数のオブジェクト名を一括で変更するには、[選択したオブジェクト] の右上隅にある 
をクリックします。 詳細については、「複数のオブジェクト名を一括でマッピングする」をご参照ください。
オブジェクトの名前変更により、依存関係を持つ他のオブジェクトの移行が失敗する可能性があります。
条件による行のフィルターを設定するには、選択済みオブジェクト 内のテーブルを右クリックし、WHERE 句を指定します。詳細については、「SQL 条件によるデータのフィルター」をご参照ください。
テーブルに対して特定の DML または DDL 操作を選択するには、選択済みオブジェクト 内のテーブルを右クリックし、操作を選択します。詳細については、「増分移行でサポートされる SQL 操作」をご参照ください。
高度な設定
| パラメーター | 説明 |
|---|---|
| アラートの設定 | タスクが失敗した場合、または移行遅延がしきい値を超えた場合に通知を受信するには、[はい] を選択します。アラートのしきい値と連絡先を設定します。「DTS タスクの作成時にモニタリングとアラートを設定する」をご参照ください。 |
| 移行先インスタンスにおけるオブジェクト名の大文字小文字の処理 | DTS が宛先でのデータベース名、テーブル名、および列名の大文字小文字をどのように処理するかを制御します。詳細については、「宛先インスタンスでのオブジェクト名の大文字小文字の指定」をご参照ください。 |
| ソーステーブルで生成されたオンライン DDL ツールの一時テーブルを移行先データベースにコピー | DTS がオンライン DDL ツール（DMS または gh-ost）の一時テーブルをどのように処理するかを制御します。 重要 pt-online-schema-change はサポートされていません。使用すると DTS タスクが失敗します。選択肢： はい（一時テーブルのデータを移行しますが、タスクの持続時間が延長される可能性があります）、いいえ、DMS オンライン DDL に適合（元の DDL のみを移行しますが、移行先テーブルがロックされる可能性があります）、いいえ、gh-ost に適合（元の DDL のみを移行しますが、移行先テーブルがロックされる可能性があります）。 |
| 接続失敗時の再試行時間 | 接続失敗後の DTS の再試行時間を指定します。有効範囲：10～1,440 分。デフォルト：720 分。30 分より大きい値を設定してください。この時間内に DTS が再接続できた場合、タスクは自動的に再開されます。 |
再試行時間については、複数のタスクが同一のソースまたは移行先データベースを共有する場合、最も最近設定された値が優先されます。再試行期間中は、インスタンスに対して課金されますので、移行完了後は速やかにインスタンスをリリースしてください。
ステップ 6：事前チェックの実行
次へ：タスク設定の保存と事前チェック をクリックします。
DTS はタスク開始前に事前チェックを実行します。失敗項目を解決するには、以下の手順を実行してください。
失敗項目： 詳細の表示 をクリックして問題を修正し、その後 再事前チェック をクリックします。
無視可能な警告項目： 警告詳細の確認 ＞ 無視 ＞ OK をクリックし、その後 再事前チェック をクリックします。
警告項目を無視すると、データの不整合が発生する可能性があります。
ステップ 7：インスタンスの購入
成功率 が 100％ になったら、次へ：インスタンスの購入 をクリックします。
「[インスタンスの購入]」ページで、データ移行インスタンス用の「[インスタンスクラス]」を選択します。インスタンスクラスが高くなるほど、移行速度が速くなります。詳細については、「データ移行インスタンスの仕様」をご参照ください。
ステップ 8：タスクの開始
Data Transmission Service（従量課金）利用規約を確認・同意した後、購入して開始 をクリックします。
タスクリストで移行の進行状況を確認できます。