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自動切り替えもでき、機能としては１番maxscaleの代わりになりそうです。

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

---

株式会社grasys(グラシス)は、技術が好きで一緒に夢中になれる仲間を募集しています。

grasysは、大規模・高負荷・高集積・高密度なシステムを多く扱っているITインフラの会社です。Google Cloud (GCP)、Amazon Web Services (AWS)、Microsoft Azureの最先端技術を活用してクラウドインフラやデータ分析基盤など、ITシステムの重要な基盤を設計・構築し、改善を続けながら運用しています。

お客様の課題解決をしながら技術を広げたい方、攻めのインフラ技術を習得したい方、とことん技術を追求したい方にとって素晴らしい環境が、grasysにはあります。
お気軽にご連絡ください。