スマートスタイル TECH BLOG

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

OrchestratorとはGithub社のDBAであるShlomi Noach氏が開発した、MySQL用レプリケーション管理用ソフトウェアです。

Orchestrator documentation

自動フェイルオーバ、自動フェイルバックの機能を備えており、MHAやPacemakerの代替となりうるソリューションです。

今回は、ごく一般的なマスタースレーブ構成のMySQLを、Orchestratorで管理する方法についてご紹介します。

環境構成

検証に使用する環境は以下の構成です。

Hostname IP 用途
test1 192.168.122.211 MySQL マスタサーバ
test2 192.168.122.212 MySQL スレーブサーバ1
test3 192.168.122.213 MySQL スレーブサーバ2
test4 192.168.122.214 Orchestrator + バックエンド用MySQLサーバ

OSにはCentOS7を使用しました。

MySQLサーバは一般的な非同期レプリケーション構成までセットアップ済みとします。

Orchestratorのインストール

Orchestratorにはプレインストール用スクリプトが用意されていますので、そちらを使用します。

Orchestratorは以下のディレクトリにインストールされました。

バックエンドDBの作成

OrchestratorはバックエンドデータベースサーバにSQLITE3MySQLを使用します。
今回はMySQLをインストールしました。

Orchestrator用のスキーマ、ユーザーをMySQLに作成します。

なお、今回はローカルホストにインストールしたMySQLを使用していますが、Orchestrator自身の可用性を高めるために、リモートのレプリケーション構成のMySQLを使用することも可能です。

設定ファイルの作成

Orchestratorは、以下の順序で設定ファイルを探します。

  • orchestrator -c オプションで指定したファイル
  • /etc/orchestrator.conf.json
  • conf/orchestrator.conf.json
  • orchestrator.conf.json

今回は、/etc/orchestrator.cnf.jsonに設定ファイルを作成します。
/usr/local/orchestrator/orchestrator-sample.conf.json をベースに必要な部分のみ変更します。

サンプル設定ファイルから以下を変更します。

データベース接続情報

バックエンドDB、ターゲットDBへの接続情報を設定する必要があります。

接続ユーザー、パスワードは以下の部分に設定する事が可能です。

別の指定方法として、MySQLTopologyCredentialsConfigFileや、MySQLOrchestratorCredentialsConfigFileがあります。

パスに指定するファイルは以下の内容です。

この方法が優れているのは、環境変数が使用できる点です。よりセキュアに設定を行うことができます。

リカバリフィルタ

サンプルではリカバリターゲットフィルタ部分が適当な文字列になっています。
追加するクラスタ名がここにマッチしないと停止時のフェイルオーバは行われません。
今回はワイルドカードを指定します。

ターゲットデータベースサーバの設定

orchestratorからの監視用ユーザーを作成する必要があります。

my.cnfでは、バイナリログ、GTIDの有効化と、いくつかの設定を行いました。
なおGTIDは必須ではありません。

Orchestratorは監視対象となるMySQL自身から正常であるかどうか、という情報を収集します。
ですので、各ターゲットDBにおいてなるべく早いタイミングで異常を検知することで迅速なフェイルオーバが可能となります。
slave_net_timeoutを短くすることに加え、再接続間隔も短いほうが良いでしょう。

上記の設定を行うと、問題が発生した場合に非常に短い間隔で再接続とエラーを繰り返します。

通常、適切な設定が行われていればスレーブからマスタへの接続に失敗する事はありませんが、接続失敗回数がmax_connect_errorsの回数を超えるとマスタへの接続がブロックされてしまいます。

ですので、念の為max_connect_errorsも引き上げています。

Orchestratorの実行

設定が済んだところでOrchestratorを起動します。

orchestrator-clientによる操作

今回Orchestratorの操作にはorchestrator-clientを使用しました。
orchestrator-clientはorchestratorへREST API経由で操作を行うためのCLIツールです。
orchestrator本体と概ね同じ事が実行できます。

