スマートスタイル TECH BLOG|データベース&クラウドの最新技術情報を配信

Orchestrator の Group Replication 初期サポート実装について

はじめに

過去弊社ブログでも何度か取り上げている Orchestrator(MySQL用高可用性&レプリケーション管理ツール)ですが、GAリリースバージョン v3.2.3 のリリースノートをチェックしたところ Group Replication の初期サポート実装が追加されています。

今回の記事では、この内容について確認してみたいと思います。

変更点を確認してみる

上記の Pull Request #1180 および FAQ の Group Replication に関する記載内容から今回の「ベーシックサポート」の内容を拾ってみます。

  • Group Replication(シングルプライマリーモードのみ)をサポート
    • Orchestrator は plain-old-MySQL-replication のサポートを根幹に置いているので、シングルプライマリーモード構成であれば、各セカンダリーはプライマリーからのレプリカと見做せるためのようです。
  • UI上でクラスターを指定してトポロジーを確認すると、グループメンバーが1クラスター内に全て認識・表示されるようになりました。
    • これまでのバージョンでは、Group Replicationをトポロジーグループとして識別できず、各メンバー毎に表示するしかできませんでした。
    • 専用のアイコンが表示されるようになりました。(アイコンにマウスオーバーするとGroup Replication上のロールとステータスがポップアップ表示されます)
  • 以前のバージョンまでは Group Replication のメンバーからレプリケーションされた非同期レプリカ の GTID を errant として見做していたが、そうではなく正常と識別するようになりました。
  • ユーザーが、Orchestrator 経由で Group Replication に対して誤ったトポロジー変更を実行することを防ぐようになりました。
    具体的には、以下のような操作を行うとエラーとなります。

    • プライマリーをセカンダリーからレプリケートするように設定しようとする
    • セカンダリーを別の場所からレプリケートするように移動させようとする

動作確認してみる

簡易的ではありますが、MySQL 8.0.21 - 3ノード Group Replication環境(MySQL Shell の InnoDB Cluster デプロイ用APIを使って構築)を Orchestrator v3.2.3 にてディスカバリーさせ、Group Replication のトポロジー変化にどのように対応しているのか、確認してみました。

事前に必要な設定

Group Replication のメンバーステータスを取得・監視するため、Orchestrator クライアントユーザー(MySQL側ユーザー)に、performance_schema.replication_group_members の参照権限を追加する必要があります。

orchestrator/configuration-discovery-basic.md at master · openark/orchestrator · GitHub

※ユーザー名・ホスト名は環境に合わせて適宜変更してください

トポロジー・グループメンバーの状態表示

基本的には、上述のperformance_schema.replication_group_membersテーブルから読み取った状態を表示していることが確認できます。

  • 正常時

    ただ、orchestrator-client でトポロジーを確認したところ、グループメンバーの最後のノードしか表示されません…
    恐らくAPIのBugかもしれませんので、後ほど Issue をあげてみようと思います。

  • セカンダリーノード停止時

    通常のレプリケーション構成の場合と同じ仕様で、停止ノードが黒枠で表示されています。
    ただ、アイコンのポップアップでは ONLINE のままになっていますね…

    これは監視対象テーブル上に停止したノードのレコードが無いからなのかと推察します。

    MySQL Shell からステータスを確認してみますと確かに MISSING になっているので、この場合はこのようなステータスが反映された方がより良いかもしれません…

    その後、起動してグループに再参加させている途中の RECOVERING ステータスは垣間見ることが出来ました。

  • プライマリーノード停止時
    プライマリーのgr-node1を停止すると、トポロジーが再グループ(分断)されました。


    残アクティブノードのグループは以下のように表示されています。

    元プライマリーをグループレプリケーションに復帰させると、gr-node3クラスターのトポロジーに再グルーピングされました。

    グループレプリケーションメンバーの障害復旧は正常に行われ、Orchestratorは復旧後の状態を正常に把握できています。
    あくまで、障害時の高可用性はグループレプリケーション本来の挙動に則っていて、Orchestrator が自動リカバリーを行ってはいないようです。(当然と言えばその通りですが)

  • プライマリー変更時

    プライマリーがgr-node1に戻ったことを反映させています。

  • メンバー追加時
    ノード4と5(gr-node4,gr-node5)をグループレプリケーションメンバーに追加してみます。

    ※追加ノードはちょうど8.0.22がリリースされた直後に作成したインスタンスです。

  • メンバー削除時
    Group Replication 上からメンバーを削除した場合、Orchestrator 上では Problem: group replication member not online として扱われていますので、完全に削除するには Orchestrator 側で削除したメンバーをforget してあげる必要がありました。

予期せぬトポロジーリファクタリング操作の防止

Orchestrator上からグループレプリケーションのトポロジーを変更しようとしても防がれることが確認できます。(エラーメッセージがでてオペレーションが許可されません)

  • プライマリーをセカンダリーからレプリケートするように設定しようとすると…


  • セカンダリーを別の場所からレプリケートするように移動させようとすると…


Group Replicationのメンバーをソースとしたレプリケーション構成が組まれている場合

pull reqest に書いてあった通り、セカンダリーメンバーにぶら下げた非同期レプリケーションも正常に認識されます。

ただし、残念ながらレプリカのソースとなるセカンダリーメンバーがダウンしたら自動フェイルオーバーはされません。(トポロジー上で障害は検知されている模様)
元レプリカは元のクラスターからは再グループされ、孤立状態となっています。

Orchestrator のログメッセージ上からは、RecoverDeadIntermediateMasterのトポロジリカバリーを試みようとしていますが、ソース候補が見つかっていないようです。

Group Replication のプライマリーノードを別ノードのレプリカにした場合

プライマリーメンバー gr-node1 を ar-node2 のレプリカに設定してみました。
構成当初はソースも Group Replication のトポロジー内に認識されますが、時間経過後、Group Replication のトポロジーマップが吸収されてしまいました。

まとめ

最近の MySQL における動向として、InnoDB Cluster および Group Replication は高可用性構成の中核として位置付けられているようですので、Orchestorator もサポートするようになったことは非常に重要なアップデートではないかと考えています。
まだ現時点では、基本的なトポロジー監視レベルの段階なのでOrchestoratorの強力な特徴であるトポロジーの自動リカバリが活かせないものの、機能拡張や Bug Fix 含め、今後の活発な開発に期待したいと思います。


MySQL

 

Return Top