すべてのプロダクト
Search
ドキュメントセンター

Data Transmission Service:MySQL インスタンス間の双方向同期

最終更新日:Apr 30, 2026

Data Transmission Service (DTS) を使用すると、MySQL データベース間で双方向同期を実現できます。本トピックでは、RDS MySQL インスタンス間で双方向同期を設定する手順について説明します。

前提条件

  • ソースおよびターゲットの ApsaraDB RDS for MySQL インスタンスを作成済みである必要があります。詳細については、「ApsaraDB RDS for MySQL インスタンスの作成」をご参照ください。

  • ソースおよびターゲットの ApsaraDB RDS for MySQL インスタンスのストレージ容量は同一である必要があります。

制限事項

説明
  • スキーマ同期中に、DTS は外部キーをソースデータベースからターゲットデータベースに同期します。

  • 完全データ同期および増分データ同期中、DTS はセッションレベルで制約チェックおよび外部キーのカスケード操作を一時的に無効化します。タスク実行中にソースデータベースでカスケード更新または削除操作を実行すると、データの不整合が発生する可能性があります。

種別

説明

ソースおよびターゲットデータベースの制限

  • 同期対象のテーブルにプライマリキーおよび一意制約が存在しない場合、タスク構成で Exactly-Once 書き込みを有効にしてください。これを行わないと、ターゲットデータベースに重複データが発生する可能性があります。詳細については、「プライマリキーまたは一意制約のないテーブルの同期」をご参照ください。

  • テーブル単位で同期し、マッピング(列名マッピングなど)を編集する必要がある場合、各同期タスクでサポートされるテーブル数は最大 1,000 です。この上限を超えると、タスクはエラーで失敗します。これを修正するには、複数のタスクにテーブルを分割するか、データベース全体の同期タスクを構成してください。

  • バイナリログ:

    • ApsaraDB RDS for MySQL では、デフォルトでバイナリロギングが有効になっています。binlog_row_image パラメーターが full に設定されていることを確認してください。設定されていない場合、事前チェックに失敗し、同期タスクを開始できません。詳細については、「インスタンスパラメーターの設定」をご参照ください。

      重要
      • ソースインスタンスが自己管理 MySQL データベースの場合、バイナリロギングを有効にし、binlog_format を row に、binlog_row_image を full に設定してください。

      • 自己管理 MySQL データベースがデュアルプライマリクラスター(両ノードがプライマリおよびセカンダリとして機能)の場合、log_slave_updates パラメーターを有効にして、DTS がすべてのバイナリログイベントを取得できるようにしてください。詳細については、「自己管理 MySQL データベースのアカウント作成およびバイナリロギングの設定」をご参照ください。

    • ApsaraDB RDS for MySQL インスタンスのローカルバイナリログは、最低でも 3 日間(推奨は 7 日間)保持する必要があります。自己管理 MySQL データベースの場合は、ローカルバイナリログを最低でも 7 日間保持してください。保持期間が短いと、DTS がバイナリログを取得できず、タスクが失敗する可能性があります。最悪の場合、データの不整合やデータ損失が発生します。DTS の要件よりも短いバイナリログ保持期間によって発生した問題は、DTS SLA の適用外となります。

      説明

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

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

    説明

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

  • バイナリログに書き込まれない変更(物理バックアップからのデータ復元やカスケード操作によって作成されたデータなど)によって生成されたデータは、ターゲットデータベースに同期されません。

    説明

    このような状況が発生した場合は、影響を受けたデータベースまたはテーブルを同期オブジェクトから削除し、再度追加してください。ただし、これはビジネス要件で許容される場合に限ります。詳細については、「同期オブジェクトの変更」をご参照ください。

  • 同期対象の列に非表示の隠し列が含まれていないことを確認してください。含まれている場合、DTS タスクが失敗したり、データが失われたりする可能性があります。

    説明

    非表示の列を表示可能にするには、ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; コマンドを実行してください。詳細については、「Invisible Columns」をご参照ください。

