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

このドキュメントでは、データ移行 (DM) のアーキテクチャを紹介します。

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

Data Migration architecture

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

DMマスター

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

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

DMワーカー

DM ワーカーは、特定のデータ移行タスクを実行します。

binlogデータをローカルstorageに保存する
データ移行サブタスクの構成情報の保存
データ移行サブタスクの操作を調整する
データ移行サブタスクの実行状態の監視

DMワーカーの詳細については、 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 ワーカーノードにスケジュールされた後は、スケジュールが実行される前に、元の DM ワーカーノードでエクスポートされた完全なデータを読み取ることができないことを意味します。