Data Transmission Service (DTS) を使用すると、MaxCompute プロジェクトから ApsaraDB RDS for MySQL インスタンスへの 1 回限りの完全移行を実行できます。これには、スキーマ移行とデータ移行の両方が含まれます。DTS は MaxCompute からの増分移行をサポートしていません。タスクを開始する前に、ソースプロジェクトへのすべての書き込みを停止してください。
サポートされる移行タイプ
| 移行タイプ | 対応 |
|---|---|
| スキーマ移行 | はい |
| 完全データ移行 | はい |
| 増分データ移行 | いいえ |
前提条件
開始する前に、以下を確認してください。
MaxCompute プロジェクトを所有する Alibaba Cloud アカウントで作成された AccessKey ペア。詳細については、「AccessKey ペアの作成」をご参照ください。
DTS アクセスを許可するように設定された MaxCompute の IP アドレスホワイトリスト。詳細については、「Alibaba Cloud サービスから MaxCompute へのアクセスを許可するための IP アドレスホワイトリストの設定」をご参照ください。
十分なストレージと、読み取り/書き込み権限を持つデータベースアカウントを備えた移行先 ApsaraDB RDS for MySQL インスタンス。詳細については、「アカウントの作成」および「アカウント権限の変更」をご参照ください。
課金
| 移行タイプ | タスク構成料金 | データ転送料金 |
|---|---|---|
| スキーマ移行と完全データ移行 | 無料 | この例では無料です。料金は、Alibaba Cloud からインターネット経由でデータが転送される場合にのみ適用されます。詳細については、「課金概要」をご参照ください。 |
制限事項
増分移行はサポートされていません。DTS は MaxCompute からの完全データ移行のみをサポートします。タスク開始後にソースプロジェクトに新しいデータを書き込まないでください。タスク開始後に書き込まれたデータは移行されず、データの不整合を引き起こします。
レコードが重複するリスク。MaxCompute はプライマリキー制約をサポートしていません。ネットワークエラーが発生し、DTS がタスクをリトライした場合、プライマリキーのないターゲットテーブルに重複レコードが書き込まれる可能性があります。
自動再開のリスク。移行タスクが失敗した場合、DTS は自動的にタスクを再開します。ワークロードをターゲットデータベースに切り替える前に、タスクを停止またはリリースしてください。そうしないと、再開されたタスクがターゲットに既にあるデータを上書きしてしまいます。
スキーマの不整合。MaxCompute と ApsaraDB RDS for MySQL は異種データベースです。DTS はスキーマ移行後のスキーマの整合性を保証しません。移行を開始する前に、データ型変換の影響を評価してください。詳細については、「異種データベース間のデータ型マッピング」をご参照ください。
移行先表領域の増加。完全移行中の同時 INSERT 操作により、ターゲットテーブルで断片化が発生します。移行完了後、ターゲットの表領域はソースよりも大きくなります。
ANALYZE TABLEまたはOPTIMIZE TABLEを実行して領域を再利用してください。説明OPTIMIZE TABLEは実行中にテーブルをロックします。オフピーク時間帯にスケジュールしてください。パフォーマンスへの影響。DTS は移行中にソースとターゲットの両方で読み取り/書き込みリソースを使用します。両方のデータベースの CPU 使用率が 30% 未満のオフピーク時間帯に移行を実行してください。
ターゲットデータベースの命名：DTS はターゲットデータベースを自動的に作成します。 ソースデータベース名が ApsaraDB RDS for MySQL の命名規則に準拠していない場合は、移行タスクを設定する前に、ターゲットデータベースを手動で作成してください。 「アカウントとデータベースの作成」をご参照ください。
データ移行
ステップ 1：データ移行タスクページに移動
Data Management (DMS) コンソールにログインします。
上部のナビゲーションバーで、[DTS] をクリックします。
左側のナビゲーションウィンドウで、[DTS (DTS)] > [データ移行] を選択します。
説明手順は、DMS コンソールのモードとレイアウトに基づいて異なる場合があります。「シンプルモード」および「DMS コンソールのレイアウトとスタイルをカスタマイズする」をご参照ください。または、新しい DTS コンソールの「データ移行タスクページ」に直接アクセスすることもできます。
ステップ 2：リージョンの選択
[データ移行タスク] の横にあるドロップダウンリストから、移行インスタンスが存在するリージョンを選択します。
新しい DTS コンソールでは、代わりに左上隅でリージョンを選択します。
ステップ 3：移行タスクの作成
[タスクの作成] をクリックします。
任意：右上隅にある [新しい設定ページ] をクリックして、新しい設定ページに切り替えます。
説明代わりに [前のバージョンに戻る] が表示されている場合は、このステップをスキップしてください。新しい設定ページの使用を推奨します。
ステップ 4：ソースデータベースとターゲットデータベースの設定
ソースデータベースとターゲットデータベースに次のパラメーターを設定します。
ソースデータベース (MaxCompute)
| パラメーター | 説明 |
|---|---|
| [タスク名] | タスクの名前。DTS は自動的に名前を割り当てます。識別しやすいように、わかりやすい名前を指定してください。名前は一意である必要はありません。 |
| [DMS データベースインスタンスの選択] | 既存の DMS データベースインスタンスを選択するか、ソースデータベースのパラメーターを手動で設定します。既存のインスタンスを選択すると、DTS は残りのパラメーターを自動的に入力します。 |
| データベース タイプ | [MaxCompute] を選択します。 |
| アクセス方法 | [Alibaba Cloud インスタンス] を選択します。 |
| インスタンス リージョン | ソースの MaxCompute プロジェクトが存在するリージョン。 |
| プロジェクト | ソースの MaxCompute プロジェクトの名前。 |
| [Alibaba Cloud アカウントの AccessKey ID] | MaxCompute プロジェクトを所有する Alibaba Cloud アカウントの AccessKey ID。 |
| [Alibaba Cloud アカウントの AccessKey Secret] | MaxCompute プロジェクトを所有する Alibaba Cloud アカウントの AccessKey Secret。 |
ターゲットデータベース (ApsaraDB RDS for MySQL)
| パラメーター | 説明 |
|---|---|
| [DMS データベースインスタンスの選択] | 既存の DMS データベースインスタンスを選択するか、ターゲットデータベースのパラメーターを手動で設定します。 |
| データベース タイプ | [MySQL] を選択します。 |
| アクセス方法 | [Alibaba Cloud インスタンス] を選択します。 |
| インスタンス リージョン | 移行先の ApsaraDB RDS for MySQL インスタンスが存在するリージョン。 |
| [Alibaba Cloud アカウント間でのデータ複製] | [いいえ] を選択して、現在の Alibaba Cloud アカウント配下のインスタンスを使用します。 |
| RDS インスタンス ID | 移行先の ApsaraDB RDS for MySQL インスタンスの ID。 |
| データベース アカウント | ターゲットデータベースに対する読み取り/書き込み権限を持つデータベースアカウント。 |
| データベースパスワード | データベースアカウントのパスワード。 |
DMS でデータベースを登録するには、DMS コンソールで [テンプレートの作成] をクリックします。詳細については、「Alibaba Cloud データベースインスタンスを登録する」および「サードパーティのクラウドサービスでホストされているデータベースまたは自己管理データベースを登録する」をご参照ください。DTS でデータベースを直接登録するには、[データベース接続] ページまたは新しい構成ページを使用します。詳細については、「データベース接続を管理する」をご参照ください。
ステップ 5：接続テスト
ページ下部の [接続をテストして次へ] をクリックします。
ソースまたはターゲットデータベースが Alibaba Cloud データベースインスタンスである場合、DTS はそのサーバーの CIDR ブロックをインスタンスの IP アドレスホワイトリストに自動的に追加します。 ソースまたはターゲットデータベースが Elastic Compute Service (ECS) インスタンスでホストされている自己管理データベースである場合、DTS は DTS サーバーの CIDR ブロックを ECS インスタンスのセキュリティグループルールに自動的に追加します。この場合、ECS インスタンスがデータベースにアクセスできることを確認する必要があります。 自己管理データベースが複数の ECS インスタンスでホストされている場合、各 ECS インスタンスのセキュリティグループルールに DTS サーバーの CIDR ブロックを手動で追加する必要があります。 データセンターでホストされている、またはサードパーティのクラウドサービスによって提供されている自己管理データベースの場合、DTS サーバーの CIDR ブロックをデータベースのホワイトリストに手動で追加する必要があります。 詳細については、「DTS サーバーの CIDR ブロック」をご参照ください。
DTS サーバーの CIDR ブロックをデータベースのホワイトリストまたは ECS のセキュリティグループルールに追加すると、セキュリティリスクが生じます。DTS を使用する前に、次の予防措置を講じてください：ユーザー名とパスワードを強化し、公開ポートを制限し、API 呼び出しを認証し、ホワイトリストとセキュリティグループルールを定期的に確認し、不正な CIDR ブロックを削除します。ネットワークレベルの分離には、Express Connect、VPN Gateway、または Smart Access Gateway を使用してデータベースを DTS に接続してください。
ステップ 6：権限の付与と接続の確認
[OK] をクリックして DTS の組み込みアカウントに MaxCompute プロジェクトへのアクセス権を付与し、次に [接続テスト] をクリックします。
ステップ 7：移行オブジェクトの選択
[オブジェクトの選択] ページで、次のパラメーターを設定します。
| パラメーター | 説明 |
|---|---|
| [移行タイプ] | [スキーマ移行] と [完全データ移行] の両方を選択します。 |
| [競合するテーブルの処理モード] | [事前チェックとエラー報告]（デフォルト）：ソースと送信先で同名のテーブルをチェックします。競合が検出された場合、事前チェックは失敗し、タスクの開始が阻止されます。競合を解決するには、オブジェクト名マッピングを使用して、移行されるテーブルの名前を変更してください。[エラーを無視して続行]：同名チェックをスキップします。ソースと送信先のスキーマが同一の場合、一致するプライマリキーを持つレコードはスキップされます。スキーマが異なる場合、特定の列のみが移行されるか、タスクが完全に失敗します。注意して使用してください。 |
| 送信先インスタンスにおけるオブジェクト名の大文字小文字の区別 | ターゲットでのデータベース名、テーブル名、列名の大文字/小文字の区別ポリシー。デフォルト：[DTS のデフォルトポリシー]送信先インスタンスにおけるオブジェクト名の大文字小文字の指定。詳細については、「」をご参照ください。 |
| [ソースオブジェクト] | 移行するプロジェクトまたはテーブルを選択し、矢印アイコンをクリックして [選択したオブジェクト] に追加します。 |
| [選択したオブジェクト] | 単一オブジェクトの名前を変更するには、そのオブジェクトを右クリックします。「単一オブジェクトの名前をマップする」をご参照ください。複数のオブジェクトを一度に名前を変更するには、[バッチ編集] をクリックします。「複数のオブジェクト名をマップする」をご参照ください。条件でデータをフィルターするには、テーブルを右クリックしてフィルター条件を指定します。「フィルター条件を設定する」をご参照ください。 |
オブジェクト名マッピングを使用してオブジェクトの名前を変更すると、それに依存する他のオブジェクトの移行が失敗する可能性があります。
ステップ 8：詳細設定
[次へ: 詳細設定] をクリックし、次のパラメーターを設定します。
| パラメーター | 説明 |
|---|---|
| [タスクのスケジュールに使用する専用クラスターを選択] | DTS はデフォルトで共有クラスターを使用します。移行の安定性を向上させるには、専用クラスターを購入してください。詳細については、「DTS 専用クラスターとは」をご参照ください。 |
| [失敗した接続のリトライ時間] | タスク開始後、DTS が失敗した接続をリトライする時間です。有効な値: 10～1440 分。デフォルト: 720 分。パラメーターは 30 より大きい値に設定することを推奨します。DTS がこのウィンドウ内で再接続した場合、タスクは再開されます。それ以外の場合、タスクは失敗します。複数のタスクが同じソースまたは送信先を共有している場合、最後に設定された値が優先されます。 |
| [ソースおよびターゲットデータベースでその他の問題が発生した場合のリトライ待機時間] | DTS が失敗した DML または DDL 操作をリトライする時間です。有効な値: 1～1440 分。デフォルト: 10 分。パラメーターは 10 より大きく、常に [失敗した接続のリトライ時間] の値より小さく設定することを推奨します。 |
| [完全データ移行のスロットリングを有効にする] | 完全移行中の DTS の読み取り/書き込みリソース使用量を制限し、送信先への負荷を軽減します。有効にすると、[ソースデータベースへの QPS (クエリ/秒)]、[完全データ移行の RPS]、および [完全移行のデータ移行速度 (MB/秒)] を設定します。[完全データ移行] が選択されている場合にのみ利用可能です。 |
| [環境タグ] | DTS インスタンスを識別するためのオプションのタグです。 |
| [ETL の設定] | 抽出・変換・書き出し (ETL) を有効にするかどうか。[はい]アラート通知設定 を行い、データ処理ステートメントを入力します。詳細については、「ETL の設定」をご参照ください。[いいえ] を選択してスキップします。概要については、「ETL とは？ |
| [モニタリングとアラート] | 移行タスクのアラートを設定するかどうか。[はい] を選択して、アラートのしきい値と通知連絡先を設定します。詳細については、「モニタリングとアラートの設定」をご参照ください。 |
ステップ 9：事前チェックの実行
[次へ: タスク設定を保存して事前チェック] をクリックします。
この設定で DTS が使用する API パラメーターを表示するには、[次へ: タスク設定を保存して事前チェック] にカーソルを合わせ、[OpenAPI パラメーターのプレビュー] をクリックします。
DTS は移行タスクを開始する前に事前チェックを実行します。タスクは事前チェックに合格した後にのみ開始できます。
事前チェックが失敗した場合は、失敗した各項目の横にある [詳細の表示] をクリックし、問題を修正して、再度事前チェックを実行します。
事前チェックでアラートが生成された場合は、続行する前に確認してください。アラートを安全に無視できる場合は、[アラート詳細の確認] をクリックし、ダイアログで [無視] をクリックして確認し、[再度事前チェック] をクリックします。
成功率が 100% になるまで待ってから、[次へ: インスタンスの購入] をクリックします。
ステップ 10：移行インスタンスの購入とタスクの開始
[インスタンスの購入] ページで、次のパラメーターを設定します。
セクション パラメーター 説明 [新しいインスタンスクラス] [リソースグループ設定] 移行インスタンスのリソースグループ。デフォルト: [デフォルト リソースグループ]。詳細については、「Resource Management とは？ [インスタンスクラス] インスタンスクラスは、移行速度を決定します。データ量とパフォーマンス要件に基づいて、クラスを選択してください。詳細については、「データ移行インスタンスの仕様」をご参照ください。 [Data Transmission Service (DTS) (従量課金) 利用規約] を読み、同意します。
[購入して開始] をクリックして移行タスクを開始します。タスクリストで進捗を監視します。
次のステップ
移行が完了した後：
ソースの MaxCompute プロジェクトと移行先の ApsaraDB RDS for MySQL インスタンスとの間でデータ整合性を検証します。
ワークロードをターゲットデータベースに切り替える前に、DTS の移行タスクを停止またはリリースします。
移行先の表領域がソースよりも大幅に大きい場合は、
ANALYZE TABLEまたはOPTIMIZE TABLEを実行して領域を再利用します。テーブルロックを避けるため、OPTIMIZE TABLEはオフピーク時間帯にスケジュールしてください。