orchestrator-clientの準備

内部的にjqを使用しているため、別途インストールします。

利用前にORCHESTRATOR_API環境変数にREST APIのエンドポイントのベースURLを設定する必要があります。
orchestrator-clientのPATHと一緒に.bashrcに記載しておきます。

データベースクラスタの追加と管理

まずは、Orchestratorにデータベースクラスタを追加します。
マスタサーバを追加すると、スレーブサーバはクラスタの一部として自動的に追加されます。
クラスタ名にはデフォルトではマスタサーバの名前が使用されます。

登録したクラスタを確認します。

クラスタ内のトポロジを確認すると、全てのサーバが監視対象となっている事がわかります。

おっと、スレーブサーバをread_onlyにするのを忘れていました。
その場合もわざわざ各サーバにログインする必要は無く、orchestrator-clientから実行できます。

他にもOrchestratorから様々な管理操作が行えます。
ちなみにクラスタを削除したいときは、forget-cluster、サーバを削除したいときはforgetです。
詳しくはorchestrator-client -c helpをご確認ください。

フェイルオーバの準備

フェイルオーバについては、以下のドキュメントにまとまっています。

https://github.com/github/orchestrator/blob/master/docs/topology-recovery.md

Orchestratorはフェイルオーバがトリガされると以下の順序で処理を行います。

  • Pre-recovery hooks (external processes execution)
  • Healing of topology
  • Post-recovery hooks(Post-recovery failer hooks)

OrchestratorはHealing of topologyのフェーズでレプリケーションマスタの切り替えを自動的に行いますが、
Pre-recovery hooksやPost-recovery hooksでどのように前処理を行い、アプリケーションからの接続先を切り替えるのかという点はユーザーが作り込む必要があります。
今回はシンプルに、Orchestrator上のdnsmasqのAレコードを書き換える事でサービス側のフェイルオーバを実現します。

dnsmasqの準備

masterサーバのIPを解決するように設定しておきます。
なお、今回は検証ですので確認のための接続もOrchestrator上から行います。

/etc/orchestrator.conf.jsonにフェイルオーバ後の処理を追加します。
PostMasterFailoverProcessesにJSONのリスト形式で実行したい処理を追記していきます。
FailureDetectionPeriodBlockMinutesはフラッピングが発生した際に再度フェイルバックするような動作を行わないための時間(分)です。
今回は検証のために1としました。

/usr/local/orchestrator/change_master_arec.shは以下のように作成しました。

実行権限を付与します。

フェイルオーバの実行

それではやっとフェイルオーバを実行してみましょう。

ターミナルをいくつか用意し、クラスタのトポロジの監視、Aレコードの監視、リカバリログの監視を行います。

トポロジの監視

A レコードの監視

ログの監視

test1(現マスタ)をsytemctlで停止します。

最初はOrchestratorのトポロジ上で、test1が停止されたことが検知されます。
マスタの停止によってスレーブではレプリケーションが止まりました。

recovery.logには、フェイルオーバが行われたという出力が確認できます。

フェイルオーバまでは30秒程度要しましたが、最終的には失敗したtest1が切り離され、test2をマスタとしたレプリケーションになりました。

正常にAレコードも切り替わったようです。

まとめ

現状Orchestratorの情報自体が少ないこともあり設定に手間取る点もありますが、期待通りの動作を行えることが確認できました。

consulやetcdなどのサービスディスカバリソリューション、DNS切り替え、VIP切り替え等、柔軟にユーザー側でカスタマイズしてフェイルオーバ処理前後に加えられる点も魅力です。
MHAで使用していたスクリプトなど過去の資産も大部分はそのまま利用可能でしょう。

レガシーなHAソリューションから脱却したいとお考えの方は、Orchestratorはいかがでしょうか。


MySQL

 

Return Top