その他の制限

  • 互換性を確保するために、ソースおよびターゲットデータベースで同じバージョンを使用するか、低いバージョンから高いバージョンへスペックアップしてください。高いバージョンから低いバージョンへの同期は、互換性の問題を引き起こす可能性があります。

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

  • コメント構文で定義されたリゾルバは、同期使用をサポートしていません。

  • タスク実行中にプライマリキーまたは一意キーの競合が発生した場合:

    • テーブルスキーマが同一で、ターゲットデータベースのレコードがソースデータベースのレコードと同じプライマリキーまたは一意キー値を持つ場合:

      • 完全同期中は、DTS がターゲットクラスター内のレコードを保持します。ソースデータベースからの対応するレコードは同期されません。

      • 増分同期中は、ソースデータベースからのレコードがターゲットデータベースのレコードを上書きします。

    • テーブルスキーマが異なる場合、初期データ同期が失敗する可能性があります。これにより、一部の列データのみが同期されるか、同期が完全に失敗する可能性があります。慎重に進めてください。

  • DTS を使用してテーブルスキーマを同期しない場合、フィールドの互換性を自分で確認してください。確認しないと、タスクが失敗したり、データが失われたりする可能性があります。たとえば、ソーステーブルで text データ型を使用しており、ターゲット列で varchar(255) を使用している場合、ソーステーブルの大きなフィールドが切り捨てられる可能性があります。

  • 双方向同期タスクの実行中、DTS は転送および逆方向タスクの両方のターゲットデータベースに dts という名前のデータベースを作成します。これにより、循環同期を防止します。タスク実行中は、このデータベースを変更しないでください。また、タスクで使用するデータベースアカウントが、このデータベースに対する読み取りおよび書き込み権限を持っていることを確認してください。

    説明

    dts データベースが MySQL の通常のプライマリ/セカンダリレプリケーションを妨害する可能性があります。セカンダリデータベースに dts データベースおよびそのテーブルが存在するかどうかを確認してください。存在しない場合は、プライマリデータベースと同じスキーマを使用して、セカンダリデータベースに手動で作成してください。

  • データに四バイト文字(希少な漢字や絵文字など)が含まれる場合、ターゲットデータベースおよびテーブルで utf8mb4 文字セットを使用する必要があります。

    説明

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

  • 同期を開始する前に、ソースおよびターゲットデータベースのパフォーマンスを評価してください。オフピーク時間帯に同期を実行することを推奨します。そうしないと、完全初期化によって両データベースの読み取りおよび書き込みリソースが消費され、データベース負荷が増加する可能性があります。

  • 完全初期化では INSERT 操作が同時に行われます。これにより、ターゲットテーブルがフラグメント化します。完全初期化後、ターゲットインスタンスの表領域はソースインスタンスよりも大きくなります。

  • データベース全体ではなく、1 つ以上のテーブルを同期する場合、pt-online-schema-change などのツールを使用してソーステーブルでオンライン DDL 操作を実行しないでください。実行すると、同期が失敗します。

    Data Management (DMS) を使用してオンライン DDL 操作を実行できます。詳細については、「テーブルロックなしのオンライン DDL」をご参照ください。

  • DTS は、ターゲットデータベースへの同期時にデフォルトで外部キー制約を無効化します。そのため、ソースデータベースでのカスケード操作および削除は、ターゲットデータベースに同期されません。

  • 双方向同期タスクには、転送および逆方向の同期タスクが含まれます。タスクを構成またはリセットする際、一方のタスクのターゲットオブジェクトがもう一方のタスクの同期オブジェクトと一致する場合:

    • 完全および増分データの同期を許可するのは 1 つのタスクのみです。もう一方のタスクは増分同期のみをサポートします。

    • 現在のタスクのソースからのデータは、現在のタスクのターゲットにのみ同期されます。他のタスクのソースデータとしては使用されません。

  • DDL 操作がターゲットデータベースで失敗しても、DTS タスクは継続して実行されます。失敗した DDL はタスクリログで確認してください。詳細については、「タスクリログの表示」をご参照ください。

  • ターゲット MySQL データベースの同じテーブルに、大文字小文字のみが異なる列名でデータを書き込むと、MySQL の列名が大文字小文字を区別しないため、予期しない結果が発生する可能性があります。

  • データ同期が完了した後(インスタンスの ステータス完了 になった後)、ANALYZE TABLE <table_name> コマンドを使用して、すべてのデータがターゲットテーブルに書き込まれていることを確認してください。たとえば、ターゲット MySQL データベースで HA フェールオーバーメカニズムがトリガーされた後、データがメモリにのみ書き込まれている可能性があり、これが原因でデータ損失が発生することがあります。

  • ApsaraDB RDS for MySQL インスタンスで Always-Encrypted が有効になっている場合、完全データ同期はサポートされません。

    説明

    透過的データ暗号化 (TDE) が有効になっている ApsaraDB RDS for MySQL インスタンスは、スキーマ同期、完全データ同期、および増分データ同期をサポートしています。

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

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

    説明

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

