MariaDB/GaleraClusterの活用

MariaDB/GaleraClusterの活用


こんにちは、MIIDAS COMPANYの大谷です。

今回は、MIIDASで採用しているMariaDB/GaleraClusterについてご紹介します。

MariaDBについて

・MySQLをforkして開発されている、MySQLと互換性のあるRDB。
・アプリケーションからはMySQLのドライバーを利用して接続/操作できる。
・バージョン5.1から5.5までは、同じバージョン番号のMySQLの非商用版を一部改良した形でリリースしていた。
・10.0系からは、MySQL5.6から新機能の選択的な追加とMariaDB独自の機能追加を実施する方針に変更された。
・いくつかのLinuxディストリビューションで、DBがMySQLからMariaDBへ切り替えられた(Fedora, RHELなど)

MySQLとの相違点

・InnoDBの代わりにPerconaのXtraDBを採用している。
・スレッドプールが利用可能(MySQLは有償版のみ)
・並列レプリケーション。
・マルチソースレプリケーション。
・独自のストレージエンジン。
 -Cassandra(Cassandraクラスタへのアクセスを可能にする)
 -CONNECT(CSV,XML,ODBCなどに接続可能)
 -FederatedX(リモートテーブルと接続。開発終了したFederatedの代替)
 -Spider(分散処理を行う)
 -TokuDB(ビックデータの活用を実現)
  etc
・SHOW EXPLAINコマンドが利用可能。
・スロークエリログEXPLAIN出力が利用可能。
・シングルテーブルに対してDELETEを行う際、リザルトセットを返すことが可能。
 SQL:DELETE … RETURNING

GaleraClusterについて

・複数台のMariaDBで構成されたクラスタ(本番運用は3台以上必須)
・全ノードで書き込み/読み込みが可能で、全ノード間で同期的にレプリケーションを行う。
・全ノードがアクティブであるため、障害時にフェールオーバーが発生しない。
・データの同期にwsrep API(Write Set Replication API)を使用している。
 (Master-Slaveレプリケーションとは仕組みが異なる)
・スプリットブレインが発生しない仕組み。
 (ノード数でトランザクションのコミットを制御/Quorum方式)
・LOCK TABLES, FLUSH TABLESなどの明示的なロックが使えない。
 (グローバルロックを除く)
・SQLのReadは負荷分散できるが、Writeは全ノードに同期するまで待つのでパフォーマンスが落ちる。

GaleraClusterを運用してみて

・1台停止しても問題ないので、障害対応やメンテナンスがとても楽に行える。
・SPOFが無いことによって安心してサービス運用できる。
・Master-Slaveレプリケーションのように遅延を意識しなくて良いので安心できる。
・Auto Incrementが3ずつ増加するのにはまだ違和感がある。

トラブル事例

・リリース当初は更新系クエリを分散→Deadlock多発。以下の対応することで解決。
 -トランザクション分離レベルの変更(Read Repat→Read Commited)
 -更新系クエリを1ノードに寄せる。
・更新処理でパフォーマンスが非常に悪い。
 -クラウドサービスのディスクでパフォーマンス劣化が発生。SSDを利用できるクラウドに移行することで解決。
・mroongaをマスタの全文検索に利用するが、データを更新しても同期されない。
 -GaleraClusterはInnoDBのみに対応しているため、mroongaは各ノードに更新処理を行うことで対応。
・全台停止した後にノードをアタッチできなくなる。
 -最後に停止したものから順に立ち上げてクラスターを構築しないとエラーが発生する。

GaleraClusterを利用することで、サービス運用やメンテナンスがとてもやりやすくなりました。いくつかトラブルはありましたが、採用してとても良かったと思っています。

MySQLとMariaDB。引き続き動向に注目してきたいと思います。