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

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

DM は、DM-master、DM-worker、および dmctl の 3 つのコンポーネントで構成されています。

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

DMマスター

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

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

DMワーカー

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

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

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

dmctl

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

• データ移行タスクの作成、更新、または削除
• データ移行タスクの状態を確認する
• データ移行タスクのエラー処理
• データ移行タスクの構成が正しいことを確認する

アーキテクチャの機能

高可用性

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

デプロイされた DM-worker ノードの数が上流の MySQL/MariaDB ノードの数を超えると、余分な DM-worker ノードはデフォルトでアイドル状態になります。 DM-worker ノードがオフラインになるか、DM-master リーダーから分離された場合、DM-master は、元の DM-worker ノードから他のアイドル状態の DM-worker ノードへのデータ移行タスクを自動的にスケジュールします。 (DM-worker ノードが隔離されている場合、そのノードでのデータ移行タスクは自動的に停止します);使用可能なアイドル状態の DM-worker ノードがない場合、元の DM-worker のデータ移行タスクは、1 つの DM-worker ノードがアイドル状態になるまで一時的にハングし、その後、タスクが自動的に再開されます。

ノート：

データ移行タスクが完全なエクスポートまたはインポートの処理中の場合、移行タスクは高可用性をサポートしません。主な理由は次のとおりです。

• フル エクスポートの場合、MySQL は特定のスナップショット ポイントからのエクスポートをまだサポートしていません。これは、データ移行タスクが再スケジュールまたは再開された後、エクスポートは前の中断ポイントから再開できないことを意味します。

• フル インポートの場合、DM-worker はノード間でエクスポートされたフル データの読み取りをまだサポートしていません。これは、データ移行タスクが新しい DM-worker ノードにスケジュールされた後、スケジュールが発生する前に元の DM-worker ノードでエクスポートされた完全なデータを読み取ることができないことを意味します。