DigiLoog

動的ページ生成にwordpressを多用しているが、
先日公開されたv5.3.1がデッドロックする事象が出た。

データベースでlockファイル削除も一つの手段だが、
今回はWebサーバ再起動によるセッションクリアと、
15待機でイニシャルデータのクリアを行った。

その後、わざと2回連続でアップグレードを走らせる事で、
テンポラリクリアとデータベースのアップグレードも走らせ無事完了。
どうやら、セッションが残ってしまうケースがあるらしく、
ハマった場合にはアプリ再起動と15待機でいい模様。

根本的な所は今後の自鯖引っ越しイベントで改修するとして、
自身のいTIPSとしてメモしておこう。

自鯖の内部用Webサーバを、Apache・Nginxの2本にすべく調整をしているのだが、
CGIを動かす為に使っているspawn-fcgiが起動しなくて四苦八苦中。

コレの調整が終われば内部のWebサーバ移行を一気に進められるのだが、
平日に時間を取れない土日の自鯖管理者なので調査時間も取れないのが悩ましい。
監視系・メールスパム集計ページとかもWebシステムとして内制しているので、
コレがないと始まらないのが辛い所。
もう暫くは試行錯誤しないとダメなので、引き続き構築テストを進めようと思う。

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

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

………

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

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