ProxySQL 2.5.0 の Native Group Replication Support を試してみる

この記事は最終更新から1年以上経過しています。内容が古くなっている可能性があります。

【注意】

本記事はベータ版の機能について取り上げていますので、商用や本番環境で使用することはご遠慮ください。

目次

はじめに

ProxySQL – A High Performance Open Source MySQL Proxy

2023/2/5 に Pre-release された ProxySQL 2.5.0 では、リリースノートから幾つかの機能追加が確認できます。

今回はそのうちのひとつ、Group Replication のネイティブサポート実装が追加されたので、試してみました。

Native Group Replication monitoring support for MySQL-8 #4082

これまでの実装

ご存じの方も多いかもしれませんが、ProxySQL の Group Replication への対応は既に v1.4.1 で実装されています。

Group Replication: Native Support for MySQL Group Replication using new configuration table mysql_group_replication_hostgroups , see this blog post

MySQL Group Replication: native support in ProxySQL – lefred blog: tribulations of a MySQL Evangelist

そして、これまでのリリースで度々機能改善や Bug fix が行われてきていました。

具体的な使い方としては、mysql_group_replication_hostgroups テーブルに以下の役割や設定を定義します。

  • writer_hostgroup
  • backup_writer_hostgroup
  • reader_hostgroup
  • offline_hostgroup
  • max_writers
  • writer_is_also_reader
  • max_transactions_behind

加えて、この機能を動作させるには、バックエンド DB 側の sys スキーマにユーザーが手動で追加の専用ファンクションとビューを作成する必要がありました。(ProxySQL 用の監視ユーザーに sys への SELECT 権限も付与)

それらの DDL は公式ドキュメントの以下のページの最下部に掲載されています。

Main (runtime tables definition) – ProxySQL

ただし、この公開 DDL には MySQL 8.0 に対応していない Bug がありました。

ProxySQL 2.0.18 gr_member_routing_candidate_status.viable_candidate return NULL causes infinite crash reboot · Issue #3406 · sysown/proxysql · GitHub

※ワークアラウンドとして、以下のスレッドで提案されている DDL で作成することで MySQL 8.0 でも正常に動作するようになります。
https://github.com/sysown/proxysql/issues/3406#issuecomment-822145789

v2.5.0 のネイティブサポート

今回の機能改善では、これまでのユーザ介入が必要な部分を排除し、ProxySQL 側でセットアップするだけで利用できるようになりました。

既にある AWS Aurora クラスタサポートの仕組み を MySQL 8.0 Group Replication 用に再利用したそうです。

Monitor ‘Group replication’ rework by JavierJF · Pull Request #4082 · sysown/proxysql · GitHub

また、併せて幾つかの既存の Group Replication 監視機能のバグも修正されているとのことです。

  • When writer was set as SHUNNED due to replication lag, and ‘mysql_servers’ table was regenerated (via servers reconfiguration or other action). SHUNNED writer wasn’t considered a found writer, triggering an unwanted server reconfiguration.

  • Since servers present in ‘backup_writer_hostgroup’ where not considered as previously configured writers, everytime the number of available writers exceeded ‘max_writers’ an unwanted server reconfiguration was triggered for each of these ervers at every monitoring action.

セットアップ方法

それでは実際に試してみたいと思います。

公式ドキュメントにはまだ今回の変更に関する説明は追加されていないようですので、多少手探りな部分はありましたがそこまで以前と変わるところはありませんでした。

今回使用する Group Replication 環境の概要は以下の通りです。

  • MySQL Server 8.0.30
  • Oracle Linux Server release 8.7
  • シングルプライマリモード
hostname IP adress
gr-mysql-e1 10.0.2.19
gr-mysql-e2 10.0.2.217
gr-mysql-e3 10.0.2.72

ProxySQL 監視用 DB ユーザーの作成

Group Relication 側に ProxySQL 用の監視ユーザーを事前に作成しておきます。

今回のポイントは、performance_schema スキーマの replication_group_membersreplication_group_member_stats への SELECT 権限を付与する必要があることです。

ProxySQL のインストール

今回使用する v2.5.0 は Pre-release 版なので、RPMパッケージを直接インストールします。

各種設定

サービスを起動して、管理インターフェースにログインします。

監視ユーザなどの設定を行います。

mysql_servers テーブルにホスト情報を投入します。

すべてのホストの hostgroup_id はこの時点では後で定義する writer_hostgroup のもの(2)に設定しています。

