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

ProxySQLを使用したOrchestratorの高可用性構成について

以前弊社でもご紹介させていただいたOrchestratorはMySQLやMariaDBのための高可用性ソフトウェアです。

Orchestratorでレプリケーション環境のHAを実現しよう

OrchestratorはMySQLのレプリケーショントポロジを理解し、マスタのフェイルオーバ、スイッチオーバや、スレーブの組み換えを行う事が可能です。
一方でアプリケーションからの負荷分散や、ルーティング先の切り替え等の機能は提供されません。

それらの機能をアプリケーションから透過的に実現するためにはプロキシソフトウェアを使用する事が一般的です。
ProxySQLはMySQL Protocolを理解し、シンプルな負荷分散からルールベースのクエリルーティング等非常に多機能で、MySQLとの相性はバッチリですが、レプリケーション構成におけるフェイルオーバ機能などは実装されていませんでした。

今回は、OrchestratorとProxySQLを使用して障害発生時に対応した環境を構築しました。

環境

サーバ名 ソフトウェア
mysql1 MySQL 8.0.16(master)
mysql2 MySQL 8.0.16(slave)
mysql3 MySQL 8.0.16(slave)
proxysql1 ProxySQL 2.0.4
orchestrator1 Orchestrator 3.0.14

OSはCentOS7です。

Orchestrator用バックエンドDBの設定

Orchestratorは監視データのリポジトリとしてMySQL(MariaDB) or SQLITE3のいずれかが必要ですのでOrchestratorと同じホストにMariaDBをインストールしました。

特にMariaDBである必要はありません。

Orchestratorはcaching_sha2_passwordに未対応ですので、MySQL8.0以降ではorchestratorからの接続ユーザは mysql_native_password を使用するようにご注意ください。

validate password pluginの都合上Passwordをあわせています。
上記を行う場合は後述するOrchestaratorの設定ファイル上も適切に合わせて下さい。

Orchestratorの設定

以下の通りOrchestratorを設定します

/etc/orchestrator.conf.json は以下の箇所を編集します

起動します。

バックエンドDBへの接続に問題がある場合、startはOkとなりますが実際にはプロセスは停止するという事がありましたので、必ず起動後はstatusをご確認ください。

上記の設定はデフォルトのユーザを使い、最低限の設定を行った状態です。

ターゲットデータベースの構築

今回はMySQLでGTIDを有効化した環境を構築します。
すべてを解説はしませんが、必要に応じてマニュアルをご確認ください。

以下はすべてのサーバで実施します

設定ファイルのパラメータでレプリケーション関連以外では以下を変更しています。

パラメータ名 説明
report_host orchestratorはマスタに接続しているスレーブのホスト名をサンプル設定では show slave statusから取得します。
そのため、全サーバで設定します。
report_port report_hostと同様の理由により、設定します
max_connect_errors Orchestratorのハートビートの失敗による接続ブロックを回避するために値を引き上げます

マスタでOrchestratorに必要なユーザを作成します。
ユーザ名、パスワードは /usr/local/orchestrator/orchestrator-sample,json.cnf に合わせています。

同様にマスタでProxySQL用ユーザを作成します。
監視用(monitor)、アプリ用(app_user)となります。

スレーブでレプリケーションを開始します

ProxySQLの設定

ProxySQLのオフィシャルの手順を参考にインストールを行い、起動、接続します。

ターゲットであるMySQLサーバ等の設定をProxySQLに行います。

最低限以下を行います

  • ターゲットサーバの登録(mysql_servers)
  • レプリケーション監視の有効化(mysql_replication_hostgroups)
  • 監視ユーザの認証情報の設定(mysql-monitor_username, mysql-monitor_password)
  • 接続用ユーザ登録(mysql_users)
  • READ/WRITE ルーティング設定(mysql_query_rulees)

なお今回は検証という事で簡単なルーティング設定を行っていますが、実際に導入する場合は個々のSQLのdigest値をもとに厳密なルーティング設定を行う事が推奨されています。

https://proxysql.com/blog/configure-read-write-split

テスト接続用のMySQL Clientのインストールと設定を行います。

設定が完了したら簡単なテストを行います。

Orchestratorにターゲットサーバを登録

orchestratorでdiscoverコマンドをを実行しmysql1(マスタ)を登録します。

※debug: trueが設定ファイルで設定されているため、ログが実際には出力されますが見やすさのために省略しています

topologyで確認した結果の通り、Orchestratorはすべてのスレーブを自動的に認識しています。

Webインタフェースからも登録されていることが確認できます

フェイルオーバテスト

今回はREAD/WRITEの処理を0.3秒間隔で繰り返し、マスタを停止した場合の動作を確認します。

WRITEのためのテスト用にターゲットにテーブルを作成します。

READの接続は以下のように実施します

WRITEの接続は以下のように実施します

マスタを停止します。
10:51:01にコマンドを実行し、完全に停止したのは10:51:11付近です。

READ処理については即時にマスタがルーティング先から切り離されました。

WRITE処理については一部のクエリはエラーが返りましたが、10秒程度で復旧しています。

mysql2(新マスタ)ではread_onlyが解除されました。

Orchestrator視点

Orchestratorのログは /var/log/orchestrator.log です。
ログが多いため特筆すべき行の抜粋となります。

ProxySQL視点

こちらも抜粋となります。
Orchestratorによってread_only=0が設定された1秒後にはWriterとして認識され、WRITEに関しての復旧が完了しています。

なお、ProxySQLには自動リトライ機能が備わっているため、一定数のエラーはProxySQL側で受けてアプリにエラーを返さないという恩恵も受けています。
Writeに関しては候補が無いためエラーとなりましたが、Readについてはmysql1にルーティングされた処理はmysql2, mysql3でリトライされたためエラーが一度も発生しなかったと考えられます。

まとめ

  • 今回の検証では正常にフェイルオーバが行われる事が確認できました
  • Write処理のエラーについては一定数発生しましたが、10秒程度で復旧が確認できました
  • Read処理についてはエラーは返ることはありませんでした
  • ProxySQLはリトライ機能やREAD/WRITE分割等、豊富な機能が実装されているため、単純なVIPによる切り替えよりも上手く動作するかもしれません

ぜひ検証にお役立て下さい。


SmartStyle

 

Return Top