新サーバの構築を進めているのだが、内部データベースの構成をどうするかが課題だった。安定稼働に必要なメモリ容量と、スプリットブレイン対策の奇数台数運用がネックだった。DBが完全停止した時のサービス再起動にも細かい手順が必要だったり、DBを本職としていない筆者には難易度が高すぎるのでお蔵入りになってしまった。.........そうなると、レプリケーション構成が候補にあがるのだが、こっちはこっちで、Master消失時にSlaveをMasterに自動昇格する方法が問題になった。スクリプトを自作しても良かったが、日々のメンテナンスが辛くなりそうなので没に。他に使えそうな物がないか調査した所、MaxScaleを使うとクエリのロードバランスと自動昇格が出来る事が判明。今後の技術検証にも使えると判断し自鯖バックエンドDBに採用する事にした。MaxScale概要図は次の通り。フロントエンドにMaxScaleを動かして、バックエンドのMariaDBにクエリを分散させる構成にした。典型的な構成なので枯れていると言えばそれまでだが、バックエンドのMariaDBを自動で昇格・降格出来るのと、サービスの接続先がMaxScaleに集約出来るので、MaxScaleが落ちない限りはセッションが切れず、可用性がかなり高くなった。実際にSELECTを送りながらバックエンドのMariaDBをダウンさせてみたが、クエリ停止せずに処理を継続する事が出来た。UPDATE系はフェールオーバーするまで通らない事があるが、3秒程度で収束出来るので自鯖レベルならば大満足の結果に。チューニングすれば更に可用性を上げられそうだが、MaxScale本体に負荷がかかるのでバランスを見極める必要がありそう。高可用性と負荷分散を両立する事が出来る。勉強の領域としてデータベースはやる事が多いので、今後もアップグレードしながらテストしようと思う。TumblrTweetフィルタリングを集中管理する為に便利なので、sieveプラグインを利用しているが、sieveプラグインを同梱している”dovecot-pigeonhole”のパッケージがCentOS8に無く、ネットの海を右往左往したのでその備忘録。原因は、RHEL8.0をリリースする際にdovecot-pigeonholeパッケージが削除された影響。大元となるRHEL8.0に含まれていないパッケージは含まない傾向がある。Bugzillaで『次期RHEL8には”dovecot-pigeonhole”を含める』とアナウンスがあった。Kojiにもdovecot-pigeonholeパッケージが準備されている事を確認。何かしらの理由があるのか、まだ403の状態になっていた。自力でビルドしてdovecotと連携させる回避策が出てきた。筆者はdovecot含めて全部独自ビルドする事に。日頃からソースビルドは良く実行しているので特に苦も無く起動までこぎ着ける事が出来た。ビルドオプションは次の通り。全部書くとそれなりの量になるので、サーバ刷新が一段落したタイミングで書こうと思う。installこれで、残るは起動テストのクリアとメールデータの移行&切り替えになる。残る作業が一番の山場なので、自鯖と言えども丁寧に切り替えを実施したい。今回はmaxscaleを採用する事に。決め手になったのは、レプリケーション構成を取っている時に自動昇格などが出来る点。他の使い方が出来ないかテストも継続中。今回からデュアルスタック化する予定なので、如何にコンフィグを短くするかに四苦八苦中。情報が纏まったらそのうちブログに載せたい。