このトピックでは、Data Transmission Service (DTS) のアーキテクチャと、各レプリケーションモードでの動作について説明します。
DTSアーキテクチャ
アーキテクチャの説明
プライマリ /セカンダリ冗長性
DTSの各モジュールは、プライマリ /セカンダリの冗長性を持つサーバーに展開されます。 HAマネージャは、各サーバのヘルスチェックを継続して実行します。 サーバーで例外が発生した場合、そのサーバーのワークロードは最小限の遅延で正常なサーバーに切り替えられます。
エンドポイント変更検出
データ同期や変更追跡などの継続的なデータ複製の場合、HAマネージャはデータソースのエンドポイントに加えられた変更を検出します。 インスタンスエンドポイントが変更された場合、HAマネージャーはデータソースを再構成して接続を確保します。
データ移行モードでのDTSの仕組み
完全なデータ移行プロセスは、スキーマ移行、完全データ移行、増分データ移行の3つのフェーズで構成されています。 データ移行中にソースデータベースを運用可能にするには、データ移行タスクを構成するときにすべてのフェーズを選択する必要があります。
スキーマ移行: データが移行される前に、DTSは移行先データベースにスキーマを再作成します。 異種データベース間のデータ移行の場合、DTSはソースデータベースのDDLコードを解析し、そのコードをターゲットデータベースの構文に変換します。 次に、DTSはターゲットデータベースにスキーマオブジェクトを再作成します。
フルデータ移行: DTSは、移行元データベースから移行先データベースに履歴データを移行します。 ソースデータベースは動作し続けることができ、ソースデータベースのデータ更新はこのプロセスで停止しません。 DTSは、増分データリーダーを使用して、完全なデータ移行フェーズ中に発生する進行中のデータ更新をキャプチャします。 増分データ読み取りは、フルデータ移行の開始時に有効になります。 フルデータ移行中、増分データは解析され、再フォーマットされ、DTSサーバーにローカルに保存されます。
増分データ移行: 完全なデータ移行が完了すると、DTSはDTSサーバーにローカルに保存されている増分データを取得し、データを再フォーマットして移行先データベースに移行します。 このプロセスは、すべての進行中のデータ変更が宛先データベースにレプリケートされ、宛先データベースがソースデータベースと同期するまで続きます。
データ同期モードでのDTSの仕組み
データ同期モードでは、DTSは2つのデータストア間で進行中のデータ変更をレプリケートします。 このモードは、通常、OLTPからOLAPへの複製に使用されます。 OLTPはオンライントランザクション処理を表し、OLAPはオンライン分析処理を表します。 データ同期タスクは、次のフェーズで構成されます。
初期データ同期: DTSは、移行元データベースの履歴データを移行先データベースに同期します。
リアルタイムデータ同期: DTSは進行中のデータ変更を同期し、ターゲットデータベースをソースデータベースと同期させます。
進行中のデータ変更を同期するために、DTSはトランザクションログで動作する2つのコンポーネントを使用します。
トランザクションログリーダー: トランザクションログリーダーは、ソースインスタンスからデータを取得します。 解析、フィルタリング、および構文変換後、データはDTSサーバーでローカルに保持されます。 トランザクションログリーダーは、対応するプロトコルを介してソースインスタンスに接続し、ソースインスタンスの増分データに関するログを読み取ります。 たとえば、このリーダーはbinlogダンププロトコルを使用してApsaraDB RDS For MySQLインスタンスに接続します。
Transaction log applier: トランザクションログapplierは、トランザクションログリーダーからデータの更新を取得し、レプリケートされるオブジェクトに関連しない更新を除外し、フィルター処理された更新をターゲットデータベースに適用します。 このプロセスでは、トランザクションログアプライアは、トランザクションのアトミック性、一貫性、分離、および耐久性 (ACID) プロパティを維持します。 トランザクションログリーダーとトランザクションログアプライアの両方が冗長モードでデプロイされます。 HAマネージャは, 各サーバのヘルス状態を確認します。 例外が発生すると、正常なサーバーでトランザクションログの実行が再開されます。
変更追跡モードでのDTSの仕組み
変更追跡モードでは、ApsaraDB RDSインスタンスの増分データに関するログをリアルタイムで取得できます。 DTS SDKを使用して、変更追跡サーバーのログを追跡できます。 要件に基づいてデータ消費ルールをカスタマイズすることもできます。
ログプロセッサは、ソースデータベースからデータを取得します。 解析、フィルタリング、および構文変換の後、データはDTSサーバーにローカルに保存されます。
ログプロセッサは、対応するプロトコルを介してソースインスタンスに接続し、ソースインスタンスの増分データに関するログを読み取ります。 たとえば、このログプロセッサは、binlogダンププロトコルを使用してApsaraDB RDS For MySQLインスタンスに接続します。
DTSは、ログプロセッサとSDKベースの消費プロセスの高可用性を保証します。
ログプロセッサの高可用性を確保するために、ログプロセッサで例外が検出されると、HAマネージャは正常なサービスノードでログプロセッサを再起動します。
サーバー上のSDKベースの消費プロセスの高可用性を確保するために、DTSでは、1つの変更追跡タスクに対して複数のSDKベースの消費プロセスを開始できます。 サーバーは、一度に単一のプロセスを使用して増分データをプッシュします。 プロセスで例外が発生した場合、サーバーは別の消費プロセスを使用して増分データをプッシュします。