すべてのプロダクト
Search

このプロダクト

    PolarDB:自己管理 MySQL データベースから PolarDB for MySQL クラスターへの移行

    ドキュメントセンター

    PolarDB:自己管理 MySQL データベースから PolarDB for MySQL クラスターへの移行

    最終更新日:Apr 30, 2026

    Data Transmission Service (DTS) を使用して、自己管理 MySQL データベースを PolarDB for MySQL クラスターに移行できます。

    前提条件

    注意事項

    説明

    タイプ

    説明

    ソースデータベースの制限

    • 帯域幅の要件：ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、移行速度が低下します。

    • 移行する各テーブルには、プライマリキーまたは一意制約が必要であり、キー列には一意の値が含まれている必要があります。そうでない場合、ターゲットデータベースに重複レコードが表示される可能性があります。

    • 移行オブジェクトとしてテーブルを選択し、列名のマッピングなどで編集する場合、単一の移行タスクでサポートされるテーブルは最大 1,000 個です。この制限を超えると、タスクの送信時にエラーが発生して失敗します。この問題を解決するには、テーブルを複数のタスクに分割するか、データベース全体の移行タスクを設定します。

    • 増分移行が必要な場合は、バイナリロギングを有効にします：

      • `binlog_format` を `ROW` に、`binlog_row_image` を `FULL` に設定します。そうでない場合、事前チェックが失敗し、タスクを開始できません。

        重要

        自己管理 MySQL ソースがデュアルマスタークラスター (各インスタンスがマスターとスレーブの両方として機能する) の場合は、`log_slave_updates` パラメーターを有効にします。これにより、DTS がすべてのバイナリログを読み取れるようになります。

      • RDS for MySQL インスタンスの場合、ローカルバイナリログを少なくとも 3 日間 (7 日間を推奨) 保持します。自己管理 MySQL データベースの場合、ローカルバイナリログを少なくとも 7 日間保持します。DTS がバイナリログにアクセスできない場合、タスクは失敗します。極端な場合、データの不整合やデータ損失が発生する可能性があります。DTS が要求するよりも短いバイナリログ保持期間に起因する問題は、DTS SLA の対象外です。

        説明

        RDS for MySQL インスタンスのローカルバイナリログの保持期間を設定するには、「ローカルログの自動削除」をご参照ください。

    • ソースデータベースで許可されていない操作：

      • スキーマ移行または完全移行中に、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうでない場合、移行タスクは失敗します。

        説明

        完全移行中、DTS はソースデータベースにクエリを実行します。これにより、ソースデータベースでの DDL 操作をブロックする可能性のあるメタデータロックが作成されます。

      • 完全移行のみを実行する場合は、ソースインスタンスに新しいデータを書き込まないでください。そうでない場合、ソースとターゲットのデータに不整合が生じます。リアルタイムでデータの一貫性を保つには、スキーマ移行、完全移行、増分移行を選択します。

    • DTS は、バイナリログに書き込まれない変更によって生成されたデータを移行しません。例としては、物理バックアップから復元されたデータや、カスケード操作によって作成されたデータなどがあります。

      説明

      これが発生した場合、ビジネスで許可された後に完全移行を再実行してください。

    • ソースの MySQL データベースがバージョン 8.0.23 以降で、非表示の隠し列が含まれている場合、DTS はそれらの列を読み取ることができません。これにより、データ損失が発生する可能性があります。

      説明

      非表示列を表示するには、ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; を実行します。詳細については、「非表示列」をご参照ください。

    その他の制限

    • 互換性を確保するために、ソースデータベースとターゲットデータベースで同じ MySQL バージョンを使用することを推奨します。

    • ソースデータベースが一時テーブルモードのオンライン DDL 操作 (複数テーブルのマージシナリオを含む) を使用している場合、または一意キー列に関数ベースインデックスを追加している場合、ターゲットデータベースでデータ損失またはタスクの失敗が発生する可能性があります。

    • DTS は、コメント構文を使用して定義されたパーサーの移行をサポートしていません。

    • 移行中にプライマリキーまたは一意キーの競合が発生した場合：

      • テーブルスキーマに一貫性があり、ターゲットデータベースのレコードがソースデータベースのレコードと同じプライマリキー値を持つ場合：

        • 完全移行中、DTS はターゲットデータベースのレコードを保持します。ソースデータベースからのレコードは移行されません。

        • 増分移行中、DTS はターゲットデータベースのレコードを保持しません。ソースデータベースからのレコードがターゲットデータベースのレコードを上書きします。

      • テーブルスキーマに一貫性がない場合、一部の列のデータのみが移行されるか、移行が失敗する可能性があります。注意して進めてください。

    • 移行前に、ソースデータベースとターゲットデータベースの両方のパフォーマンスを評価してください。ビジネスのオフピーク時間に移行を実行してください。そうでない場合、完全移行は両方のデータベースの読み取りおよび書き込みリソースを消費し、データベースの負荷を増加させます。

    • 完全移行は `INSERT` 操作を同時に実行します。これにより、ターゲットテーブルが断片化されます。完全移行後、ターゲットテーブルはソーステーブルよりも多くのストレージ領域を必要とします。

    • データに 4 バイト文字 (珍しい漢字や絵文字など) が含まれている場合、ターゲットデータベースとテーブルは `utf8mb4` 文字セットを使用する必要があります。

      説明

      DTS を使用してスキーマを移行する場合は、ターゲットデータベースのインスタンスレベルのパラメーター character_set_server を utf8mb4 に設定してください。

    • `FLOAT` または `DOUBLE` 列の DTS 移行精度がビジネス要件を満たしていることを確認してください。DTS はこれらの列を ROUND(COLUMN,PRECISION) を使用して読み取ります。精度が定義されていない場合、DTS は `FLOAT` に 38 桁、`DOUBLE` に 308 桁を使用します。

    • DTS は、失敗したタスクを 7 日以内に回復しようとします。トラフィックをターゲットインスタンスに切り替える前に、タスクを終了またはリリースしてください。または、revoke コマンドを実行して、ターゲットインスタンスアカウントに対する DTS の書き込み権限を削除します。これにより、自動回復によってターゲットデータがソースデータで上書きされるのを防ぎます。

    • DTS は、datetime データを varchar に変換することをサポートしていません。

    • ターゲットデータベースで DDL の書き込みが失敗した場合、DTS タスクは実行を継続します。タスクログで失敗した DDL ステートメントを確認してください。手順については、「タスクログの表示」をご参照ください。

    • ご利用の RDS for MySQL インスタンスで Always-Encrypted が有効になっている場合、完全移行はサポートされません。

      説明

      Transparent Data Encryption (TDE) が有効になっている RDS for MySQL インスタンスは、スキーマ移行、完全移行、および増分移行をサポートします。

    • ソースからデータベースアカウントを移行するには、必要な前提条件を満たし、関連する考慮事項を確認してください。詳細については、「データベースアカウントの移行」をご参照ください。

    • タスクが失敗した場合、DTS サポートスタッフは 8 時間以内に復旧を試みます。復旧中、タスクを再起動したり、パラメーターを調整したりすることがあります。

      説明

      DTS タスクのパラメーターのみが変更され、データベースのパラメーターは変更されません。調整される可能性のあるパラメーターには、「インスタンスパラメーターの変更」に記載されているものが含まれます。

    特殊なケース

    • 自己管理 MySQL ソースの場合：

      • ソースデータベースでのマスター/スタンバイの切り替えにより、移行タスクは失敗します。

      • DTS は、ターゲットデータベースに移行された最後のレコードのタイムスタンプと現在時刻を比較してレイテンシーを計算します。ソースで DML 操作が長時間実行されない場合、レイテンシーの報告が不正確になります。レイテンシーが高すぎるように見える場合は、ソースで DML 操作を実行してレイテンシー値を更新してください。

        説明

        データベース全体の移行を選択した場合は、ハートビートテーブルを作成します。毎秒更新または書き込みを行ってください。

      • DTS は、バイナリログオフセットを進めるために、ソースデータベースで定期的に CREATE DATABASE IF NOT EXISTS `test` を実行します。

      • ソースが Amazon Aurora MySQL または別のクラスター化された MySQL インスタンスである場合、タスクに設定されたドメイン名または IP アドレス、およびその DNS 解決が常に読み取り/書き込み (RW) ノードを指すようにしてください。そうでない場合、移行タスクが失敗する可能性があります。

    • RDS for MySQL ソースの場合：

      • 増分移行が必要な場合、RDS for MySQL 5.6 の読み取り専用インスタンスなど、トランザクションログを記録しない RDS for MySQL インスタンスはソースとしてサポートされません。

      • DTS は、バイナリログオフセットを進めるために、ソースデータベースで定期的に CREATE DATABASE IF NOT EXISTS `test` を実行します。

    • ターゲットデータベースが PolarDB MySQL Edition の場合：

      • DTS は PolarDB for MySQL にデータベースを自動的に作成します。移行するデータベースの名前が PolarDB for MySQL の命名規則に準拠していない場合は、移行タスクを設定する前に PolarDB for MySQL にデータベースを作成する必要があります。関連する操作については、「データベースの管理」をご参照ください。

      • 完全移行のレートは調整できません。

    移行タイプ

    • スキーマ移行

      DTS は、移行オブジェクトのスキーマ定義をソースデータベースからターゲットデータベースに移行します。

      • DTS は、テーブル、ビュー、トリガー、ストアドプロシージャ、および関数のスキーマ移行をサポートしています。

        説明

        ストアドプロシージャの routine_body、関数の routine_body、およびビューの select_statement は変更されません。

      • スキーマ移行中、DTS は移行対象のビュー、ストアドプロシージャ、および関数の `DEFINER` を `INVOKER` に変更します。このアクションにより、`SQL SECURITY` の値が `INVOKER` に変更されます。DTS はまた、`DEFINER` を移行タスクに使用されるターゲットデータベースアカウントに設定します。

        説明

        ソースデータベースのセキュリティ認証メソッドと definer は変更されません。

      • DTS はユーザー情報を移行しないため、ターゲットデータベースでビュー、ストアドプロシージャ、および関数を呼び出すために、invoker に読み取りおよび書き込み権限を付与する必要があります。

    • 完全移行

      DTS は、指定された移行オブジェクトのすべての既存データをソースデータベースからターゲットデータベースに移行します。

    • 増分移行

      完全移行が完了した後、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

      重要

      RENAME TABLE 操作は、データの不整合を引き起こす可能性があります。たとえば、移行オブジェクトとして 1 つのテーブルのみを選択し、移行中にソースインスタンスでテーブルの名前を変更した場合、このテーブルのデータはターゲットデータベースに移行されません。この問題を回避するには、データ移行タスクを設定する際に、テーブルが属するデータベース全体を移行オブジェクトとして選択します。RENAME TABLE 操作の前後にテーブルが属するデータベースが両方とも移行オブジェクトに含まれていることを確認してください。

    • TRUNCATE TABLE

    データベースアカウントの権限

    データベース

    スキーマ移行

    完全移行

    増分移行

    自己管理 MySQL データベース

    SELECT 権限

    SELECT 権限

    移行対象オブジェクトに対する SELECT 権限

    REPLICATION CLIENT、REPLICATION SLAVE、および SHOW VIEW 権限

    データベースとテーブルを作成する権限。これにより、DTS はハートビートデータを保存するための dts データベースを作成できます

    PolarDB for MySQL クラスター

    読み取りおよび書き込み権限

    データベースアカウントを作成して承認するには、次の手順を実行します：

    操作手順

    1. 次のいずれかの方法で、ターゲットリージョンの移行タスクリストページに移動します。

      DTS コンソールから

      1. Data Transmission Service (DTS) コンソールにログインします。

      2. 左側のナビゲーションウィンドウで、データの移行 をクリックします。

      3. ページの左上隅で、移行インスタンスが配置されているリージョンを選択します。

      DMS コンソールから

      説明

      実際の操作は、DMS コンソールのモードとレイアウトによって異なる場合があります。詳細については、「シンプルモードコンソール」および「DMS コンソールのレイアウトとスタイルをカスタマイズする」をご参照ください。

      1. Data Management (DMS) コンソールにログインします。

      2. 上部のメニューバーで、[データ + AI] > [Data Transmission (DTS)] > [データ移行] を選択します。

      3. データ移行タスク の右側で、移行インスタンスが配置されているリージョンを選択します。

    2. タスクの作成 をクリックして、タスク設定ページに移動します。

    3. 任意: ページの右上隅で、新バージョンの設定ページを試してみる をクリックします。

      説明

      • すでに新しい設定ページにいる場合 (右上隅のボタンが 旧バージョンの設定ページに戻る の場合)、この手順はスキップできます。

      • 新しい設定ページと古い設定ページのパラメーターは異なります。新しい設定ページを使用することを推奨します。

    4. ソースデータベースとターゲットデータベースを設定します。

      警告

      ソースインスタンスとターゲットインスタンスを選択した後、ページ上部に表示される制限を注意深くお読みください。そうでない場合、タスクが失敗したり、データの不整合が発生したりする可能性があります。

      カテゴリ

      設定

      説明

      なし

      タスク名

      DTS は自動的にタスク名を生成します。簡単に識別できるように、わかりやすい名前を指定することを推奨します。名前は一意である必要はありません。

      ソースデータベース

      既存の接続情報の選択

      • システムに追加された (作成または保存された) データベースインスタンスを使用するには、ドロップダウンリストから目的のデータベースインスタンスを選択します。以下のデータベース情報が自動的に設定されます。

        説明

        DMS コンソールでは、このパラメーターは DMS データベースインスタンスの選択 という名前です。

      • データベースインスタンスをシステムに登録していない場合、または登録済みのインスタンスを使用する必要がない場合は、以下のデータベース情報を手動で設定します。

      データベースタイプ

      MySQL を選択します。

      アクセス方法

      ソースデータベースがデプロイされている場所に基づいて選択します。このトピックでは、例として Public IP Address を使用します。

      説明

      自己管理データベースが別のインスタンスタイプである場合は、追加の準備を完了してください。詳細については、「準備の概要」をご参照ください。

      インスタンスリージョン

      自己管理 MySQL データベースが存在するリージョンを選択します。

      説明

      最適なネットワークパフォーマンスとアクセス速度を確保するために、クラウドでホストされていない場合でも、自己管理 MySQL データベースに物理的に近いリージョンを選択してください。

      [ホスト名または IP アドレス]

      自己管理 MySQL データベースのエンドポイントを入力します。この例では、パブリック IP アドレスを入力します。

      ポート

      自己管理 MySQL データベースのサービスポートを入力します (パブリックネットワークに公開されている必要があります)。デフォルトは [3306] です。

      データベースアカウント

      自己管理 MySQL データベースのアカウントを入力します。必要な権限については、「データベースアカウントの権限」をご参照ください。

      データベースパスワード

      データベースアカウントのパスワードを入力します。

      暗号化

      必要に応じて 非暗号化 または SSL 暗号化 を選択します。

      • 自己管理 MySQL データベースで SSL 暗号化が有効になっていない場合は、非暗号化 を選択します。

      • 自己管理 MySQL データベースで SSL 暗号化が有効になっている場合は、SSL 暗号化 を選択します。また、CA 証明書 をアップロードし、CA証明書パスワード を入力する必要があります。

      宛先データベース

      既存の接続情報の選択

      • システムに追加された (作成または保存された) データベースインスタンスを使用するには、ドロップダウンリストから目的のデータベースインスタンスを選択します。以下のデータベース情報が自動的に設定されます。

        説明

        DMS コンソールでは、このパラメーターは DMS データベースインスタンスの選択 という名前です。

      • データベースインスタンスをシステムに登録していない場合、または登録済みのインスタンスを使用する必要がない場合は、以下のデータベース情報を手動で設定します。

      データベースタイプ

      PolarDB for MySQL を選択します。

      アクセス方法

      [クラウドインスタンス] を選択します。

      インスタンスリージョン

      ターゲットの PolarDB for MySQL クラスターが存在するリージョンを選択します。

      PolarDB インスタンス ID

      ターゲットの PolarDB for MySQL クラスターの ID を選択します。

      データベースアカウント

      ターゲットの PolarDB for MySQL クラスターのデータベースアカウントを入力します。必要な権限については、「データベースアカウントの権限」をご参照ください。

      データベースパスワード

      データベースアカウントのパスワードを入力します。

      暗号化

      ビジネス要件に基づいてオプションを選択します。SSL 暗号化の詳細については、「SSL 暗号化の設定」をご参照ください。

    5. 設定が完了したら、ページ下部の 接続をテストして続行 をクリックします。表示される DTS サーバーの CIDR ブロック ダイアログボックスで、接続テスト をクリックします。

      説明

      DTS サーバーからのアクセスを許可するために、DTS サービスの IP アドレスセグメントがソースデータベースとターゲットデータベースのセキュリティ設定に自動または手動で追加されていることを確認してください。詳細については、「DTS サーバーの IP アドレスをホワイトリストに追加する」をご参照ください。

    6. タスクオブジェクトを設定します。

      1. オブジェクト設定 ページで、移行するオブジェクトを設定します。

        設定

        説明

        移行タイプ

        • 完全移行のみを実行する必要がある場合は、スキーマ移行 と 完全データ移行 の両方を選択します。

        • ダウンタイムなしで移行を実行するには、スキーマ移行、完全データ移行、および 増分データ移行 を選択します。

        説明

        • スキーマ移行 を選択しない場合は、データを受け取るためのデータベースとテーブルがターゲットデータベースに存在することを確認する必要があります。必要に応じて、選択中のオブジェクト ボックスのオブジェクト名マッピング機能を使用することもできます。

        • 増分データ移行 を選択しない場合は、データの一貫性を確保するために、データ移行中にソースインスタンスに新しいデータを書き込まないでください。

        移行元データベースのトリガーを移行する方法

        必要に応じてトリガーの移行方法を選択します。移行対象のオブジェクトにトリガーが含まれていない場合は、この手順をスキップできます。詳細については、「トリガーの移行方法の設定」をご参照ください。

        説明

        このパラメーターは、移行タイプ に スキーマ移行 が含まれている場合にのみ設定できます。

        競合するテーブルの処理モード

        • エラーの事前チェックと報告：ターゲットデータベースに同じ名前のテーブルが存在するかどうかを確認します。同じ名前のテーブルが存在しない場合、事前チェックは合格します。同じ名前のテーブルが存在する場合、事前チェック中にエラーが報告され、データ移行タスクは開始されません。

          説明

          ターゲットデータベースのテーブルが同じ名前で、簡単に削除または名前変更できない場合は、ターゲットデータベースのテーブルの名前を変更できます。詳細については、「オブジェクト名マッピング」をご参照ください。

        • エラーを無視して続行：同じ名前のテーブルのチェックをスキップします。

          警告

          エラーを無視して続行 を選択すると、データの不整合やビジネスリスクが発生する可能性があります。例：

          • テーブルスキーマに一貫性があり、ターゲットデータベースのレコードがソースデータベースのレコードと同じプライマリキー値を持つ場合：

            • 完全移行中、DTS はターゲットデータベースのレコードを保持します。ソースデータベースからのレコードは移行されません。

            • 増分移行中、DTS はターゲットデータベースのレコードを保持しません。ソースデータベースからのレコードがターゲットデータベースのレコードを上書きします。

          • テーブルスキーマに一貫性がない場合、一部の列のデータのみが移行されるか、移行が失敗する可能性があります。注意して進めてください。

        イベントを移行するかどうか

        移行先インスタンスでのオブジェクト名の大文字化

        ターゲットインスタンスで移行されたオブジェクト (データベース、テーブル、列など) の名前の大文字/小文字の区別ポリシーを設定できます。デフォルトでは、DTS のデフォルトポリシー が選択されています。ソースまたはターゲットデータベースのデフォルトポリシーと大文字/小文字の区別を一致させることも選択できます。詳細については、「ターゲットデータベースのオブジェクト名の大文字/小文字の区別」をご参照ください。

        ソースオブジェクト

        ソースオブジェクト セクションから 1 つ以上のオブジェクトを選択します。Rightwards arrow アイコンをクリックして、オブジェクトを [選択済みオブジェクト] セクションに追加します。

        説明

        移行オブジェクトを選択する粒度は、スキーマ、テーブル、および列です。移行オブジェクトとしてテーブルまたは列のみを選択した場合、ビュー、トリガー、ストアドプロシージャなどの他のオブジェクトはターゲットデータベースに移行されません。

        選択中のオブジェクト
        説明

        • オブジェクト名マッピングを使用すると、依存オブジェクトの移行が失敗する可能性があります。

        • WHERE 句を使用してデータをフィルタリングするには、選択中のオブジェクト ボックスでテーブルを右クリックし、表示されるダイアログボックスでフィルター条件を設定します。詳細については、「フィルター条件の設定」をご参照ください。

        • データベースまたはテーブルレベルで SQL 操作を選択するには、選択中のオブジェクト ボックスでオブジェクトを右クリックし、表示されるダイアログボックスで必要な SQL 操作を選択します。サポートされている操作については、「増分移行でサポートされる SQL 操作」をご参照ください。

      2. 詳細設定へ をクリックして、詳細パラメーターを設定します。

        設定

        説明

        タスクのスケジュールに使用する専用クラスターの選択

        デフォルトでは、DTS は共有クラスターでタスクをスケジュールします。選択する必要はありません。より安定したタスクが必要な場合は、専用クラスターを購入して DTS 移行タスクを実行できます。

        移行先データベースのエンジンタイプを選択します。

        ターゲットデータベースのエンジンタイプを選択します。

        • InnoDB: デフォルトのストレージエンジン。

        • X-Engine：オンラインントランザクション処理 (OLTP) データベースストレージエンジン。

        移行元テーブルで生成された Online DDL ツールの一時テーブルを移行先データベースにコピーします。

        Data Management (DMS) または gh-ost を使用してソースデータベースでオンライン DDL 変更を実行する場合、オンライン DDL 変更によって生成された一時テーブルからデータを移行するかどうかを選択できます。

        重要

        • DTS タスクは、pt-online-schema-change などのツールを使用してオンライン DDL 変更を実行することをサポートしていません。そうしないと、DTS タスクは失敗します。

        • 各フェーズの処理方法は次のとおりです。スキーマ移行 および 完全データ移行 フェーズでは、データベースまたはテーブル構造を変更する DDL 操作は許可されません。したがって、これらはオンライン DDL ポリシーによって制御されません。

          • スキーマ移行：オンライン DDL ポリシーによって制御されません。関連する一時テーブルが作成されます。

          • 完全データ移行：オンライン DDL ポリシーによって制御されません。一時テーブルの移行は完全移行オブジェクトに含まれません。正規表現 (^_(.+)_(?:gho|new)$ または ^_(.+)_(?:ghc|del|old)$) に一致する名前のすべてのテーブルは除外されます。

          • 増分データ移行：オンライン DDL ポリシーによって制御されます。

            • ○：オンライン DDL 操作によって生成された一時テーブル (例: _table_name_gho) からのデータ変更を移行します。

            • いいえ、DMS オンライン DDL に適応 および いいえ、gh-ost に適応：gh-ost などのツールによって生成された一時テーブル (例: _table_name_gho) からのデータ変更を正規表現ルールに基づいて除外します。

        • ○：オンライン DDL 変更によって生成された一時テーブルからデータを移行します。

          説明

          オンライン DDL 変更が一時テーブルに大量のデータを生成する場合、タスクの遅延を引き起こす可能性があります。

        • いいえ、DMS オンライン DDL に適応：オンライン DDL 変更によって生成された一時テーブルからデータを移行しません。Data Management (DMS) を使用して実行された元の DDL ステートメントのみを移行します。

          説明

          このオプションは、ターゲットデータベースのテーブルがロックされる原因となります。

        • いいえ、gh-ost に適応：オンライン DDL 変更によって生成された一時テーブルからデータを移行しません。カスタムフィルタリングルールをサポートしています。DTS は、gh-ost などのツールによって生成された一時テーブル (例: _table_name_gho) からのデータ変更を正規表現ルールに基づいて除外します。必要に応じて、シャドウテーブルと不要テーブルに一致させるために使用されるデフォルトの正規表現を変更できます：

          • シャドウテーブル：^_(.+)_(?:gho|new)$

          • 不要テーブル：^_(.+)_(?:ghc|del|old)$

          説明

          このオプションは、ターゲットデータベースのテーブルがロックされる原因となります。

        アカウントを移行

        ソースデータベースからアカウント情報を移行するかどうかを選択します。[はい] を選択した場合は、移行するアカウントを選択し、その権限を確認します。

        失敗した接続の再試行時間

        移行タスクが開始された後、ソースまたはターゲットデータベースへの接続が失敗した場合、DTS はエラーを報告し、直ちに接続の再試行を開始します。デフォルトの再試行時間は 720 分です。再試行時間を 10 分から 1440 分の間の値にカスタマイズできます。30 分以上に設定することを推奨します。DTS が指定された時間内にソースおよびターゲットデータベースに再接続した場合、移行タスクは自動的に再開されます。そうでない場合、タスクは失敗します。

        説明

        • 同じソースまたはターゲットを共有する複数の DTS インスタンスの場合、ネットワークの再試行時間は最後に作成されたタスクの設定によって決まります。

        • 接続再試行期間中もタスクには課金されるため、ビジネスニーズに基づいて再試行時間をカスタマイズするか、ソースおよびターゲットデータベースインスタンスがリリースされた後、できるだけ早く DTS インスタンスをリリースすることを推奨します。

        移行元データベースと移行先データベースで他の問題が発生した場合の、再試行までの待機時間です。

        移行タスクが開始された後、ソースまたはターゲットデータベースで DDL または DML 実行例外などの接続以外の問題が発生した場合、DTS はエラーを報告し、直ちに操作の再試行を開始します。デフォルトの再試行時間は 10 分です。再試行時間を 1 分から 1440 分の間の値にカスタマイズできます。10 分以上に設定することを推奨します。指定された再試行時間内に関連する操作が成功した場合、移行タスクは自動的に再開されます。そうでない場合、タスクは失敗します。

        重要

        移行元データベースと移行先データベースで他の問題が発生した場合の、再試行までの待機時間です。 の値は、失敗した接続の再試行時間 の値より小さくする必要があります。

        完全なデータ移行のためのスロットリングを有効化

        完全移行中、DTS はソースおよびターゲットデータベースの読み取りおよび書き込みリソースを消費し、データベースの負荷を増加させる可能性があります。必要に応じて、完全移行タスクの速度制限を有効にすることができます。1 秒あたりのソースデータベースのクエリ率 QPS、1 秒あたりの完全移行の行数 RPS、および 1 秒あたりの完全移行データ量 (MB) BPS を設定して、ターゲットデータベースの負荷を軽減できます。

        説明

        • この設定項目は、移行タイプ で 完全データ移行 を選択した場合にのみ利用できます。

        • 移行インスタンスが実行された後、完全移行速度を調整することもできます。

        完全なデータ移行のスロットリングを有効化

        必要に応じて、増分移行タスクの速度制限を設定することもできます。1 秒あたりの増分移行の行数 RPS と 1 秒あたりの増分移行データ量 (MB) BPS を設定して、ターゲットデータベースの負荷を軽減できます。

        説明

        • この設定項目は、移行タイプ で 増分データ移行 を選択した場合にのみ利用できます。

        • 移行インスタンスが実行された後、増分移行速度を調整することもできます。

        環境タグ

        インスタンスを識別するための環境タグを選択します。この例では、タグを選択する必要はありません。

        順方向および逆方向タスクのハートビートテーブル SQL を削除

        DTS インスタンスの実行中にハートビート SQL 情報をソースデータベースに書き込むかどうかを選択します。

        • ○：ハートビート SQL 情報はソースデータベースに書き込まれません。これにより、DTS インスタンスが遅延を報告する可能性があります。

        • ×：ハートビート SQL 情報をソースデータベースに書き込みます。これにより、ソースデータベースの物理バックアップやクローンなどの機能に干渉する可能性があります。

        ETL 機能の設定

        抽出、変換、ロード (ETL) 機能を有効にするかどうかを選択します。詳細については、「ETL とは何か？」をご参照ください。有効な値：

        監視アラート

        ビジネスニーズに基づいてアラートを設定し、アラート通知を受け取るかどうかを選択します。

        • ×：アラートを設定しません。

        • ○：アラートのしきい値とアラート通知を設定してアラートを設定します。移行が失敗した場合、または遅延がしきい値を超えた場合、システムはアラート通知を送信します。

      3. [次へ: データ検証] をクリックして、データ検証タスクを設定します。

        データ検証機能の詳細については、「データ検証の設定」をご参照ください。

    7. タスクを保存して事前チェックを実行します。

      • API オペレーションを呼び出す際にこのインスタンスを設定するためのパラメーターを表示するには、次：タスク設定の保存と事前チェック ボタンにポインターを合わせ、表示されるバブルで OpenAPI パラメーターのプレビュー をクリックします。

      • API パラメーターを表示する必要がない場合、または表示が完了した場合は、ページ下部の 次：タスク設定の保存と事前チェック をクリックします。

      説明

      • 移行タスクが開始される前に、DTS は事前チェックを実行します。タスクは事前チェックに合格した後にのみ開始されます。

      • 事前チェックが失敗した場合は、失敗した確認項目の横にある 詳細を表示 をクリックし、プロンプトに基づいて問題を修正してから、再度事前チェックを実行します。

      • 事前チェック中に警告が報告された場合：

        • 無視できない確認項目については、失敗した項目の横にある 詳細を表示 をクリックし、プロンプトに基づいて問題を修正してから、再度事前チェックを実行します。

        • 無視できる確認項目については、アラートの詳細を確認、無視、OK、および 再度事前チェックを実行 をクリックして、アラート項目をスキップし、再度事前チェックを実行できます。警告を無視することを選択した場合、データの不整合などの問題が発生し、ビジネスにリスクをもたらす可能性があります。

    8. インスタンスを購入します。

      1. 成功率 が 100% になったら、次：インスタンスの購入 をクリックします。

      2. 購入 ページで、データ移行インスタンスのリンク仕様を選択します。詳細については、次の表をご参照ください。

        カテゴリ

        パラメーター

        説明

        新しいインスタンスクラス

        リソースグループの設定

        インスタンスが属するリソースグループを選択します。デフォルト値はデフォルトのリソースグループです。詳細については、「Resource Management とは」をご参照ください。

        インスタンスクラス

        DTS は、さまざまなパフォーマンスレベルの移行仕様を提供します。リンク仕様は移行速度に影響します。ビジネスシナリオに基づいて仕様を選択できます。詳細については、「データ移行リンク仕様」をご参照ください。

      3. 設定が完了したら、Data Transmission Service (従量課金) 利用規約 を読んで選択します。

      4. 購入して起動 をクリックします。表示される OK ダイアログボックスで、[OK] をクリックします。

        データ移行タスク リストページで移行タスクの進捗状況を確認できます。

        説明

        • 移行タスクに増分移行が含まれていない場合、完全移行が完了した後に自動的に停止します。タスクが停止すると、その ステータス は 完了 に変わります。

        • 移行タスクに増分移行が含まれている場合、自動的に停止しません。増分移行タスクは実行を継続します。増分移行タスクが実行されている間、タスクの ステータス は 実行中 です。