特殊なケース

  • 自己管理 MySQL ソースデータベースの場合:

    • 同期中にソースデータベースでプライマリ/セカンダリ スイッチオーバーが発生すると、タスクは失敗します。

    • DTS は、最後に同期されたレコードのタイムスタンプと現在時刻を比較して遅延を計算します。ソースデータベースで長時間 DML 操作が実行されない場合、遅延レポートが不正確になる可能性があります。遅延が高すぎると思われる場合は、ソースデータベースで DML 操作を実行して遅延を更新してください。

      説明

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

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

    • セルフマネージド MySQL が双方向同期タスクおよび他のタスクの両方のソースデータベースとして機能する場合、ソースデータベースの /etc/my.cnf ファイルに log_slave_updates=1 行を追加し、データベースを再起動する必要があります。これを行わないと、逆方向タスクからのデータ変更がセルフマネージド MySQL のバイナリログに記録されず、他のタスクでデータの不整合が発生します。

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

  • ApsaraDB RDS for MySQL ソースデータベースの場合:

    • トランザクションログを記録しない読み取り専用インスタンス(例:ApsaraDB RDS for MySQL 5.6 読み取り専用インスタンス)は、ソースデータベースとして使用できません。

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

課金

同期タイプ

料金

スキーマ同期および完全データ同期

無料です。

増分データ同期

課金対象です。詳細については、「課金概要」をご参照ください。

競合検出

データ整合性を確保するため、双方向同期のデータベースインスタンスのいずれか一方でのみ、同じプライマリキー、ビジネスプライマリキー、または一意キーを持つデータレコードを更新するようにしてください。両方のデータベースインスタンスでデータレコードが更新された場合、DTS システムはタスクで構成された競合解決ポリシーを適用します。

DTS は競合をチェックおよび修正して、双方向同期タスクの安定性を最大化します。DTS は以下のタイプの競合を検出できます。

  • INSERT 操作によって発生する一意性競合

    双方向同期では、同じプライマリキーを持つレコードが両方のデータベースインスタンスに同時に(または短時間の間に)挿入されると、一意性制約の競合がトリガーされます。INSERT 文がピアインスタンスに同期されると、同じプライマリキー値を持つレコードがすでに存在するため、失敗します。

  • UPDATE 操作における不一致レコード

    • 更新対象のレコードがターゲットインスタンスに存在しない場合、DTS は UPDATE 操作を INSERT 操作に変換します。ただし、一意性競合が発生する可能性があります。

    • UPDATE 操作によって更新されるレコードがプライマリキーまたは一意キーの競合を引き起こします。

  • 削除対象の存在しないレコード

    削除対象のレコードがターゲットインスタンスに存在しません。この場合、指定された競合解決ポリシーに関係なく、DTS は DELETE 操作を無視します。

重要
  • 時差および遅延のため、DTS は競合を 100 % 防止できるとは限りません。整合性を確保するため、同じプライマリキーまたは一意キーを持つレコードは、一度に 1 つのデータベースインスタンスでのみ更新してください。

  • 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 操作はデータの不整合を引き起こす可能性があります。たとえば、同期オブジェクトが単一テーブルで、同期中にソースインスタンスでこのテーブルの名前を変更すると、このテーブルのデータはターゲットデータベースに同期されません。この問題を回避するには、テーブルが属するデータベース全体を同期オブジェクトとして選択してください。RENAME TABLE 操作の前後でテーブルが属するデータベースが同期オブジェクトに含まれていることを確認してください。

  • TRUNCATE TABLE

重要
  • DDL ステートメントは転送タスク(ソースデータベースからターゲットデータベースへの同期)でのみ同期されます。逆方向タスクでは DDL ステートメントはサポートされておらず、自動的にフィルターで除外されます。

  • 双方向同期中に、ソースデータベースで DDL ステートメントを実行してテーブルスキーマを変更する場合、ソースおよびターゲットデータベースの両方での DML 書き込み操作が新しいスキーマと一致していることを確認してください。一致していないと、書き込み操作が失敗する可能性があります。たとえば、ソースデータベースから列を削除した場合、ターゲットデータベースは削除された列を含む古いスキーマに基づいてデータの書き込みを試行する可能性があります。

