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

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

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

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

DMマスター

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

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

DMワーカー

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

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

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

dmctl

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

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

アーキテクチャの機能

高可用性

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

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

ノート：

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

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

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