maxscaleの代わりを探す

こんにちは角田(tsunoda)です。

maxscaleはライセンスが改定してオープンミドルウェアではない新しいモデルになったものもあるので、
別のアプリケーションを探してみました。

今回試したもの

gcpにインスタンスを作成し検証しました。

n1-standard-1
asia-northeast1

以下のミドルウェアをインストールしてmysqlを対象にさわってみました。

haproxy
galera load balancer
mixer
proxysql

使ってみてわかった事ですが、mixerはreplicationでは使えますがclusterでは使えませんでした。
slaveが1サーバしか登録できず。。。
なのでmixerは今回検証から外してます。

評価項目

・sysbenchによる性能(Read/Writeは綺麗に分散するか)
・メンテナンスモードの有無(切り離しができるか)
・その他、ドキュメントなどから運用のしやすさなどの評価

sysbench

table作成

database: sbtestにtableを以下のコマンドで作成
user,passwordはミドルウェアに合わせて都度変更
table-sizeは100万を指定

例) maxscaleの場合
sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql --table-size=1000000 --mysql-host=127.0.0.1 \
--mysql-user=maxscale --mysql-password=maxscale  --db-ps-mode=disable prepare
テスト実施

以下のコマンドでsysbenchテストを実施
thread数は4を指定
timeは60秒に指定

sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql --table-size=100000 --mysql-host=127.0.0.1 \
--mysql-user=maxscale --mysql-password=maxscale --time=60 --db-ps-mode=disable --threads=4 run

結果

middleware transaction完了時間(s) 平均1リクエスト処理時間(ms) transaction処理/秒
maxscale 60.0100 20.03 199.63/s
haproxy 60.0185 17.80 224.49/s
galeraLB 60.0098 18.07 221.29/s
proxysql 60.0179 18.26 218.93s

transaction完了時間はそれほど変わりはない感じでした。
maxscaleは平均1リクエスト処理時間が他よりもかかっていますが、transaction処理は早かったです。
haproxyはその逆だったり。
環境によってどのproxyツールを使うかの検討材料にはなったかなと思います。

メンテナンスモードの有無

middleware maintenance
maxscale
haproxy
galeraLB 有(△)
proxysql
maxscale メンテナンスモード
$ maxadmin -S /var/lib/maxscale/maxadmin.sock
> set server prd-dbXX maintenance
haproxy メンテナンスモード
$ echo "disable server backend_servers/prd-dbXX" | socat stdio /usr/local/var/haproxy/haproxy-cli.sock
galeraLB メンテナンスモード

galeraLBはメンテナンスモードというよりnodeの切り離しと追加。

 ※[ ]は適宜指定
$ /etc/init.d/glb remove [IP or hostname]:[port]:[weight]
$ /etc/init.d/glb add [IP or hostname]:[port]:[weight]
proxysql メンテナンスモード

SQLiteのtableでstatusを変更する

$ mysql -u admin -padmin -h 127.0.0.1 -P6032
> show tables;
> select * from mysql_servers;
> update mysql_servers set status='OFFLINE_SOFT' where hostname='10.146.0.8';
> load mysql servers to runtime;
> select * from runtime_mysql_servers;

runtimeのtableに反映しないと実際に使用している設定に反映されません。

機能

haproxy

・負荷分散の重み付けを指定できる。
・haproxyはデフォルトではバックエンドサーバが停止した状態でも、そのサーバに接続が振り分けれらるようになっている。
・停止しているサーバへの接続振り分け自体を止めたい場合は、サーバの死活監視を行う設定を追加すれば良い。(check)
・mysql用の死活監視オプション(option mysql-check)もあり。
ユーザ指定でアクセス可能か否かで判定。
・利用できるサーバがない場合、待機系サーバへの振り分けも可能。
・haproxy経由でmysqlに接続したままmasterを落とす。
show variables like 'hostname';
一度エラーを返すが、その後はすぐに切り替わったmasterサーバに接続する。

galeraLB

・起動に時間がかかる。
・galeraLB経由でmysqlに接続したままmasterを落とす。
これも一度エラーを返すが、その後はすぐにmasterに切り替わったサーバに接続する。
・重み付け可能。

mixer

mixerはreplicationでは使えるが、clusterでは使えない。
slaveが1サーバーしか登録できない。

proxysql

・read-write分散可能
・クエリやIP、ポートによってアクセスするbackendDBの振り分け
・backendDBの監視
・proxyの操作はadminユーザを作成してそこから操作する
・failover 自動切り替え
・DBサーバのスケールイン/アウト
/etc/proxysql.cnfよりも、/var/lib/proxysql/proxysql.dbの方が優先される。
DBのmysql tableに設定を追加したら、runtime tableへloadして反映させる。
proxysql.dbに反映するにはsaveする。

> LOAD MYSQL VARIABLES TO RUNTIME;
> SAVE MYSQL VARIABLES TO DISK;

まとめ

使ってみた感じで言うとhaproxyが使いやすかったです。(以前から使っているからだと思いますw)
galeraLBは機能にも書きましたが起動に時間がかかりました。
また設定ファイルなども初めて使う方にはとっつきにくい印象でした。
proxysqlはfailover自動切り替えもでき、機能としては1番maxscaleの代わりになりそうです。

mxscaleの代わりとして使うならhaproxyかproxysqlが良いかなと思いました。
proxysqlはgalera_check.plというツールを利用してfailoverを自動化する必要がありましたが、
2.0からは自動切り替え機能も追加されたようなので、今回の検証ではproxysqlが良さそうです。 他のミドルウェアなどもさわってみようー!