アカウント権限

データベース

権限

操作

ソース ApsaraDB RDS for MySQL

アカウントは、ソースおよびターゲットデータベースに対する読み取りおよび書き込み権限を持っている必要があります。ApsaraDB RDS for MySQL インスタンスの特権アカウントは、すでにこれらの権限を持っています。

アカウントを作成する および 特権アカウントをリセットする

ターゲット ApsaraDB RDS for MySQL

操作手順

  1. ターゲットリージョンの同期タスクリストページに移動します。次の 2 つの方法のいずれかを使用できます。

    DTS コンソールから

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

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

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

    DMS コンソールから

    説明

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

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

    2. 上部のメニューバーで、データ + AI > データ伝送 (DTS) > データ同期 を選択します。

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

  2. タスクの作成 をクリックして、タスク構成ページを開きます。

  3. ソースおよびターゲットデータベースを構成します。

    警告

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

    カテゴリ

    パラメーター

    説明

    該当なし

    タスク名

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

    移行元データベース

    既存の接続情報の選択

    • システムに追加済み(新規作成または保存済み)のデータベースインスタンスを使用する場合、ドロップダウンリストからデータベースインスタンスを選択します。データベース情報は自動的に構成されます。

      説明

      DMS コンソールでは、この設定項目の名前は DMS データベースインスタンスの選択 です。

    • データベースインスタンスをまだシステムに追加していない場合、またはすでに追加されているインスタンスを使用しない場合は、次のデータベース情報を手動で構成してください。

    データベースタイプ

    MySQL を選択します。

    アクセス方法

    Alibaba Cloud インスタンス を選択します。

    インスタンスリージョン

    ソース RDS MySQL インスタンスのリージョンを選択します。

    Alibaba Cloud アカウント間でデータを複製

    この例では、現在の Alibaba Cloud アカウントに属するデータベースインスタンスを使用します。× を選択します。

    RDS インスタンス ID

    ソース RDS MySQL インスタンスの ID を選択します。

    説明

    ソースおよびターゲットの RDS MySQL インスタンスは、同一でも異なっていてもかまいません。DTS を使用して、2 つの RDS MySQL インスタンス間、または同一の RDS MySQL インスタンス内でデータを同期できます。

    データベースアカウント

    ソース RDS MySQL インスタンスの特権アカウントを入力します。

    データベースパスワード

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

    暗号化

    必要に応じて、非暗号化 または SSL 暗号化 を選択します。SSL 暗号化 を選択する場合、事前に RDS for MySQL インスタンスで SSL 暗号化を有効化しておく必要があります。詳細については、「クラウド証明書を使用した SSL 暗号化の迅速な有効化」をご参照ください。

    移行先データベース

    既存の接続情報の選択

    • システムに追加済み(新規作成または保存済み)のデータベースインスタンスを使用する場合、ドロップダウンリストからデータベースインスタンスを選択します。データベース情報は自動的に構成されます。

      説明

      DMS コンソールでは、この設定項目の名前は DMS データベースインスタンスの選択 です。

    • データベースインスタンスをまだシステムに追加していない場合、またはすでに追加されているインスタンスを使用しない場合は、次のデータベース情報を手動で構成してください。

    データベースタイプ

    MySQL を選択します。

    アクセス方法

    Alibaba Cloud インスタンス を選択します。

    インスタンスリージョン

    ターゲット RDS MySQL インスタンスのリージョンを選択します。

    Alibaba Cloud アカウント間でデータを複製

    この例では、現在の Alibaba Cloud アカウントに属するデータベースインスタンスを使用します。× を選択します。

    RDS インスタンス ID

    ターゲット RDS MySQL インスタンスの ID を選択します。

    データベースアカウント

    ターゲット RDS MySQL インスタンスの特権アカウントを入力します。

    データベースパスワード

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

    暗号化

    必要に応じて、非暗号化 または SSL 暗号化 を選択します。SSL 暗号化 を選択する場合、事前に RDS for MySQL インスタンスで SSL 暗号化を有効化しておく必要があります。詳細については、「クラウド証明書を使用した SSL 暗号化の迅速な有効化」をご参照ください。

  4. 構成が完了したら、ページ下部の 接続をテストして続行 をクリックします。

    説明
    • DTS サーバーからのアクセスを許可するために、ソースおよびターゲットデータベースのセキュリティ設定に DTS サーバーの IP アドレス CIDR ブロックを追加してください。これは自動または手動で行えます。詳細については、「DTS サーバーの IP アドレス CIDR ブロックをホワイトリストに追加」をご参照ください。

    • ソースまたはターゲットデータベースが自己管理データベース(アクセス方法Alibaba Cloud インスタンス ではない)の場合、DTS サーバーの CIDR ブロック ダイアログボックスで 接続テスト をクリックする必要があります。

  5. タスクオブジェクトを構成します。

    1. オブジェクト設定 ページで、同期するオブジェクトを構成します。

      パラメーター

      説明

      同期タイプ

      増分データ同期 が選択されています。デフォルトでは、スキーマ同期 および 完全データ同期 も選択する必要があります。事前チェックが完了すると、DTS は選択されたオブジェクトの完全データをソースインスタンスからターゲットクラスターに同期します。これは、その後の増分データ同期のベースラインデータとなります。

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

      要件に応じて、トリガーを同期する方法を選択します。同期対象のオブジェクトにトリガーが含まれない場合は、このパラメーターをスキップできます。詳細については、「トリガーの同期または移行方法の構成」をご参照ください。

      説明

      スキーマ同期同期タイプ に選択した場合にのみ、このパラメーターを構成できます。

      移行評価の有効化

      ソースおよびターゲットデータベースのスキーマ(インデックス長、ストアドプロシージャ、依存テーブルなど)が要件を満たしているかどうかを評価します。ビジネス要件に応じて、 または いいえ を選択できます。

      説明
      • スキーマ同期同期タイプ に選択した場合にのみ、このパラメーターを構成できます。

      • を選択すると、事前チェックに時間がかかる可能性があります。事前チェックフェーズ中に 評価結果 を確認できます。評価結果は事前チェック結果に影響しません。

      同期トポロジ

      双方向同期 を選択します。

      [Exactly-Once] を有効化し書き込みを実行するかどうか

      同期対象のオブジェクトにプライマリキーまたは一意制約のないテーブルが含まれる場合、 を選択します。詳細については、「プライマリキーまたは一意制約のないテーブルの同期」をご参照ください。

      DDL 操作を除外

      • :DDL 操作は同期されません。

      • いいえ:DDL 操作は同期されます。

        重要

        双方向同期リンクの安定性を確保するために、DDL 操作の同期を転送同期タスク(ソースデータベースからターゲットデータベースへの同期)に対してのみ選択できます。逆方向同期タスク(ターゲットデータベースからソースデータベースへの同期)では、DDL 操作は自動的にフィルターで除外されます。

      グローバルな競合修復ポリシー

      前述の競合タイプが発生した場合、ビジネス要件に応じて適切な競合解決ポリシーを選択します。

      • Taskfailed (競合が発生した場合、エラーが報告されタスクは終了します。)

        データ同期中にデータ競合が発生すると、タスクはエラーを報告して停止します。タスクは失敗状態になり、手動での介入が必要です。

      • Ignore (競合が発生した場合、移行先インスタンスの競合レコードが使用されます。)

        データ同期中にデータ競合が発生すると、現在の同期文はスキップされ、処理は継続されます。ターゲットデータベースの競合レコードは保持されます。

      • Overwrite (競合が発生した場合、移行先インスタンスの競合レコードは上書きされます。)

        データ同期中にデータ競合が発生すると、ターゲットデータベースの競合レコードが上書きされます。

      説明

      これらのポリシーは、タスクの一時停止または再開後に発生する遅延期間中には適用されません。このような場合は、デフォルトでターゲットデータベースのデータが上書きされます。

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

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

        説明

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

      • エラーを無視して続行:ターゲットデータベースでの重複テーブル名のチェックをスキップします。

        警告

        エラーを無視して続行 を選択すると、データの不整合が発生し、ビジネスにリスクをもたらす可能性があります。たとえば:

        • テーブルスキーマが同一で、ターゲットデータベースのレコードがソースデータベースのレコードと同じプライマリキーまたは一意キー値を持つ場合:

          • 完全同期中は、DTS がターゲットクラスター内のレコードを保持します。ソースデータベースからの対応するレコードは同期されません。

          • 増分同期中は、ソースデータベースからのレコードがターゲットデータベースのレコードを上書きします。

        • テーブルスキーマが異なる場合、初期データ同期が失敗する可能性があります。これにより、一部の列データのみが同期されるか、同期が完全に失敗する可能性があります。慎重に進めてください。

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

      必要に応じて、ソースデータベースからイベントを同期するかどうかを指定します。 を選択する場合、関連要件を満たし、後続の操作を実行する必要があります。詳細については、「イベントの同期または移行」をご参照ください。

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

      ターゲットインスタンスに同期されるデータベース、テーブル、列オブジェクト名の大文字小文字の扱いポリシーを構成できます。デフォルトでは、DTS のデフォルトポリシー が選択されています。ソースおよびターゲットデータベースのデフォルトポリシーを使用することもできます。詳細については、「ターゲットオブジェクト名の大文字小文字の扱いポリシー」をご参照ください。

      ソースオブジェクト

      ソースオブジェクト ボックスで、同期するオブジェクトをクリックし、向右 をクリックして 選択中のオブジェクト ボックスに移動させます。

      説明

      同期オブジェクトとしてデータベース、テーブル、列を選択できます。テーブルまたは列を選択した場合、ビュー、トリガー、ストアドプロシージャなどの他のオブジェクトはターゲットデータベースに同期されません。

      選択中のオブジェクト

      説明
      • データベースまたはテーブルレベルで同期する SQL 操作を選択するには、選択中のオブジェクト ボックスでオブジェクトを右クリックし、表示されるダイアログボックスで目的の SQL 操作を選択します。

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

      • オブジェクト名マッピング機能を使用する場合、マッピングされたオブジェクトに依存する他のオブジェクトの同期が失敗する可能性があります。

      • 増分データ同期に対して 個別の競合修復ポリシー を構成する必要がある場合は、「独立競合解決ポリシーの設定」をご参照ください。

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

      パラメーター

      説明

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

      デフォルトでは、DTS は共有クラスターでタスクをスケジュールし、クラスターを選択する必要はありません。より安定したパフォーマンスを求める場合は、DTS 同期タスクを実行する専用クラスターを購入できます。詳細については、「DTS 専用クラスターとは」をご参照ください。

      移行元テーブルで生成された 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 ~ 1,440 分の範囲でカスタム再試行時間を指定することもできます。30 分以上に設定することを推奨します。指定された時間内に DTS がデータベースへの再接続に成功した場合、同期タスクは自動的に再開されます。それ以外の場合は、タスクが失敗します。

      説明
      • 複数の DTS インスタンス(例:インスタンス A およびインスタンス B)が同じソースまたはターゲットを共有しており、インスタンス A のネットワークリトライ時間を 30 分、インスタンス B を 60 分に設定している場合、両方に短い方の 30 分が適用されます。

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

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

      同期タスクを開始した後、ソースまたはターゲットデータベースで接続以外の問題(DDL または DML 実行例外など)が発生した場合、DTS はエラーを報告し、すぐに継続的な再試行操作を開始します。デフォルトの再試行時間は 10 分です。1 ~ 1,440 分の範囲でカスタム再試行時間を指定することもできます。10 分以上に設定することを推奨します。設定された再試行時間内に関連操作が成功した場合、同期タスクは自動的に再開されます。それ以外の場合は、タスクが失敗します。

      重要

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

      完全同期レートを制限するかどうか

      完全同期ステージ中、DTS はソースおよびターゲットデータベースの読み取りおよび書き込みリソースを消費し、データベース負荷が増加する可能性があります。ソースおよびターゲットデータベースの負荷を軽減するために、1 秒あたりのソースデータベースのクエリ率 QPS1 秒あたりの完全移行の行数 RPS、および 1 秒あたりの完全移行データ量 (MB) BPS パラメーターを構成して、完全同期タスクのレート制限を設定できます。

      説明
      • この設定項目は、同期タイプ完全データ同期 に設定されている場合にのみ利用可能です。

      • 同期インスタンスの実行後も、完全同期レートを調整 できます。

      増分同期率を制限するかどうか

      増分同期タスクのレート制限も設定できます。ターゲットデータベースの負荷を軽減するために、1 秒あたりの増分同期の行数 RPS および 1 秒あたりの増分同期データ量 (MB) BPS を設定します。

      環境タグ

      要件に応じて、インスタンスを識別するための環境タグを選択できます。この例では、このパラメーターを構成する必要はありません。

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

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

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

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

      ETL 機能の設定

      抽出・変換・書き出し (ETL) 機能を有効にするかどうかを選択します。詳細については、「ETL とは」をご参照ください。有効値:

      監視アラート

      アラートを構成するかどうかを指定します。同期が失敗した場合、または遅延が指定されたしきい値を超えた場合、アラート連絡先に通知が送信されます。

    3. 次へ:データ検証 をクリックして、データ検証タスクを構成します。

      データ検証機能を使用する場合は、「データ検証の構成」の構成手順をご参照ください。

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

    • このインスタンスを構成するための API パラメーターを表示するには、次:タスク設定の保存と事前チェック ボタンにカーソルを合わせ、表示されるバルーンで OpenAPI パラメーターのプレビュー をクリックします。

    • API パラメーターの確認が完了したら、ページ下部の 次:タスク設定の保存と事前チェック をクリックします。

    説明
    • 同期ジョブを開始する前に、DTS は事前チェックを実行します。すべての事前チェック項目が合格した後でのみ、ジョブを開始できます。

    • 事前チェックに失敗した場合、失敗した項目の横にある 詳細を表示 をクリックします。指示に従って問題を修正し、再度事前チェックを実行します。

    • 事前チェックで警告が返された場合:

      • チェック項目が失敗し、無視できない場合は、項目の横にある 詳細を表示 をクリックします。指示に従って問題を修正し、再度事前チェックを実行します。

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

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

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

    2. 購入 ページで、データ同期インスタンスの課金方法およびリンク仕様を選択します。利用可能なオプションは次のとおりです。

      カテゴリ

      パラメーター

      説明

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

      課金方法

      • サブスクリプション:インスタンス作成時に支払いを行います。長期的なニーズに適しており、従量課金よりもコスト効率が高くなります。サブスクリプション期間が長いほど、割引率が高くなります。

      • 従量課金:1 時間単位で課金されます。短期的なニーズに適しています。使用後すぐにインスタンスをリリースしてコストを節約できます。

      リソースグループ構成

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

      リンク仕様

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

      同期トポロジ

      これは 双方向同期 に固定されています。

      サブスクリプション期間

      サブスクリプションモードでは、サブスクリプションインスタンスの期間および数量を選択します。1 ~ 9 ヶ月の月額サブスクリプション、または 1、2、3、5 年の年額サブスクリプションを選択できます。

      説明

      このオプションは、課金方法が サブスクリプション の場合にのみ利用可能です。

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

    4. 購入して起動 をクリックします。OK ダイアログボックスで、OK をクリックします。

      データ同期ページでタスクの進行状況を確認できます。

  8. 逆方向同期タスクを構成します。

    1. 転送同期タスクの初期化が完了し、ステータス実行中 に変更されるまで待ちます。

    2. 逆方向同期タスクを見つけ、タスクの設定 をクリックします。

    3. ステップ 3 から ステップ 6 を参照して、逆方向同期タスクを構成します。

      重要
      • 逆方向同期タスクを構成する際は、正しいソースおよびターゲットインスタンスを選択する必要があります。逆方向同期のソースインスタンスは転送同期のターゲットインスタンスであり、逆方向同期のターゲットインスタンスは転送同期のソースインスタンスです。データベース名、アカウント、パスワードなどのインスタンス情報が一致していることを慎重に確認してください。

      • 逆方向同期タスクでは、ソースおよびターゲットデータベースの インスタンスのリージョン を変更できません。このタスクでは、転送同期タスクよりも少ない構成パラメーターが必要です。実際のパラメーターはコンソールを参照してください。

      • 逆方向同期タスクの 競合するテーブルの処理モード 構成では、転送同期タスクによってターゲットインスタンスに同期されたテーブルはチェックされません。

      • 逆方向同期タスクは、転送同期タスクの 選択中のオブジェクト リストで指定されたオブジェクトの同期をサポートしていません。

      • 逆方向同期タスクを構成する際は、マッピング機能を使用しないことを推奨します。使用すると、データの不整合が発生する可能性があります。

    4. 成功率100% に達したら、戻る をクリックします。

  9. 逆方向同期タスクの構成後、両方の同期タスクの ステータス実行中 になるまで待ちます。これで双方向データ同期の構成が完了します。