MariaDB Galera Cluster の Split-Brain 問題

MySQLのマスター・スレーブ構成からMariaDBのマルチマスター構成に移行してから、DB側の運用は非常に楽になった。wordpressに関して言えばWeb+DBのセットが2つあるので、その単位でラウンドロビンしている限り、まったく問題なく複数台構成を取れる(Webの接続先DBがlocalhostという状態)。しかし、DBのみを分離してreadもwriteも関係なくラウンドロビンさせると、どうしてもdead lockが頻発してしまって不都合が起きやすい。

結局マルチマスターにもかかわらず、このdead lock問題のために、writeが混ざる場合は片側のDBに寄せるしかなくなってしまう。性能面では恩恵の低いマルチマスターだが、それでも単にトラフィックを切り替えるだけでフェールオーバできるのだから運用面でのシンプルさは評価できる。期待通りという訳ではないが、以前よりは使いやすいので、このまま運用してみようと思う。Webとセットで分散させれば問題起きにくいし。

そして、もう1つの問題がSprit-Brain。GlusterFSもそうだけど、マルチマスター構成のデータモデルには常に付きまとう問題。最初に問題に気付いたのは、まさにepgrec UNAのところで、当初はreadもwriteも余裕でラウンドロビンさせていた。録画予約をした後に、予約が登録されたページと未登録のページが交互に表示される。これは間違いなくSprit-Brainじゃん!と思ってDBを覗く。一方のDBにはレコードが出来ていたが、もう一方には出来ていない。まじかよ。。。

散々、調べた挙句、とんでもない事実に気付きましたよ。epgrec UNAのtableはMyISAMで作られているんですね!Galera ClusterのマルチマスターはInnoDBのみをサポートしているので、当然同期してくれる訳がない。全てのtableをInnoDBに作り変えて確認したところ、マルチマスターとして正しく動作するようになった。しかし、今度はトランスコードのところで稀に失敗してしまう。おそらくトランスコード用のレコードが取得できていないためで、上記のdead lock問題が起きている可能性が高い。

この問題を回避するには、2つのWebと2つのDBを1対1で繋ぐような構成にするか、トランスコード処理時にリトライさせるか、DBを片側に寄せるか。epgrec UNAはWeb側でatdも使うので2台のact/act構成を取るのが難しい。仕方ないので、以下のようなリトライ処理を入れておいたが、これで特に問題はなかった。とはいえ、他のシステムでもdead lock問題が顕著になってきたので、結局DBをkeepalivedによるvip運用に変えて、片側に寄せる形に落ち着きました。

vi trans_manager.php
    :
if($tran_start['mode']=0){
  reclog( $tran_start['hd'].'開始再試行'.$tran_start['tl'].' try again.', EPGREC_WARN );
  continue;
}

そして、最後の問題はSplit-Brain対策による全滅問題。メンバーが以上終了した場合は、Quorumで正しいClusterを組もうとするので、2台構成の場合は1台のみでの運用は不可能で全滅扱いになってしまう。そうそうこんなこと起きないからいいんだけど、Mariadbをlxcコンテナ上で動かすと結構起きてしまう。というのも、lxcホストサーバを落とすと、コンテナ内のプロセスを無理やり落としているようで、もう一方のサーバが残っているのにDBは繋がらなくなってしまう。

ホストサーバを落とす前にコンテナ上のMariaDBを停止すればいいんだけど面倒だよね。ホストサーバでlxcデーモンを停止する際のスクリプトはsystemdを追えばわかる。/usr/libexec/lxc/lxc-autostart-helperというファイルがそれ。この中で『$bindir”/lxc-autostart $STOPOPTS $SHUTDOWNDELAY』というコマンドで停止していたので、lxc-autostartのオプションで何とかならないか試してみる。が、どうにもきれいに落ちてくれない。こちらも以下のような適当なscriptを作って、それを呼び出す形に書き換えて解決。

#!/bin/sh

for host in `lxc-ls --active`; do
  ssh $host shutdown -h now 2>/dev/null
  lxc-stop -n $host
  rmdir /sys/fs/cgroup/*/lxc/$host
done

exit 0

こういうSplit-Brain対策による暴走というのは、GlusterFSやElasticSearchなんかでも起きがち。どれもQuorumを達成すればClusterを維持できるんだけど、それを割り込むと生き残っているノードがいても全滅扱い。また、最低構成数が3台になってしまうのも個人用途としては冗長過ぎて使う気になれない。同じデータが3つもあるなんてねえ。だったらSplit-Brain対策なんて寧ろなくてもいいんじゃないか、という気も。ダメかな、ダメだよね。。。どなたか一刻も早く、Quorum以外のSplit-Brain対策を考えて頂けませんか!w

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)