※特に writer_hostgroup が全て同一である必要性はありませんが、後程このホストグループが本機能によって役割毎に分散される様子を分かり易くするためこのように設定しています。

本機能の肝となる mysql_group_replication_hostgroups テーブルに定義を投入します。

Runtime に設定がロードされると、直ちにバックエンドDBへチェックが行われます。

Monitor モジュールの mysql_server_group_replication_log テーブルを確認すると、正しく情報が取得できていれば以下のように表示されます。

Runtime の mysql_servers の状態(runtime_mysql_servers) を見てみましょう。

それぞれのノードが役割のホストグループに適切に振り分けられているか確認することができます。

ルーティングの挙動確認

それでは、クライアントからの接続ルーティングがこちらで意図した役割通りになるか簡易的に確認してみます。

通常時

以下の R/W Splitting ルールを設定しておきます。

純粋な SELECT クエリは reader_hostgroup へ、それ以外は writer_hostgroup へルーティングされるようになります。

テスト用のユーザーとテーブルを作成し、一つ目のターミナルでは更新(INSERT)を、二つ目のターミナルは参照(SELECT)を、それぞれ実行します。

  • terminal 1

  • terminal 2

更新処理は writer_hostgroup に属しているプライマリノードのみにルーティングされています。

参照処理は reader_hostgroup に分散ルーティングされています。

プライマリノードを R/W 可能にしていて(mysql_group_replication_hostgroups.writer_is_also_reader=1)、参照処理のルーティング頻度を下げたい場合は mysql_servers.weight を調整しましょう。

プライマリノードダウン時

つぎに、プライマリノードの mysqld を停止させてみます。

ノード3がプライマリに昇格しました。

更新処理は、プライマリノードのシャットダウン中、接続断でエラーとなり、ノード3がプライマリ昇格後、処理再開・ルーティングされています。

参照処理は、プライマリノードのシャットダウン中、データアクセスは継続され、シャットダウン後は生存メンバーの reader_hostgroup でルーティングされています。

ダウンした旧プライマリノードは offline_hostgroup には移されるものの、ステータスは OFFLINE ではなく、SHUNNED に移行されています。

SHUNNED ステータスとは、一時的なエラーで使用不可状態(敬遠)と言う意味です。接続中のセッションは切断され、そのノードへは以降ルーティングされなくなります。また、ヘルスチェックなども無効となります。

OFFLINE_HARD と異なるのは、一時的なエラー扱いなので復帰の可能性を見込んでいるということです。OFFLINE_HARD はサーバー自体を接続先から削除してしまうことと同等になります。

対象ノードが、read_only=1 かつ mysql-monitor_groupreplication_max_transactions_behind_count (デフォルト:3) の回数、transactions_behind のチェックに失敗すると SHUNNED に変更されます。

実際に mysql_server_group_replication_log テーブルを確認してみるとその通りの挙動となっています。

Group Replication 用 Monitor パラメータはヘルスチェック間隔含め幾つか用意されていて、調整が可能です。

各パラメータの説明は以下のページをご確認ください。

MySQL Monitor Variables – ProxySQL

ダウンノードの復帰時

最後に、先ほど停止させた旧プライマリノード(ノード1)の mysqld を再び起動し、Group Replication に自動再参加させます。

復帰ノードは直ちに reader_hostgroup に再度振り分けられました。

参照処理のルーティングも行われるようになりました。

まとめ

以前のバージョンから Group Replication には対応していたので、既に利用しているユーザーも多いのではないでしょうか。

今回の改善で MySQL 8.0 に対応し、さらに ProxySQL 側のみでセットアップできるようになってより導入のし易さが向上したと言えます。

ProxySQL は自身のプロセスを再起動不要で設定変更が可能であることが強みで、あたかもネットワークスイッチのようにルーティングを柔軟に制御できます。

また、クエリルールを駆使した多彩な機能を使えるようになり、ファイアウォールやSQLインジェクション検出、監査ログといったセキュリティ面の機能も充実しています。

ProxySQL と Group Replication を組み合わせることで、望んでいた運用や現在抱えている課題の解決が実現するかもしれません。

冒頭で注意を述べました通り、本記事の機能は執筆時点ではまだ Pre-release 扱いのバージョンですので、遠くない正式リリースの時を楽しみに待ちたいと思います。

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃MySQLのサポート業務に従事している有資格者で構成された技術サポートチームがMySQLに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次