Data Transmission Service (DTS) を使用して、ApsaraDB RDS for MariaDB TX インスタンスから ApsaraDB RDS for MySQL インスタンスへデータを移行します。DTS はスキーマ移行、完全なデータ移行、および増分データ移行をサポートしており、ダウンタイムを最小限に抑えながらデータ移行を実行できます。
前提条件
開始する前に、以下の条件を満たしていることを確認してください。
宛先の ApsaraDB RDS for MySQL インスタンスを作成済みであること。詳細については、「ApsaraDB RDS for MySQL インスタンスの作成」をご参照ください。
宛先インスタンスに、ソースインスタンスからのすべてのデータを格納できる十分な空きストレージ容量があること。
データベースアカウントに必要な権限を付与済みであること。「データベースアカウントに必要な権限」をご参照ください。
課金
| 移行タイプ | タスク構成料金 | データ転送料金 |
|---|---|---|
| スキーマ移行および完全なデータ移行 | 無料 | 無料 |
| 増分データ移行 | 課金済み | 「課金概要 |
データベースアカウントに必要な権限
| データベース | スキーマ移行 | 完全なデータ移行 | 増分データ移行 |
|---|---|---|---|
| ソース ApsaraDB RDS for MariaDB TX インスタンス | 移行対象のオブジェクトに対する SELECT | 移行対象オブジェクトに対する読み取りおよび書き込み権限 | 移行対象オブジェクトに対する読み取りおよび書き込み権限 |
| 宛先 ApsaraDB RDS for MySQL インスタンス | 宛先データベースに対する読み取りおよび書き込み権限 | 宛先データベースに対する読み取りおよび書き込み権限 | 宛先データベースに対する読み取りおよび書き込み権限 |
アカウントの作成および必要な権限の付与手順については、以下をご参照ください。
ApsaraDB RDS for MariaDB TX:「アカウントの作成」および「アカウント権限の変更またはリセット」
ApsaraDB RDS for MySQL:「アカウントの作成」および「アカウント権限の変更」
増分移行でサポートされる 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 は、スキーマ移行時にソースデータベースから宛先データベースへ外部キーを移行します。完全なデータ移行および増分データ移行中には、DTS はセッションレベルで一時的に外部キー制約チェックおよびカスケード操作を無効化します。移行中にソースデータベースでカスケード操作または削除操作を実行すると、データの不整合が発生する可能性があります。
ソースデータベースの要件
| 要件 | 詳細 |
|---|---|
| 帯域幅 | ソースサーバーには十分なアウトバウンド帯域幅が必要です。帯域幅が不足していると、移行速度が低下します。 |
| テーブル制約 | テーブルにはプライマリキーまたは一意制約 (UNIQUE constraint) が設定されている必要があり、すべてのフィールドが一意である必要があります。これらの制約がない場合、宛先データベースに重複レコードが含まれる可能性があります。 |
| テーブル数の上限 | テーブルを移行オブジェクトとして選択し、宛先データベースでテーブル名を変更する場合、1 つの移行タスクで最大 1,000 個のテーブルをサポートします。1,000 個を超えるテーブルを移行する場合は、タスクを分割するか、データベース全体を移行オブジェクトとして選択してください。 |
| DDL 操作 | スキーマ移行および完全なデータ移行中は、ソースデータベースで DDL 操作を実行しないでください。 |
| 書き込み操作 | 完全なデータ移行のみ(増分移行なし)を実行する場合、移行中にソースデータベースへの書き込みを行わないでください。データ整合性を確保するためには、スキーマ移行、完全なデータ移行、および増分データ移行を同時に選択することを推奨します。 |
増分データ移行のためのバイナリログ要件
増分データ移行を有効化するには、ソースインスタンスで以下のパラメーターを設定してください。
| パラメーター | 必須値 | 理由 |
|---|---|---|
| バイナリログ記録 | 有効 | DTS は、増分移行のためにバイナリログから変更を読み取ります。 |
binlog_format | row | ロウベース形式は、DTS が要求する完全なロウレベルの変更を記録します。 |
binlog_row_image | full | フルイメージは、各ロウ変更の前後の値を記録します。 |
バイナリログの保存期間は、移行タイプに応じて設定してください。
増分移行のみ:バイナリログを 24 時間以上保持してください。
完全なデータ移行+増分データ移行:バイナリログを最低 7 日間保持してください。完全なデータ移行が完了後は、保存期間を 24 時間以上に短縮できます。
DTS が必要なバイナリログを取得できない場合、タスクは失敗するか、データ損失が発生する可能性があります。上記の最低限の保存期間を下回る設定は、DTS のサービスレベルアグリーメント (SLA) を無効化します。
その他の制限事項
タイミング:開始前に、ソースおよび宛先データベースのパフォーマンスへの影響を評価してください。ピーク時間帯を避けて移行を実行してください。完全なデータ移行では、両方のインスタンスで読み取りおよび書き込みリソースが消費されます。
表領域サイズ:完全なデータ移行中の同時 INSERT 操作により、宛先テーブルで断片化が発生します。移行後、宛先の表領域は通常、ソースよりも大きくなります。
FLOAT および DOUBLE の精度:DTS は
ROUND(COLUMN,PRECISION)を使用して FLOAT および DOUBLE 列の値を取得します。精度が指定されていない場合、DTS は FLOAT に対して 38 桁、DOUBLE に対して 308 桁を使用します。これらのデフォルト値が要件を満たすことを確認してください。失敗したタスクの再開:DTS は、失敗した移行タスクを最大 7 日間再試行します。ワークロードを宛先データベースに切り替える前に、失敗したタスクを停止または解放してください。あるいは、宛先データベース上の DTS アカウントの書き込み権限を取り消すために、
REVOKE文を実行してください。そうしないと、再開された失敗タスクが宛先データベースのデータを上書きする可能性があります。送信先での DDL 失敗: DDL 文がターゲットデータベースで失敗した場合、DTS タスクは実行を継続します。失敗した DDL 文を確認するには、タスクログを確認してください。詳細については、「タスクログの表示」をご参照ください。
列名の大文字小文字の区別:MySQL の列名は大文字小文字を区別しません。ソースデータベースに、大文字小文字のみが異なる列名を持つ列が存在する場合、移行結果が期待通りでない可能性があります。
移行後の検証:移行が完了したら、
analyze table <table_name>を実行して、データが宛先テーブルに正しく書き込まれていることを確認してください。一部の高可用性 (HA) スイッチオーバーのシナリオでは、データがソースインスタンスのメモリにのみ書き込まれ、データ損失が発生する可能性があります。
移行前のチェックリスト
移行タスクを開始する前に、以下の項目を確認してください。いずれかの項目をスキップすると、タスクが失敗したり、データの不整合が発生したりする可能性があります。
| # | 項目 | 確認方法 |
|---|---|---|
| 1 | 宛先の ApsaraDB RDS for MySQL インスタンスが作成済みであり、十分なストレージ容量があること | RDS コンソールでインスタンスステータスおよびストレージを確認 |
| 2 | データベースアカウントに必要な権限が付与済みであること | 各データベースで SHOW GRANTS FOR '<dts_user>'@'%'; を実行 |
| 3 | ソースインスタンスに十分なアウトバウンド帯域幅があること | モニタリングコンソールで帯域幅使用量を確認 |
| 4 | 移行対象のテーブルにプライマリキーまたは一意制約があること | SHOW CREATE TABLE <table_name>; を実行して確認 |
| 5 | バイナリログ記録が有効になっていること(増分移行のみ) | SHOW VARIABLES LIKE 'log_bin'; を実行 — 値は ON |
| 6 | binlog_format = row(増分移行のみ) | SHOW VARIABLES LIKE 'binlog_format'; |
| 7 | binlog_row_image = full(増分移行のみ) | SHOW VARIABLES LIKE 'binlog_row_image'; |
| 8 | バイナリログの保存期間が要件を満たしていること(増分移行のみ) | RDS パラメーターグループの設定を確認 |
| 9 | スキーマ移行/完全なデータ移行中に DDL 操作を実行しないこと | チームと調整 |
| 10 | ピーク時間帯を避けて移行をスケジュールすること | アプリケーションのトラフィックパターンを確認 |
移行タスクの作成
ステップ 1:データ移行タスクページへ移動
Data Management (DMS) コンソール にログインします。
トップナビゲーションバーで、DTS をクリックします。
左側のナビゲーションウィンドウで、DTS (DTS) > データ移行 を選択します。
あるいは、直接 新しい DTS コンソールのデータ移行タスクページ にアクセスします。コンソールのレイアウトおよび利用可能な操作は異なる場合があります。詳細については、「シンプルモード」および「DMS コンソールのレイアウトとスタイルをカスタマイズする」をご参照ください。
ステップ 2:リージョンの選択
データ移行タスク の横にあるドロップダウンリストから、移行インスタンスが配置されているリージョンを選択します。
新しい DTS コンソールでは、左上隅からリージョンを選択します。
ステップ 3:ソースおよび宛先データベースの構成
タスクの作成 をクリックします。タスクの作成 ページで、ソースおよび宛先データベースを構成します。
進む前に、ページ上部に表示される制限事項を必ずご確認ください。このステップをスキップすると、タスクが失敗したり、データの不整合が発生したりする可能性があります。
ソースデータベース
| パラメーター | 説明 |
|---|---|
| 既存の DMS データベースインスタンスの選択(任意) | 接続パラメーターを自動入力するために既存のインスタンスを選択するか、手動で構成する場合は空白のままにしてください。 |
| データベースタイプ | MariaDB を選択します。 |
| アクセス方法 | Alibaba Cloud インスタンス を選択します。 |
| インスタンスリージョン | ソース ApsaraDB RDS for MariaDB TX インスタンスが配置されているリージョンを選択します。 |
| Alibaba Cloud アカウント間でのデータ複製 | 同一アカウント間の移行の場合は、いいえ を選択します。 |
| インスタンス ID | ソース ApsaraDB RDS for MariaDB TX インスタンスの ID を選択または入力します。 |
| データベースアカウント | ソースインスタンス用のデータベースアカウントを入力します。「データベースアカウントに必要な権限」をご参照ください。 |
| データベースパスワード | データベースアカウントのパスワードを入力します。 |
| 暗号化 | 本例では、非暗号化 を選択します。 |
宛先データベース
| パラメーター | 説明 |
|---|---|
| 既存の DMS データベースインスタンスの選択(任意) | 接続パラメーターを自動入力するために既存のインスタンスを選択するか、手動で構成する場合は空白のままにしてください。 |
| データベースタイプ | MySQL を選択します。 |
| アクセス方法 | Alibaba Cloud インスタンス を選択します。 |
| インスタンスリージョン | 宛先 ApsaraDB RDS for MySQL インスタンスが配置されているリージョンを選択します。 |
| Alibaba Cloud アカウント間でのデータ複製 | 同一アカウント間の移行の場合は、いいえ を選択します。 |
| RDS インスタンス ID | 宛先 ApsaraDB RDS for MySQL インスタンスの ID を選択または入力します。 |
| データベースアカウント | 宛先インスタンス用のデータベースアカウントを入力します。「データベースアカウントに必要な権限」をご参照ください。 |
| データベースパスワード | データベースアカウントのパスワードを入力します。 |
| 暗号化 | 「[非暗号化]」または「[SSL 暗号化]」を選択します。 「[SSL 暗号化]」を選択した場合は、まず宛先インスタンスで SSL 暗号化を有効化してください。 詳細については、「SSL 暗号化機能の設定」をご参照ください。 |
ステップ 4:接続性のテスト
接続性のテストと続行 をクリックします。
DTS は、そのサーバーの CIDR ブロックを自動的に Alibaba Cloud データベースインスタンスの IP アドレスホワイトリスト、および自己管理データベースをホストする Elastic Compute Service (ECS) インスタンスのセキュリティグループルールに追加します。複数の ECS インスタンスまたはオンプレミスデータベース上で実行される自己管理データベースの場合、DTS サーバーの CIDR ブロックを手動で追加する必要があります。詳細については、「オンプレミスデータベースのセキュリティ設定に DTS サーバーの CIDR ブロックを追加する」をご参照ください。
パブリック CIDR ブロックを IP アドレスホワイトリストまたはセキュリティグループルールに追加すると、セキュリティリスクが発生します。DTS を使用する前に、アカウントパスワードの強化、公開ポートの制限、API 呼び出しの認証、IP ホワイトリストおよびセキュリティグループルールの定期的な監査などの予防措置を講じてください。可能であれば、パブリックネットワークアクセスではなく、Express Connect、VPN Gateway、または Smart Access Gateway を使用して DTS に接続してください。
ステップ 5:移行オブジェクトの構成
移行タイプを構成し、移行対象のオブジェクトを選択します。
| パラメーター | 説明 |
|---|---|
| 移行タイプ | ニーズに応じて移行タイプを選択します。 - 完全な移行のみ:スキーマ移行 および 完全なデータ移行 を選択します。 - サービス継続性を確保した移行:スキーマ移行、完全なデータ移行、および 増分データ移行 を選択します。 増分データ移行 を選択しない場合、移行中にソースデータベースへの書き込みを行わないでください。 |
| ソースデータベース内のトリガーの移行方法 | 要件に応じてトリガーの移行方法を選択します。このパラメーターは、スキーマ移行 および 増分データ移行 の両方が選択されている場合にのみ利用可能です。「ソースデータベースからのトリガーの同期または移行」をご参照ください。 |
| 競合するテーブルの処理モード | [事前チェックしてエラーを報告](デフォルト): DTS は、両方のデータベースで同じ名前のテーブルをチェックします。重複が存在する場合、タスクは事前チェックに失敗します。名前の競合を解決するには、オブジェクト名マッピング機能を使用してください。詳細については、「オブジェクト名をマップする」をご参照ください。 エラーを無視して続行:重複名チェックをスキップします。ソースおよび宛先テーブルのスキーマが一致する場合、DTS は主キーが一致するレコードをスキップします。スキーマが異なる場合、特定の列のみが移行されるか、タスクが失敗します。 |
| ソースオブジェクト | ソースオブジェクト セクションから移行対象のオブジェクトを選択し、矢印アイコンをクリックして 選択済みオブジェクト に追加します。列、テーブル、またはデータベースを選択できます。テーブルまたは列を選択した場合、ビュー、トリガー、およびストアドプロシージャは移行対象から除外されます。 |
| 選択済みオブジェクト | 単一オブジェクトの名前を変更するには、[選択済みオブジェクト] でそのオブジェクトを右クリックします。詳細については、「単一オブジェクトの名前をマッピングする」をご参照ください。複数のオブジェクトを一度に名前を変更するには、[一括編集] をクリックします。詳細については、「複数のオブジェクト名を一度にマッピングする」をご参照ください。WHERE 条件でデータをフィルターするには、オブジェクトを右クリックして条件を指定します。詳細については、「フィルター条件を設定する」をご参照ください。オブジェクトに対して移行する DML または DDL 操作を指定するには、オブジェクトを右クリックし、操作を選択します。 |
オブジェクト名マッピング機能を使用してオブジェクトの名前を変更すると、それらに依存する他のオブジェクトの移行が失敗する可能性があります。
ステップ 6:高度な設定の構成
次へ:高度な設定 をクリックします。
| パラメーター | 説明 |
|---|---|
| タスクのスケジュールに使用する専用クラスターの選択 | デフォルトでは、DTS は共有クラスターを使用します。専用クラスターを使用するには、購入して指定します。詳細については、「DTS 専用クラスターとは」をご参照ください。 |
| アラートの設定 | いいえ:アラートは送信されません。はい:モニタリングとアラートの設定タスクが失敗した場合、または移行遅延がしきい値を超えた場合にアラートが送信されます。アラートのしきい値および連絡先を指定してください。「」をご参照ください。 |
| 接続失敗時の再試行時間 | 接続失敗時の再試行ウィンドウです。有効な値:10~1,440 分。デフォルト:720 分。30 分より大きい値を設定してください。DTS が再試行ウィンドウ内に再接続できた場合、タスクは再開されます。そうでない場合、タスクは失敗します。同じソースまたは宛先データベースを共有する複数のタスクでは、最も最近に構成された再試行時間が使用されます。 |
| ソースおよび宛先データベースでその他の問題が発生した際の再試行までの待機時間 | DML または DDL 操作の失敗など、接続以外の問題に対する再試行ウィンドウです。有効な値:1~1,440 分。デフォルト:10 分。10 分より大きい値を設定してください。この値は、接続失敗時の再試行時間 よりも小さくなければなりません。 |
| 完全なデータ移行のスロットリングの有効化 | ソースデータベースへの QPS、完全なデータ移行の RPS、および移行速度(MB/s)を制限し、宛先への負荷を軽減します。完全なデータ移行 が選択されている場合にのみ表示されます。 |
| 増分データ移行のスロットリングの有効化 | 増分移行の RPS および移行速度(MB/s)を制限します。増分データ移行 が選択されている場合にのみ表示されます。 |
| 環境タグ | DTS インスタンスを識別するための任意のタグです。 |
| ETL の構成 | はい:データ処理文を入力するためのコードエディタを開きます。詳しくは、「データ移行または同期タスクでの ETL の構成」および「ETL とは?」をご参照ください。いいえ:ETL の構成をスキップします。 |
ステップ 7:事前チェックの実行
次へ:タスク設定の保存および事前チェック をクリックします。
このタスク構成の OpenAPI パラメーターをプレビューするには、次へ:タスク設定の保存および事前チェック 上にカーソルを合わせ、OpenAPI パラメーターのプレビュー をクリックします。
DTS は、移行タスクを開始する前に事前チェックを実行します。項目が失敗した場合:
失敗した項目の横にある 詳細の表示 をクリックし、エラーメッセージに基づいて問題を修正した後、再チェック をクリックします。
アラート項目の場合:無視できる項目については、アラート詳細の確認 > 無視 > OK をクリックし、その後 再チェック をクリックします。アラートを無視すると、データの不整合が発生する可能性があります。
ステップ 8:移行インスタンスの購入
事前チェックの成功率が100%になるまで待ち、その後 次へ:インスタンスの購入 をクリックします。
インスタンスの購入 ページで、以下の設定を行います。
| セクション | パラメーター | 説明 |
|---|---|---|
| 新規インスタンスクラス | リソースグループ | 移行インスタンスのリソースグループです。デフォルト: デフォルトのリソースグループResource Management とは |
| インスタンスクラス | データ移行インスタンスの仕様必要な移行速度に応じてインスタンスクラスを選択します。「」をご参照ください。 |
Data Transmission Service(従量課金)サービス利用規約 を確認し、チェックボックスを選択して同意した後、購入および開始 をクリックします。
移行タスクが開始され、タスクリストに表示されます。タスクリストからタスクの進行状況を監視できます。
次のステップ
移行タスクが完了したら、宛先インスタンスで analyze table <table_name> を実行して、データが正しく書き込まれていることを確認してください。その後、ワークロードを宛先の ApsaraDB RDS for MySQL インスタンスに切り替えることができます。