Data Transmission Service:ApsaraDB RDS for MySQL インスタンスからインスタンスへのデータ同期

バイナリログの要件

DTS の設定を行う前に、以下のバイナリログ設定を確認してください。

ApsaraDB RDS for MySQL の場合（バイナリロギングはデフォルトで有効）：

• binlog_row_image を full に設定します。詳細については、「インスタンスパラメーターの変更」をご参照ください。

• バイナリログは少なくとも 3 日間保持してください（7 日間推奨）。詳細については、「バイナリログファイルの削除」をご参照ください。

自己管理 MySQL の場合：

• バイナリロギングを有効化します

• binlog_format を row に設定します

• binlog_row_image を full に設定します

• バイナリログの保持期間を最低 7 日間に設定します

• デュアルプライマリクラスターの場合、log_slave_updates を ON に設定します。詳細については、「自己管理 MySQL データベースのアカウントを作成してバイナリロギングを設定する」をご参照ください。

ソースデータベース

• テーブルには PRIMARY KEY または一意制約（すべてのフィールドが一意）が必要です。これらの制約がないテーブルを使用すると、宛先に重複レコードが生成される可能性があります。

• データベース全体ではなく個別のテーブルを同期対象とする場合、テーブル名やカラム名の変更などの編集を行う際、1 つのタスクで最大 1,000 個のテーブルをサポートします。タスク内のテーブル数が 1,000 を超えると、リクエストエラーが発生します。より大規模なセットの同期には、複数のタスクを設定するか、データベース単位での同期を行ってください。

• DTS では、以下のデータ型は同期されません：BIT、VARBIT、GEOMETRY、ARRAY、UUID、TSQUERY、TSVECTOR、TXID_SNAPSHOT、POINT。

• プレフィックスインデックスはサポートされておらず、タスクが失敗する原因となる可能性があります。

• 同期対象として選択できるのはテーブルのみです。インデックス、パーティション、ビュー、ストアドプロシージャ、関数、トリガー、外部キーは除外されます。

• 同期中に、プライマリキーを変更する DDL 文やコメントを追加する文（例：ALTER TABLE table_name COMMENT='...'）を実行しないでください。これらの操作は無効です。

• スキーマ同期または完全データ同期のフェーズ中は、データベースまたはテーブルのスキーマを変更する DDL 文を実行しないでください。

• ソースが MySQL 8.0.23 以降であり、テーブルに不可視カラムが含まれている場合、DTS はそれらのカラムを読み取れず、データ損失が発生します。タスク開始前に、ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; を実行してカラムを可視化してください。明示的なプライマリキーを持たないテーブルには自動的に不可視プライマリキーが生成されるため、それらも可視化してください。「Invisible Columns」および「Generated Invisible Primary Keys」をご参照ください。

• EncDB が有効化された ApsaraDB RDS for MySQL インスタンスをソースとして使用する場合、完全データ同期はサポートされません。透過的データ暗号化（TDE）が有効化されたインスタンスは、3 つの同期タイプすべてをサポートします。

• 0000-00-00 00:00:00 の DATETIME 値は、宛先で null に変換されます。これを回避するには、ソースで値を 0001-01-01 00:00:00 に変更するか、タスク開始前に宛先フィールドを空欄のままにしてください。

• 同期インスタンスの実行中は、物理バックアップから復元されたデータやカスケード操作によるデータなど、バイナリログの変更操作によって生成されたデータは、送信先に記録または同期されません。このような問題が発生した場合、ビジネスに影響がない場合に限り、影響を受けるデータベースまたはテーブルを同期オブジェクトから削除し、再度追加することができます。詳細については、「同期するオブジェクトを変更する」をご参照ください。

宛先データベース

• 宛先テーブルは、追加最適化（AO）テーブルであってはなりません。

• 宛先テーブルの一意キー（プライマリキーを含む）には、分散キーのすべてのカラムが含まれている必要があります。

• ソーステーブルにプライマリキーがある場合、宛先のプライマリキー列はソースと一致します。ソーステーブルにプライマリキーがない場合、宛先のプライマリキー列は分散キーと一致します。

その他の制限事項

• 同期中に他のソースから宛先に書き込まれたデータは、不整合を引き起こす可能性があります。DTS 実行中は、宛先テーブルへの同時書き込みを避けてください。

• 個別のテーブルがオブジェクトとして選択された場合、pt-online-schema-change などのオンライン DDL ツールはサポートされていません。代わりに、ロックなし DDL 操作を実行するには Data Management (DMS) を使用してください。詳細については、「ロックなし DDL 操作の実行」をご参照ください。

• カラムマッピングを使用する場合、またはソースと宛先のスキーマが異なる場合、ソースに存在し宛先に存在しないカラムは同期されません。

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

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

• 初期完全データ同期中、同時 INSERT 操作により、宛先でテーブルの断片化が発生します。完全同期完了後、宛先の表領域はソースよりも大きくなります。負荷低減のため、初期同期は非ピーク時間帯に実行することを推奨します。

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

自己管理 MySQL ソース

• タスク実行中にプライマリ／セカンダリ スイッチオーバーが発生すると、タスクが失敗します。

• DTS は、最新の同期タイムスタンプと現在のソースタイムスタンプを比較することで同期遅延を算出します。ソースで長期間 DML 操作が実行されない場合、報告される遅延は不正確になる可能性があります。遅延メトリックを更新するには、ソースで DML 操作を実行してください。同期対象としてデータベース全体を選択した場合、遅延メトリックを正確に保つために、1 秒ごとに更新されるハートビートテーブルを作成できます。

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

ApsaraDB RDS for MySQL ソース

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

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

ステップ 1：データ同期タスクページを開く

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

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

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

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

ステップ 2：リージョンの選択

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

新しい DTS コンソールでは、トップナビゲーションバーからリージョンを選択します。

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

タスクの作成 をクリックします。ウィザードで、以下のパラメーターを設定します。

ソースデータベース

宛先データベース

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

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

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

ステップ 5：同期対象および設定の構成

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

次へ：高度な設定 をクリックします。

データ検証

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

高度な設定

ステップ 7：プライマリキーおよび分散キー列の設定

次へ：データベースおよびテーブルフィールドの設定 をクリックします。宛先の AnalyticDB for PostgreSQL インスタンスに同期する各テーブルについて、プライマリキーおよび分散キー列を設定します。

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

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

保存前に同等の OpenAPI パラメーターをプレビューするには、ボタンにカーソルを合わせて OpenAPI パラメーターのプレビュー をクリックします。

DTS は、同期を開始する前に事前チェックを実行します。いずれかの項目が失敗した場合：

• 失敗した項目の横にある 詳細の表示 をクリックし、問題を解決した後、再事前チェック をクリックします。

• 警告項目を安全に無視できる場合は、警告の詳細の確認 をクリックし、ダイアログで 無視 をクリックして OK をクリックし、その後 再事前チェック をクリックします。警告を無視すると、データの不整合が発生する可能性があります。

成功確率 が 100% になるまで待機し、その後 次へ：インスタンスの購入 をクリックします。

ステップ 9：インスタンスの購入および開始

購入 ページで、以下のパラメーターを設定します。

Data Transmission Service（従量課金）サービス利用規約 を読み、チェックボックスをオンにした後、購入および開始 をクリックします。確認ダイアログで OK をクリックします。

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