📣

TiDB Cloud Serverless が
Starter
に変わりました!このページは自動翻訳されたものです。
原文はこちらからご覧ください。

アップストリーム MySQL インスタンス間の DM ワーカー接続を切り替える

DM-worker が接続するアップストリーム MySQL インスタンスでダウンタイム メンテナンスが必要になった場合、またはインスタンスが予期せずクラッシュした場合は、DM-worker 接続を同じ移行グループ内の別の MySQL インスタンスに切り替える必要があります。

注記:

  • DM ワーカー接続は、同じプライマリ - セカンダリ移行クラスター内のインスタンスにのみ切り替えることができます。
  • 新しく接続する MySQL インスタンスには、DM-worker に必要なbinlogが必要です。
  • DM ワーカーは GTID セット モードで動作する必要があります。つまり、対応するソース構成ファイルでenable-gtid: true指定する必要があります。
  • 接続切り替えは以下の2つのシナリオのみをサポートします。各シナリオの手順を厳密に守ってください。そうしないと、新しく接続されたMySQLインスタンスに合わせてDMクラスタを再デプロイし、データ移行タスクを最初からやり直す必要がある場合があります。

GTID セットの詳細については、 MySQLドキュメントを参照してください。

仮想IP経由でDMワーカー接続を切り替える

DM-worker が仮想 IP (VIP) を介してアップストリーム MySQL インスタンスに接続する場合、VIP 接続を別の MySQL インスタンスに切り替えると、アップストリーム接続アドレスは変更されずに、DM-worker に接続されている MySQL インスタンスが切り替わります。

注記:

このような状況では、DMに必要な変更を加えてください。そうしないと、VIP接続を別のMySQLインスタンスに切り替えた際に、DMが新旧のMySQLインスタンスに同時に異なる接続で接続してしまう可能性があります。このような状況では、DMに複製されたbinlogが、DMが受信する他のアップストリームステータスと一致しなくなり、予期しない異常やデータ損傷が発生する可能性があります。

あるアップストリーム MySQL インスタンス (DM ワーカーが VIP 経由で接続している場合) を別のアップストリーム MySQL インスタンスに切り替えるには、次の手順を実行します。

  1. query-statusコマンドを使用して、binlogレプリケーションの現在の処理単位が下流に複製したbinlogに対応するGTIDセット( syncerBinlogGtid )を取得します。これらのセットをgtid-Sとしてマークします。
  2. 新しいMySQLインスタンスでSELECT @@GLOBAL.gtid_purged;コマンドを使用して、削除されたバイナリログに対応するGTIDセットを取得します。これらのセットをgtid-Pとしてマークします。
  3. 新しいMySQLインスタンスでSELECT @@GLOBAL.gtid_executed;コマンドを使用して、正常に実行されたすべてのトランザクションに対応するGTIDセットを取得します。これらのセットにgtid-Eとマークを付けます。
  4. 以下の条件が満たされていることを確認してください。満たされていない場合、DM-work 接続を新しい MySQL インスタンスに切り替えることはできません。
    • gtid-Sにはgtid-P含まれます。4 gtid-P空になる場合があります。
    • gtid-Eにはgtid-S含まれます。
  5. pause-task使用すると、データ移行の実行中のすべてのタスクが一時停止されます。
  6. 新しい MySQL インスタンスに直接送信されるように VIP を変更します。
  7. 前の移行タスクを再開するには、 resume-task使用します。

DM-workerが接続する上流のMySQLインスタンスのアドレスを変更する

DM-worker 設定を変更して、DM-worker をアップストリーム内の新しい MySQL インスタンスに接続するには、次の手順を実行します。

  1. query-statusコマンドを使用して、binlogレプリケーションの現在の処理単位が下流に複製したbinlogに対応するGTIDセット( syncerBinlogGtid )を取得します。このセットをgtid-Sとしてマークします。
  2. 新しいMySQLインスタンスでSELECT @@GLOBAL.gtid_purged;コマンドを使用して、削除されたバイナリログに対応するGTIDセットを取得します。このセットをgtid-Pとしてマークします。
  3. 新しいMySQLインスタンスでSELECT @@GLOBAL.gtid_executed;コマンドを使用して、正常に実行されたすべてのトランザクションに対応するGTIDセットを取得します。これらのセットをgtid-Eとしてマークします。
  4. 以下の条件が満たされていることを確認してください。満たされていない場合、DM-work 接続を新しい MySQL インスタンスに切り替えることはできません。
    • gtid-Sにはgtid-P含まれます。4 gtid-P空になる場合があります。
    • gtid-Eにはgtid-S含まれます。
  5. stop-task使用すると、データ移行の実行中のタスクがすべて停止します。
  6. operator-source stopコマンドを使用して、古い MySQL インスタンスのアドレスに対応するソース構成を DM クラスターから削除します。
  7. ソース構成ファイル内の MySQL インスタンスのアドレスを更新し、 operate-source createコマンドを使用して DM クラスターに新しいソース構成を再ロードします。
  8. 移行タスクを再開するにはstart-task使用します。

このページは役に立ちましたか?