DigiLoog

老朽化した自宅サーバとサービス終了したCloudGarageからの引越し先として、
新サーバの構築を進めているのだが、内部データベースの構成をどうするかが課題だった。

当初、MariaDB Galera Clusterを利用しようと考えていたが、
安定稼働に必要なメモリ容量と、スプリットブレイン対策の奇数台数運用がネックだった。
また、DBが完全停止した時のサービス再起動にも細かい手順が必要だったり、
DBを本職としていない筆者には難易度が高すぎるのでお蔵入りになってしまった。

………

そうなると、レプリケーション構成が候補にあがるのだが、
こっちはこっちで、Master消失時にSlaveをMasterに自動昇格する方法が問題になった。
スクリプトを自作しても良かったが、日々のメンテナンスが辛くなりそうなので没に。
他に使えそうな物がないか調査した所、
MaxScaleを使うとクエリのロードバランスと自動昇格が出来る事が判明。

何処かのパブリッククラウド基盤にも採用していた筈で、稼働実績がありそうなのと、
MariaDB Galera Clusterの構成にMaxScaleも組み込まれている事が多いので、
今後の技術検証にも使えると判断し自鯖バックエンドDBに採用する事にした。

現行の自鯖機ではそれぞれのサーバ毎にDBを構築しているが、
今回の自鯖刷新を機にDBの集約化と構成変更も計る事にした。

パターンは色々あるが、今テストを行っているのは下記の通り

1. MariaDB + Replication + mysqlfailover
2. MariaDB + Replication + MaxScale
3. MariaDB Galera Cluster + Galera Arbitrator

現行維持で行くならば、レプリケーションを元にした構成になるが、
Galera Clusterを元にした構成も技術的に面白いので調査中。

ただし、クラスタ構成は3台以上の奇数構成を取らないと安定しない為、
“ns-lab BB”のサーバ構成になっているActive/Standbyとすると台数が足りなくなる。
その為、Arbitratorを何処かに構築して疑似的に奇数台数にする手があるのだが、
Arbitratorを使った構成例が極端に少なかったり、
そもそもドキュメントもお粗末な状況なので踏み切っていい物か手探り状態だったりする。

その為、MaxScaleを使った疑似リバプロ構成もテスト中。
久々に構成を大きく変更する事もあり、技術調査をしながら構築している為、
構成変更をブログに書くのは1ヶ月以上先になりそうだが何時か纏めようと思う。

今度は自宅の無線APが不調に…

1年半前に無線LAN構成を変更したのだが、最近はエラーが出てしまい繋がらない事が増えてきた。
また、IEEE802.11acに対応しておらず、比較的新しい技術の検証にも支障が出る様になってきた。
という事で、今回の自宅NW・自鯖刷新を機に無線APも刷新する事に。
こちらは以前からお金を準備していたので、今は機材を物色中。

目まぐるしく刷新を進めている “ns-lab BB” だが、
折角のタイミングなので今までの課題を一気に払拭すべく構成変更せねば。