データ移行アーキテクチャ

このドキュメントでは、データ移行 (DM) のアーキテクチャについて説明します。

DM は、DM マスター、DM ワーカー、dmctl の 3 つのコンポーネントで構成されます。

Data Migration architecture

アーキテクチャコンポーネント

DMマスター

DM-master は、データ移行タスクの操作を管理およびスケジュールします。

DMクラスタのトポロジ情報の保存
DMワーカープロセスの実行状態の監視
データ移行タスクの実行状態の監視
データ移行タスクを管理するための統合ポータルを提供する
シャーディングシナリオにおける各インスタンスのシャーディングされたテーブルの DDL 移行の調整

DMワーカー

DM-worker は特定のデータ移行タスクを実行します。

binlogデータをローカルstorage
データ移行サブタスクの構成情報を保存する
データ移行サブタスクの操作のオーケストレーション
データ移行サブタスクの実行状態の監視

DM-workerの詳細についてはDMワーカー紹介参照してください。

dmctl

dmctl は、DM クラスターを制御するために使用されるコマンドラインツールです。

データ移行タスクの作成、更新、または削除
データ移行タスクの状態を確認する
データ移行タスクのエラー処理
データ移行タスクの構成の正確さの検証

アーキテクチャの特徴

高可用性

複数のDMマスターノードをデプロイする場合、すべてのDMマスターノードは組み込みのetcdを使用してクラスタを形成します。DMマスタークラスタは、クラスタノード情報やタスク設定などのメタデータを保存するために使用されます。etcdによって選出されたリーダーノードは、クラスタ管理やデータ移行タスク管理などのサービスを提供します。したがって、利用可能なDMマスターノードの数がデプロイされたノードの半数を超えても、DMクラスタは正常にサービスを提供できます。

デプロイされた DM ワーカーノードの数が上流の MySQL/MariaDB ノードの数を超える場合、超過した DM ワーカーノードはデフォルトでアイドル状態になります。DM ワーカーノードがオフラインになったり、DM マスターリーダーから分離したりした場合、DM マスターは元の DM ワーカーノードのデータ移行タスクを他のアイドル状態の DM ワーカーノードに自動的にスケジュールします。（DM ワーカーノードが分離されると、そのノード上のデータ移行タスクが自動的に停止されます。）利用可能なアイドル状態の DM ワーカーノードがない場合、元の DM ワーカーのデータ移行タスクは、1 つの DM ワーカーノードがアイドル状態になるまで一時的に停止され、その後タスクが自動的に再開されます。

注記：
データ移行タスクがフルエクスポートまたはインポートの処理中の場合、移行タスクは高可用性をサポートしません。主な理由は次のとおりです。
完全エクスポートの場合、MySQL は特定のスナップショットポイントからのエクスポートをまだサポートしていません。つまり、データ移行タスクが再スケジュールまたは再開された後、前回の中断ポイントからエクスポートを再開することはできません。
フルインポートの場合、DM-worker はノード間でエクスポートされたフルデータの読み取りをまだサポートしていません。つまり、データ移行タスクが新しい DM-worker ノードにスケジュールされた後、スケジュールが実行されるまで、元の DM-worker ノードでエクスポートされたフルデータを読み取ることはできません。