Data Transmission Service (DTS) を使用すると、異なるデータソース間でデータを移行できます。これには、Alibaba Cloud への移行、Alibaba Cloud 内のインスタンス間移行、およびデータベースの分割やスケールアウトのシナリオが含まれます。本トピックでは、ソースおよびターゲットの両方に ApsaraDB RDS for MySQL インスタンスを使用して、DTS 専用クラスターでデータ移行タスクを構成する方法について説明します。
前提条件
開始前に、以下の要件を満たしていることを確認してください。
DTS 専用クラスター。詳細については、「DTS 専用クラスターの作成」をご参照ください。
ソースおよびターゲットの ApsaraDB RDS for MySQL インスタンス。詳細については、「ApsaraDB RDS for MySQL インスタンスの作成」をご参照ください。
ターゲットインスタンスの利用可能なストレージが、ソースインスタンスの合計データサイズよりも大きいこと
（ソースまたはターゲットと DTS 専用クラスターが異なるリージョンにある場合）ソースまたはターゲットインスタンスでインターネットアクセスが有効になっていること
課金
DTS 専用クラスターのリソースに対してのみ課金されます。専用クラスター内で移行タスクを作成しても、追加料金は発生しません。Alibaba Cloud データベースから他のクラウドへデータを移行する場合、発生したインターネットトラフィックに対して課金されます。詳細については、「DTS 専用クラスターの課金」をご参照ください。
移行タイプ
DTS は、目的に応じて組み合わせて使用できる 3 種類の移行タイプをサポートしています。
| 移行タイプ | 機能 | 使用タイミング |
|---|---|---|
| スキーマ移行 | テーブル、ビュー、トリガー、ストアドプロシージャ、関数などのオブジェクトスキーマをソースからターゲットにコピーします。ビュー、ストアドプロシージャ、関数の SECURITY 属性を DEFINER から INVOKER に変更します。ユーザーアカウントは移行されません。INVOKER に必要な読み取りおよび書き込み権限を別途付与してください。 | 送信先スキーマが既に存在する場合を除き、必ずこれを含めてください。 |
| 完全なデータ移行 | ソースからターゲットに既存のすべてのデータをコピーします。 | 初期データの投入にはこのタイプを含めてください。完全移行のみを行う場合は、移行中にソースへの書き込みを行わないでください。 |
| 増分データ移行 | 完全移行完了後、バイナリログを使用してソースからの変更を継続的にターゲットに適用します。これにより、サービス中断なくソースとターゲットを同期状態に保ちます。 | ダウンタイムを最小限に抑え、移行中にサービスを継続したい場合は、このタイプを含めてください。 |
推奨される組み合わせ：アプリケーションを中断せずにデータを移行するには、3 つのタイプすべて（スキーマ移行＋完全なデータ移行＋増分データ移行）を選択してください。ダウンタイムが許容される一時的な移行の場合のみ、完全移行のみ（スキーマ移行＋完全なデータ移行）を使用してください。
増分データ移行でサポートされる 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 |
必要な権限
タスクを開始する前に、DTS が使用するデータベースアカウントに以下の権限を付与してください。
| データベース | スキーマ移行 | 完全なデータ移行 | 増分データ移行 |
|---|---|---|---|
| ソース ApsaraDB RDS for MySQL | SELECT | SELECT | 読み取りおよび書き込み権限 |
| ターゲット ApsaraDB RDS for MySQL | 読み取りおよび書き込み権限 | 読み取りおよび書き込み権限 | 読み取りおよび書き込み権限 |
アカウントを移行する場合は、ソースアカウントに mysql.user、mysql.db、mysql.columns_priv、および mysql.tables_priv に対する SELECT 権限も必要です。ターゲットアカウントには CREATE USER および GRANT OPTION 権限が必要です。システムアカウント（root、mysql.infoschema、mysql.session、mysql.sys）およびターゲットにすでに存在するアカウントは移行できません。
アカウントの作成および権限付与の手順については、「ApsaraDB RDS for MySQL インスタンスでのアカウント作成」および「ApsaraDB RDS for MySQL インスタンスでの標準アカウントの権限変更」をご参照ください。
制限事項
スキーマ移行中、DTS は外部キーをソースデータベースからターゲットデータベースに移行します。完全なデータ移行および増分データ移行中、DTS はセッションレベルで外部キー制約チェックおよびカスケード操作を一時的に無効にします。移行中にソースデータベースでカスケード操作または削除操作を実行すると、データの不整合が発生する可能性があります。
| カテゴリ | 制限事項 |
|---|---|
| ソースデータベース | ソースサーバーに十分なアウトバウンド帯域幅がない場合、移行速度が低下します。 |
| テーブルにはプライマリキーまたはすべてのフィールドが一意となる UNIQUE 制約が必要です。これらの制約がない場合、ターゲットデータベースに重複レコードが含まれる可能性があります。 | |
| テーブルを移行オブジェクトとして選択し、ターゲットでテーブル名または列名を変更する必要がある場合、1 つのタスクで最大 1,000 のテーブルをサポートします。この上限を超えるとリクエストエラーが発生するため、複数のタスクに分割するか、データベース全体を移行してください。 | |
増分データ移行の場合：binlog_format を row に設定し、binlog_row_image を full に設定し、バイナリロギングを有効にしてください。自己管理 MySQL データベースがデュアルプライマリクラスターで動作している場合は、DTS がすべてのバイナリログを読み取れるように、log_slave_updates を ON に設定してください。 | |
| 増分移行のみの場合：バイナリログを 24 時間以上保持してください。完全なデータ移行＋増分データ移行の場合：バイナリログを少なくとも 7 日間保持してください。完全移行完了後は、保持期間を 24 時間以上に短縮できます。保持期間が不十分な場合、DTS がバイナリログを取得できず、タスクが失敗したりデータが損失したりする可能性があります。 | |
| スキーマ移行または完全なデータ移行中に DDL 操作を実行しないでください。完全移行のみを行う場合は、ソースデータベースへの書き込みを行わないでください。これらを行うと、データの不整合が発生します。 | |
| その他 | ソースおよびターゲットの MySQL データベースで同じエンジンバージョンを使用してください。 |
| オフピーク時間帯に移行を実行してください。完全なデータ移行では、両方のインスタンスの読み取りおよび書き込みリソースを使用し、サーバーロードが増加します。 | |
| 完全なデータ移行では、同時 INSERT 操作によりターゲットテーブルに断片化が発生します。移行後、ターゲットの表領域はソースの表領域よりも大きくなります。 | |
DTS は ROUND(COLUMN,PRECISION) を使用して FLOAT および DOUBLE 列を読み取ります。デフォルトの精度は、FLOAT が 38 桁、DOUBLE が 308 桁です。これらの精度設定が要件を満たしているか確認してください。 | |
DTS は、失敗したタスクを最大 7 日間自動的にリトライします。ワークロードをターゲットデータベースに切り替える前に、移行タスクを停止またはリリースするか、REVOKE を実行してターゲットに対する DTS の書き込み権限を削除してください。そうしないと、再開されたタスクがターゲットデータをソースデータで上書きしてしまいます。 | |
| 特殊なケース | 自己管理 MySQL の場合：アクティブな移行タスク中にプライマリ/セカンダリのフェールオーバーが発生すると、タスクが失敗します。 |
| 自己管理 MySQL の場合：ソースで長時間 DML 操作が実行されない場合、移行遅延のレポートが正確でなくなる可能性があります。遅延情報を更新するには、DML 操作を実行してください。データベース全体を移行する場合は、毎秒データを書き込むハートビートテーブルを作成してください。 | |
DTS は、バイナリログの位置を進めるために、定期的にソースデータベースで CREATE DATABASE IF NOT EXISTS \test\`` を実行します。 | |
| ApsaraDB RDS for MySQL をターゲットとする場合：DTS は、ソースデータベース名が無効でない限り、ターゲットデータベースを自動的に作成します。名前が無効な場合は、タスク構成前に手動でデータベースを作成してください。 |
移行タスクの構成
構成は、ソースおよびターゲットデータベースの接続、移行オブジェクトの選択、高度な設定の構成、タスクの開始の 4 つのステージで行われます。
ステップ 1：ソースおよびターゲットデータベースの接続
専用クラスターページに移動します。
上部のナビゲーションバーで、ご利用の DTS 専用クラスターが配置されているリージョンを選択します。
クラスターを見つけ、[操作] 列で、[タスクの構成] ＞ [データ移行タスクの構成] を選択します。
構成ページで、先に進む前に上部の [制限事項] 通知を確認します。
[ソースデータベース] のパラメーターを構成します。
パラメーター 説明 タスク名 自動生成されます。タスクを識別するためにわかりやすい名前を指定してください。一意である必要はありません。 既存のデータベース接続を選択（オプション） 既存の接続を選択すると、ソースパラメーターが自動的に入力されます。手動で構成する場合は、この手順をスキップしてください。 データベースタイプ MySQL を選択します。 アクセス方法 Alibaba Cloud インスタンス を選択します。 インスタンスリージョン DTS 専用クラスターによって設定されます。変更できません。 Alibaba Cloud アカウント間でデータを複製 同一アカウントでの移行の場合は、いいえ を選択します。 RDS インスタンス ID ソース ApsaraDB RDS for MySQL インスタンスの ID です。ソースおよびターゲットは同じインスタンスでも構いません。 データベースアカウント 必要な権限 に記載されている権限を持つアカウントです。 データベースパスワード データベースアカウントのパスワードです。 暗号化 [暗号化なし] または [SSL 暗号化] を選択します。SSL 暗号化の場合は、このタスクを開始する前にインスタンスで SSL を設定する必要があります。 [ターゲットデータベース] のパラメーターを構成します。
パラメーター 説明 既存の DMS データベースインスタンスを選択（オプション） 既存の接続を選択すると、ターゲットパラメーターが自動的に入力されます。手動で構成する場合は、この手順をスキップしてください。 データベースタイプ MySQL を選択します。 アクセス方法 Alibaba Cloud インスタンス を選択します。 インスタンスリージョン DTS 専用クラスターによって設定されます。変更できません。 RDS インスタンス ID ターゲット ApsaraDB RDS for MySQL インスタンスの ID です。 データベースアカウント 必要な権限 に記載されている権限を持つアカウントです。 データベースパスワード データベースアカウントのパスワードです。 暗号化 非暗号化 または SSL 暗号化インスタンスで SSL を設定する を選択します。SSL 暗号化を使用する場合は、このタスクを開始する前にしてください。 [接続をテストして続行] をクリックします。 DTS は、サーバーの CIDR ブロックを Alibaba Cloud データベースインスタンスの IP ホワイトリスト、または自己管理データベースをホストする Elastic Compute Service (ECS) インスタンスのセキュリティグループルールに自動的に追加します。 オンプレミスデータセンターまたはサードパーティのクラウド内の自己管理データベースの場合、DTS サーバーの CIDR ブロックをデータベースの IP ホワイトリストに手動で追加します。 詳細については、「DTS サーバーの CIDR ブロックをオンプレミスデータベースのセキュリティ設定に追加する」をご参照ください。
警告IP ホワイトリストまたはセキュリティグループルールに DTS サーバーの CIDR ブロックを追加すると、セキュリティリスクが生じます。先に進む前に、予防措置を講じてください。具体的には、アカウントおよびパスワードのセキュリティを強化し、公開ポートを制限し、API 呼び出しを認証し、IP ホワイトリストおよびセキュリティグループルールを定期的に監査して不正な CIDR ブロックを削除することです。また、Express Connect、VPN Gateway、Smart Access Gateway を使用してデータベースを DTS に接続することを検討してください。
ステップ 2：移行オブジェクトの選択
移行タイプ、競合処理方法、および移行するオブジェクトを構成します。
| パラメーター | 説明 |
|---|---|
| 移行タイプ | 目的に合った組み合わせを選択します。完全移行のみを行う場合は、スキーマ移行 と フルデータ移行 を選択してください。移行中にサービスを継続して実行する場合は、スキーマ移行、フルデータ移行、および 増分データ移行 を選択してください。 |
| 競合テーブルの処理モード | 事前チェックしてエラーを報告：宛先にソースと同じ名前のテーブルが存在するかどうかをチェックします。名前の競合が存在しない場合にのみ、事前チェックは合格となります。競合するテーブルの名前を宛先で変更するには、オブジェクト名マッピングをご利用ください。エラーを無視して続行：名前の競合チェックをスキップします。スキーマが一致する場合、DTS は重複するプライマリキーを持つレコードをスキップします。スキーマが異なる場合、特定の列のみが移行されるか、タスクが失敗します。データの不整合が発生する可能性があるため、注意してご利用ください。 |
| ソースデータベースのトリガー移行方法 | スキーマ移行 を選択した場合にのみ適用されます。要件に基づいて方法を選択してください。詳細については、「ソースデータベースからトリガーを同期または移行する」をご参照ください。 |
| 移行アセスメントの有効化 | スキーマ移行 を選択した場合にのみ適用されます。はい を選択すると、ソースと宛先のスキーマ（インデックス長、ストアドプロシージャ、依存テーブルなど）が移行要件を満たしているかどうかをチェックします。アセスメント結果は事前チェック中に確認できますが、事前チェックの合格／不合格には影響しません。 |
| 宛先インスタンスにおけるオブジェクト名の大文字・小文字の扱い | 宛先のデータベース、テーブル、および列名の大文字・小文字の扱いを制御します。デフォルトは DTS デフォルトポリシー です。詳細については、「宛先インスタンスにおけるオブジェクト名の大文字・小文字の扱いを指定する」をご参照ください。 |
| ソースオブジェクト | ソースオブジェクト リストからオブジェクトを選択し、 アイコンをクリックして 選択済みオブジェクト に追加します。選択可能な粒度は、列、テーブル、またはデータベースです。テーブルまたは列を選択した場合、ビュー、トリガー、ストアドプロシージャは移行対象外となります。 |
| 選択済みオブジェクト | オブジェクトを右クリックして名前を変更したり、WHERE 条件を設定して行をフィルターしたりできます。右上隅の 一括編集 をクリックすると、複数のオブジェクトの名前を一度に変更できます。詳細については、「オブジェクト名マッピング」および「SQL 条件を使用してデータをフィルターする」をご参照ください。オブジェクトの名前を変更すると、依存オブジェクトの移行が失敗する可能性があります。 |
ステップ 3：高度な設定の構成
[次へ：高度な設定] をクリックして、以下の設定を行います。
データ検証
移行後のデータ整合性を確認するには、「データ検証の有効化」をご参照ください。
高度な設定
| パラメーター | 説明 |
|---|---|
| タスクのスケジュールに使用する専用クラスターを選択 | ご利用の DTS 専用クラスターがデフォルトで選択されます。 |
| アラートの設定 | タスクが失敗した場合、または移行遅延がしきい値を超過した場合に通知を受け取るには、[はい] を選択します。アラートのしきい値と連絡先を指定します。詳細については、「DTS タスクを作成する際にモニタリングとアラートを設定する」をご参照ください。 |
| ソーステーブルで生成されたオンライン DDL ツールの一時テーブルをターゲットデータベースにコピー | ソースで Data Management (DMS) または gh-ost を使用してオンライン DDL 操作を実行する場合に適用されます。はい：オンライン DDL で生成された一時テーブルのデータを移行します（大規模なデータセットの場合、移行時間が延長される可能性があります）。いいえ、DMS オンライン DDL に適応：一時テーブルのデータをスキップし、元の DDL のみを移行します。ターゲットのテーブルがロックされる可能性があります。いいえ、gh-ost に適応：一時テーブルのデータをスキップし、元の DDL のみを移行します。gh-ost のシャドウテーブルを除外するために、デフォルトまたはカスタムの正規表現を使用します。ターゲットのテーブルがロックされる可能性があります。 重要 pt-online-schema-change はサポートされていません。使用するとタスクが失敗します。 |
| アカウントを移行するかどうか | はい を選択すると、ソースデータベースのアカウントを移行します。必要な権限 の権限要件をご確認ください。 |
| ソースデータベースのトリガーを移行する方法 | トリガーの移行メソッドを選択します。「ソースデータベースからトリガーを同期または移行する」をご参照ください。 |
| 接続失敗時のリトライ時間 | 接続が失敗した後に DTS がリトライを試行する時間です。有効値：10～1,440 分。デフォルト：720。少なくとも 30 分に設定してください。この時間枠内で再接続が成功すると、DTS はタスクを再開します。共有のソースまたはターゲットインスタンスを複数のタスクで使用している場合、最も最近設定された値がすべてのタスクに適用されます。 説明 DTS が接続をリトライしている間、DTS インスタンスに対して課金されます。この値はビジネス要件に基づいて指定してください。また、ソースおよびターゲットインスタンスをリリースした後は、できるだけ早く DTS インスタンスをリリースすることもできます。 |
| ソースおよびターゲットデータベースでその他の問題が発生した場合のリトライ前の待機時間 | DDL または DML 操作が失敗した後に DTS がリトライを試行する時間です。有効値：1～1,440 分。デフォルト：10。少なくとも 10 分に設定してください。この値は 接続失敗時のリトライ時間 より小さくする必要があります。 |
ステップ 4：事前チェックを実行してタスクを開始
[次へ：タスク設定を保存して事前チェック] をクリックします。このタスクの構成に使用される API パラメーターをプレビューするには、ボタンにカーソルを合わせて [OpenAPI パラメーターをプレビュー] をクリックします。
事前チェックが完了するまで待ちます。事前チェックが失敗した場合は、以下のように対応します。
失敗した項目の場合：[詳細を表示] をクリックして問題を修正し、[再度事前チェック] をクリックします。
無視できないアラート項目の場合：[詳細を表示] をクリックして問題を修正し、[再度事前チェック] をクリックします。
無視可能なアラート項目の場合：[アラートの詳細を確認] ＞ [無視] ＞ [OK] ＞ [再度事前チェック] をクリックします。アラートを無視すると、データの不整合が発生する可能性があります。
成功率が 100 % になったら、[次へ：DTS インスタンスタイプの選択] をクリックします。
[新規インスタンスクラス] セクションで、タスクの インスタンスクラス を設定します。最小値は 1 DTS ユニット (DU)、最大値はクラスター内の残りの利用可能 DU 数です。
[Data Transmission Service (従量課金) サービス利用規約] チェックボックスを読み、選択します。
[タスクを開始] ＞ [OK] をクリックします。
進行状況をモニターするには、クラスター詳細ページに移動し、左側のナビゲーションウィンドウで [クラスタータスクリスト] をクリックします。
次のステップ
タスクが開始され、増分移行が実行中の場合：
[クラスタータスクリスト] で移行遅延をモニターします。ソースの非アクティブにより遅延が高くなっている場合は、DML 操作を実行して遅延情報をリフレッシュします。
アプリケーション トラフィックをターゲットデータベースに切り替える前に、データ検証を使用してデータ整合性を確認します。
ワークロードを切り替える前に、移行タスクを停止またはリリースするか、
REVOKEを実行してターゲットに対する DTS の書き込み権限を削除します。これにより、再開されたタスクがターゲットデータを上書きするのを防ぎます。