Data Transmission Service (DTS) は、高可用性 (HA) を中心に構築されたモジュラーアーキテクチャを採用しています。各モジュールは、プライマリ/セカンダリの冗長性を備えたサーバーで実行されます。HA マネージャーは、すべてのサーバーのヘルスチェックを継続的に実行し、例外を検出すると、最小限のレイテンシでワークロードを正常なサーバーに切り替えます。継続的なレプリケーション (データ同期と変更追跡) の場合、HA マネージャーはデータソースのエンドポイントの変更も検出し、接続を自動的に再設定します。

- プライマリ/セカンダリの冗長性
各 DTS モジュールは、冗長性のためにプライマリ/セカンダリ アーキテクチャでデプロイされます。ディザスタリカバリシステムは、各サーバーで継続的にヘルスチェックを実行します。サーバーに障害が発生した場合、そのワークロードは最小限のレイテンシで正常なサーバーに切り替えられます。
- 動的なエンドポイント検出
データ同期タスクと変更追跡タスクの場合、ディザスタリカバリシステムはデータソースのエンドポイントへの変更を検出します。エンドポイントの変更が検出された場合、ディザスタリカバリシステムはデータソースを再設定し、接続が安定したままであることを保証します。
データ移行モードでの DTS の仕組み

完全なデータ移行は、スキーマ移行、完全なデータ移行、増分データ移行の 3 つの連続したフェーズで実行されます。データ移行タスクを設定する際にこれら 3 つすべてのフェーズを選択すると、移行プロセス全体を通じてソースデータベースを稼働させ続けることができます。
スキーマ移行:DTS は、データが移動する前にターゲットデータベースにスキーマを再作成します。異種データベース間の移行の場合、DTS はソースデータベースの DDL (データ定義言語) を解析し、それをターゲットデータベースの構文に変換して、スキーマオブジェクトを再作成します。
完全なデータ移行:DTS は、ソースからターゲットに既存データを移行します。このフェーズ中、ソースデータベースはオンラインの状態を維持し、書き込みを受け入れ続けます。これらの進行中の書き込みをキャプチャするために、DTS は完全なデータ移行の開始時に増分データリーダーをアクティブ化します。増分データは解析、再フォーマットされ、完全移行の実行中に DTS サーバーにローカルで保存されます。
増分データ移行:完全なデータ移行が完了した後、DTS はローカルに保存された増分データを取得し、それをターゲットに適用します。このフェーズは、ターゲットがソースと同期し、レプリケーションラグが安定した状態に達するまで継続します。
データ同期モードでの DTS の仕組み

データ同期モードは、2 つのデータストア間で進行中のデータ変更をレプリケーションします。これは一般的に、OLTP (オンライントランザクション処理) がトランザクションワークロードを処理し、OLAP (オンライン分析処理) が分析クエリを処理する、OLTP から OLAP へのレプリケーションに使用されます。
データ同期タスクは、2 つのフェーズを順番に実行します:
初期データ同期:DTS は、ソースからターゲットに既存データを同期します。
リアルタイムデータ同期:DTS は、進行中のデータ変更を継続的にレプリケーションして、ターゲットをソースと同期させ続けます。
2 つのコンポーネントが進行中のレプリケーションを処理します:
トランザクションログリーダー:適切なプロトコル (たとえば、ApsaraDB RDS for MySQL インスタンスの場合は binlog ダンププロトコル) を介してソースインスタンスに接続します。増分ログを読み取り、データを解析、フィルター処理、変換してから、DTS サーバーにローカルで永続化します。
トランザクションログ適用モジュール:トランザクションログリーダーから更新を取得し、レプリケーション対象のオブジェクトに関係のない変更をフィルターで除外し、残りの変更をターゲットデータベースに適用します。この適用モジュールは、各トランザクションの ACID 特性 (原子性、一貫性、独立性、永続性) を維持します。
両方のコンポーネントは冗長モードで実行されます。いずれかのコンポーネントで例外が発生した場合、HA マネージャーは正常なサーバーでトランザクションログの実行を再開します。
変更追跡モードでの DTS の仕組み

変更追跡モードでは、ApsaraDB RDS インスタンスの増分データログにリアルタイムでアクセスできます。DTS SDK を使用して変更追跡サーバーでログを消費し、要件に合わせてカスタムのデータ消費ルールを定義します。
ログプロセッサは、適切なプロトコル (たとえば、ApsaraDB RDS for MySQL インスタンスの場合は binlog ダンププロトコル) を介してソースインスタンスに接続します。増分ログを読み取り、構文を解析、フィルター処理、変換してから、DTS サーバーにデータをローカルで保存します。
DTS は、2 つのレベルで高可用性を保証します:
ログプロセッサの HA:HA マネージャーがログプロセッサで例外を検出すると、正常なサービスノードでログプロセッサを再起動します。
SDK 消費の HA:単一の変更追跡タスクに対して、複数の SDK ベースの消費プロセスを開始します。サーバーは一度に 1 つのプロセスを通じて増分データをプッシュします。そのプロセスで例外が発生した場合、サーバーは自動的に別の消費プロセスに切り替わります。