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

テーブル構造

• 同期対象のテーブルには、すべてのユニークフィールドを含む PRIMARY KEY または UNIQUE 制約が必要です。これを満たさない場合、宛先に重複レコードが生成される可能性があります。

• テーブル（データベースではなく）を同期対象として選択し、テーブル名またはカラム名の変更を予定している場合、単一タスクでサポートされるテーブル数は最大 1,000 個です。1,000 個を超えるテーブルを同期する場合は、複数のタスクを構成するか、データベースレベルで同期を行ってください。

バイナリログ

DTS がソースから変更を読み取るには、以下のバイナリログ設定が事前に適用されている必要があります。

• binlog_row_image パラメーターは、full に設定する必要があります。ApsaraDB RDS for MySQL インスタンスでは、バイナリログ記録がデフォルトで有効になっていますが、このパラメーターを確認してください。詳細については、「インスタンスのパラメーターを変更する」をご参照ください。

  • ソースが自己管理 MySQL データベースの場合： バイナリロギングを有効化し、binlog_format を row に、binlog_row_image を full に設定する必要があります。

  • ソースがデュアルプライマリクラスターにデプロイされた自己管理 MySQL データベースである場合: DTS がすべてのバイナリログを取得できるように、log_slave_updates を ON に設定する必要もあります。「自己管理 MySQL データベースのアカウントを作成してバイナリロギングを設定する」をご参照ください。

• バイナリログの保持期間は、7 日間以上である必要があります。 DTS が必要なバイナリログにアクセスできない場合、タスクは失敗し、データ損失が発生する可能性があります。 詳細については、「バイナリログファイルの管理」をご参照ください。

スキーマ同期または完全データ同期中に、ソースデータベースに対して DDL ステートメントを実行しないでください。これによりタスクが失敗します。

バージョンおよび文字セットの互換性

• 宛先データベースのバージョンは、ソースと同一またはそれより新しいものである必要があります。古いバージョンの宛先では互換性の問題が発生する可能性があります。

• ソース データベースが MySQL 8.0.23 以降であり、不可視カラムを含む場合、DTS はこれらのカラムのデータを取得できません — データ損失が発生します。

• 宛先 データベースが MySQL 8.0.23 以降であり、不可視カラムを含む場合、データ受信用の宛先カラムが見つからないため、DTS インスタンスが失敗し、データ損失が発生します。

• いずれの場合も、タスク開始前に、ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; を実行して不可視カラムを可視化してください。主キーを持たないテーブルでは、不可視の主キーが自動生成されます。これらも可視化してください。詳細については、「Invisible Columns」および「Generated Invisible Primary Keys」をご参照ください。

• スキーマ同期を使用しない場合、フィールド型の互換性を維持する必要があります。たとえば、ソースの text フィールドが宛先の varchar(255) フィールドにマッピングされている場合、データの切り捨てが発生する可能性があります。

• データに 4 バイト文字（稀少な文字や絵文字など）が含まれる場合、宛先テーブルは UTF8mb4 文字セットを使用する必要があります。スキーマ同期を使用する場合、宛先データベースの character_set_server パラメーターを UTF8mb4 に設定してください。

• MySQL のカラム名は大文字小文字を区別しません。ソースに大文字小文字のみが異なる複数のカラム名がある場合、それらは宛先で同一のカラムに書き込まれ、予期しない結果を招く可能性があります。

オンライン DDL

• 同期対象として選択されたテーブルに対するオンライン DDL では、pt-online-schema-change を使用しないでください。代わりに Data Management (DMS) を使用してください。詳細については、「ロックなしの DDL 操作を実行する」をご参照ください。

• 送信先で DDL 操作が失敗した場合、DTS タスクは継続して実行されます。失敗した DDL 文を確認するには、タスクログを確認してください。詳細については、「タスクログの表示」をご参照ください。

• DTS は、コメントで定義されたパーサーを使用するデータを同期しません。

データ整合性

• 同期中は、他のソースから宛先へのデータ書き込みを行わないでください。これによりデータの不整合が発生します。

• バイナリログの変更操作（物理バックアップからの復元やカスケード操作など）によって生成されたデータは、タスク実行中は記録・同期されません。

外部キーの動作

• スキーマ同期中、DTS はソースから宛先へ外部キーを同期します。

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

パフォーマンスへの影響

完全データ同期では、ソースデータベースからすべてのデータを一度読み取るため、両方のデータベースの負荷が増加します。リスクを軽減するには、以下の点に注意してください。

• 非ピーク時間帯に同期タスクを実行してください。

• 完全同期後、並列 INSERT による断片化のため、宛先の表領域がソースよりも大きくなることがあります。

• タスクのステータスが 完了 に変更された後、analyze table <table_name> を実行して、データが宛先に正しく書き込まれたことを確認してください。（例：ソースで高可用性 (HA) スイッチオーバーが発生した場合、一部のデータがメモリ上にのみ書き込まれる可能性があります。）

