Galera Arbitratorを用いたデュアルマスタ構成

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

はじめに

一般に知られている通り、MySQLにおける通常のレプリケーション機能はマスタが1台の「シングルマスタ」構成を前提としています(マルチソースレプリケーションを除く)。

そのため、マスタを2台用意して双方向にレプリケーションを行う「デュアルマスタ」構成は、更新イベントの競合などが多発し正常に動作しない可能性が高いです。そこで実際にはアクティブ-スタンバイ型の構成にするパターンが多いのですが、その場合アクティブからスタンバイの切り替えに時間がかかるなどの問題を抱えてしまうケースもあります。

私は上記のような場合は、Percona XtraDB Cluster(以下、PXC)の導入を推奨しています。しかし、中には諸々の事情からサーバが2台しか用意できない方もいらっしゃいます(PXCの最小構成は3台~)。
そこで本記事でご紹介するのは、PXC+Galera Arbitrator を用いた「デュアルマスタ」構成です。

※ Galera Arbitratorについてはこちらの記事を参照してください

目次

構成について

Galera Arbitratorの利点は、データを保持しないことです。そのため、PXCノードとの通信が適切にできれば、必ずしもサーバのスペックをDB側に合わせる必要はありません(性能については後述)。そこで、この構成ではGalera Arbitrator をWEBサーバに同居させることで、PXCのノード数を削減しています。

本記事では以下のような検証サーバを使用します。プロキシソフトウェアにはHAProxyを使用しています。

[code lang=text]
DBサーバ1: 192.168.100.10 / 192.168.200.10 – Percona XtraDB Cluster
DBサーバ2: 192.168.100.20 / 192.168.200.20 – Percona XtraDB Cluster
WEBサーバ: 192.168.100.30 / 192.168.200.30 – ProxySQL, Percona-client, Galera Arbitrator
[/code]

※ 全サーバ CentOS 7.3 を利用しています
※ NWはアプリ通信用とGaleraレプリケーション用の2つに分けています。

構築手順

構築手順に関しては、公式マニュアルの手順を参考に進めていきましょう。

1. PXCインストール、初期設定

まずはPXCのNode1を構築します。PXCをインストールして、初期パスワードの変更を行います。

2. Galeraの設定

設定するパラメータは、環境に合わせて随時変更してください(buffer_pool_sizeやIPアドレスなど)。

3. Node1の起動

Node1を起動して、SST用のユーザを作成します。

5. Galera Arbitratorの構築・起動

Galera Arbitratorのインストールも公式マニュアルでも説明されています。

※ 上記のコメントの通り、Arbitratorのログはデフォルトでsyslogに出力されます
  ただし、CentOS7の場合は journalctlを使うことが推奨されるようです。

6. HAProxyの構築・起動

HAProxyは有名なプロキシソフトウェアの一つですが、PXCとの相性も良くマニュアルにも設定手順が記載されています。

なおPXCはステータス情報などがMySQLと異なるため、ノードの死活監視には基本的にPXCに付属しているclustercheckスクリプトを使います。設定方法は以下の通りです。

※ ユーザ名、パスワードを変更した場合は /usr/bin/clustercheck に記載されている認証情報も変更してください

利用方法

ここまでの手順で環境はできました。それでは実際にクエリを実行してみましょう。
HAProxyローカル上の3306ポートは Node1 にのみクエリをルーティングします。Node1がダウンした場合は、Node2に切り替えます。更新クエリの実行先として使用しましょう。

対して3307ポートはアクセス数に応じてNode1とNode2両方にクエリを実行します。こちらは参照クエリの向き先として使用しましょう。

障害試験

mysqlslapコマンドを使って簡単な障害試験を実施します。以下のコマンド実行中に Node1 をkillコマンドで強制終了させた時の挙動を確認します。

【実行結果】

SQL実行中にNode1がダウンするため、mysqlslapにはエラーが返されます。ただし、その後のアクセスは全てNode2に向けられるため、エラーとなった処理をリトライしてサービスは継続稼働することができます。
また、Node2およびGalera Arbitratorがダウンした場合はNode1の処理に影響はありません。

性能試験

最後に性能試験を行います。今回はAWS EC2を利用して以下のような試験環境を用意しました。

DBサーバ1: Percona XtraDB Cluster
DBサーバ2: Percona XtraDB Cluster
仲裁サーバ: Galera Arbitrator
benchサーバ: sysbench, HAProxy

測定するのは以下の3ケースです。

① 全サーバ同じインスタンスタイプ(m5.xlarge)
② 仲裁サーバのみスペックの低いインスタンスタイプ(m5.xlarge → t2.micro)
③ ①の環境 + tcコマンドで10msのNW遅延を起こす(平常時は0.1ms程度)

※ m5.xlarge = CPU: 4core / RAM: 16GB
※ t2.micro = CPU: 1core / RAM: 1GB
※ I/O性能の安定性のため、ディスクは汎用SSD(1TB)にしています
※ ベンチマーク用とレプリケーション用でNICは分けています

試験手順

  1. 上記の手順の通り、PXC2ノード, Galera Arbitrator, HAProxyをセットアップ
  2. sysbenchをインストール(Perconaリポジトリに含まれています)
  3. テストデータをロード
  4. sysbenchのベンチマーク実行
  5. sysbench の cleanup 実行
  6. mysqldの停止、メモリのクリア
  7. 手順3.に戻る

※sysbenchについては以前のブログ記事も参照してください

試験結果

sysbenchの結果は以下のようになりました。Arbitratorサーバのスペックを落としても、sysbenchのパフォーマンスに大きな影響はないことが分かります。一方で、ArbitratorサーバのNWが遅延している場合はスコアが半分近くまで落ちています。すなわち、Arbitratorのみを遠隔地に配置するなどした場合は注意が必要となります。

    TPS QPS Latency (avg)
①同一スペック(1回目) 1565.02 31300.60 10.22 ms
①同一スペック(2回目) 1416.18 28323.77 10.22 ms
②仲裁サーバースペック低(1回目) 1596.48 31929.78 10.02ms
②仲裁サーバースペック低(2回目) 1403.25 28065.18 11.40ms
③10ms NW遅延(1回目) 792.51 15850.26 20.19ms
③10ms NW遅延(2回目) 849.52 16990.50 18.83ms

まとめ

PXC2ノード + Galera Arbitrator という構成は、公式で推奨されているものではなく少々トリッキーな構成です。しかし、通常のMySQLでは困難な「デュアルマスタ」という構成が実現できるため、必要に応じて検討してみてはいかがでしょうか?

Let’s Enjoy Galera Life !!


Percona

 

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

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

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