特殊ケース

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

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

• DTS は、宛先で最新に同期されたデータのタイムスタンプとソースの現在時刻に基づいて同期遅延を算出します。ソースで長期間 DML 操作が行われていない場合、遅延の測定値が不正確になる可能性があります。遅延が過度に高い場合は、ソースで DML 操作を実行して更新してください。データベース全体を同期対象として選択した場合は、1 秒ごとに更新されるハートビートテーブルを作成することで、遅延の精度を保つことができます。

• DTS は、バイナリログ位置を進めるために、ソースで定期的に CREATE DATABASE IF NOT EXISTS 'test' を実行します。

ApsaraDB RDS for MySQL ソースの場合：

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

• DTS は、バイナリログ位置を進めるために、ソースで定期的に CREATE DATABASE IF NOT EXISTS 'test' を実行します。

• EncDB 機能が有効化された ApsaraDB RDS for MySQL インスタンスでは、完全データ同期はサポートされていません。透過的データ暗号化 (TDE) が有効化されたインスタンスでは、スキーマ同期、完全データ同期、増分同期のすべてがサポートされます。

DTS テクニカルサポートが失敗したタスクを復旧する場合：

• サポートは 8 時間以内に復旧を試みます。タスクは再起動され、特定のタスクパラメーターが変更される場合があります。ただし、データベースパラメーターは変更されません。

ステップ 1：データ同期タスクページへ移動

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

2. トップナビゲーションバーで、Data + AI をクリックします。

3. 左側ナビゲーションウィンドウで、DTS (DTS) > データ同期 を選択します。

ナビゲーションは、お使いの DMS コンソールのモードとレイアウトによって異なる場合があります。「シンプルモード」および「DMS コンソールのレイアウトとスタイルをカスタマイズする」をご参照ください。または、直接「新しい DTS コンソールのデータ同期タスクページ」にアクセスしてください。

ステップ 2：タスクの作成

1. データ同期インスタンスが配置されているリージョンを選択します。

   新規 DTS コンソールでは、代わりにトップナビゲーションバーでリージョンを選択してください。

2. タスクの作成 をクリックします。

3. （任意）ページ右上隅の 新規構成ページ をクリックします。

   以前のバージョンに戻る ボタンが表示されている場合は、このステップをスキップしてください。新規構成ページの使用を推奨します。

ステップ 3：ソースおよび宛先データベースの構成

ソースおよび宛先の両方について、以下のパラメーターを入力してください。

ステップ 4：接続性のテスト

接続性のテストと続行 をクリックします。

DTS は、自動的にそのサーバーの CIDR ブロックを Alibaba Cloud データベースインスタンスのホワイトリストに追加します。ECS でホストされるデータベースの場合、DTS は CIDR ブロックを ECS セキュリティグループルールに追加しますが、ECS インスタンスがデータベースにアクセスできることを確認する必要があります。データベースが複数の ECS インスタンスにまたがる場合は、各インスタンスのセキュリティグループに CIDR ブロックを手動で追加してください。オンプレミスデータベースまたはサードパーティのクラウドプロバイダーでホストされるデータベースの場合は、DTS サーバーの CIDR ブロックをデータベースのホワイトリストに手動で追加してください。詳細については、「DTS サーバーの CIDR ブロック」をご参照ください。

ステップ 5：同期対象の構成

[オブジェクトの設定] ステップでは、以下のパラメーターを設定します：

オブジェクト名マッピングによるオブジェクト名の変更は、それに依存する他のオブジェクトの同期失敗を引き起こす可能性があります。

ステップ 6：高度な設定の構成

次へ：高度な設定 をクリックし、以下のパラメーターを入力してください。

ステップ 7：データ検証の構成（任意）

「[次へ：データ検証]」をクリックして、タスクのデータ検証を設定します。 「データ検証タスクの設定」をご参照ください。

ステップ 8：事前チェックの実行

次へ：タスク設定の保存と事前チェック をクリックします。

この構成の API パラメーターをプレビューするには、次へ：タスク設定の保存と事前チェック 上にマウスを合わせ、OpenAPI パラメーターのプレビュー をクリックしてください。

DTS は、タスクを開始する前に事前チェックを実行します。事前チェックが完了するまでお待ちください。

• 項目が失敗した場合、詳細の表示 をクリックして原因を確認し、問題を修正した後、再び事前チェック をクリックしてください。

• 項目に警告が表示された場合、問題を修正するか、警告の詳細の確認 > 無視 > OK > 再び事前チェック をクリックして続行してください。警告を無視すると、データの不整合が発生する可能性があります。

ステップ 9：インスタンスの購入

成功率 が 100% に達した後、次へ：インスタンスの購入 をクリックします。

購入 ページで、以下の設定を行います。

Data Transmission Service（従量課金）サービス利用規約 を読み、同意した上で、購入および開始 をクリックして確認してください。

タスクはタスクリストに表示されます。その進行状況をそこから監視してください。