Plesk環境のMariaDB停止対策と死活監視シェルスクリプト導入記 -

Plesk導入サーバーでMariaDBが頻繁に停止する問題に対し、当初は定期的な自動再起動で対応しました。しかし、バックアップ処理等への影響を考慮し、プロセスの稼働状況を確認して停止時のみ再起動を実行する死活監視用のシェルスクリプトを導入し、運用を改善しました。

死活監視の導入により、手動介入なしで復旧する体制を構築しました。最終的には、Plesk経由で提供された最新のMariaDBへアップデートしたことでシステム全体の動作が安定し、停止問題の解消に至りました。

ここ1年くらいでしょうか。
私のサーバー含めPlesk導入サーバーのMariaDBがダウンするという問題が発生しています。
アタックともいえず、クラッキングともいえず、過剰アクセスともいえず、何とも言えませんでした。

問題の切り分けからMariaDB

なぜMariaDBがダウンするのか？

マシンは1台だけではなく、10台近くありますので、データ取りはすぐにでも可能でした。ログファイルを漁り、原因になりそうなものを見つけ出して…と思ってログを漁ってみても、ダウンに至る決定的な何か。。。を見つけることはできませんでした。しいて言えば、DBの使用メモリが増えていき、サーバーに割り当てられたメモリ量を超えるタイミングでダウンするような気がします。 DBだけが悪いわけではありません。そのタイミングでWEBのアクセスが多くなったり、大きなファイルサイズのメールが届いたりすると、ダウンにつながることがある気がします。しかし、これは今に始まったことではありません。昔から仕組み的には変わっておらず、それでも今までは重くなることはあっても、ダウンする（ハングする）ことはほとんど起きなかったのですが、、、

まずはメモリを定期的に解放することを目指して DBサーバーの自動再起動

最初に取り組んだのは、Cron機能を使ってMariaDBを定期的に再起動すること。
一定時間が経過したら一度再起動するやり方です。
60分に1回再起動するように設定しました。
これによって、仮に、再起動直後に何かしらの都合でダウンしたとしても、最大60分で再起動コマンドが発出しますので最大ダウンタイムは60分ということになります。
ただ、これだと何も起きていなかったとしても、60分に1回再起動を行うことになります。

60分以上接続が必要になる処理があった場合、それは実現不可能な処理ということになります。
なかなかそういうシステムも存在しないのですが私の場合、JRA-VANの情報の初期データの登録の際に、丸2日間（48時間）程度かかりました。
なにぶん、1986年以降のJRAで開催されたすべての競馬情報、競走馬情報、繁殖情報、騎手、調教師等の情報などがあるため、膨大なデータになります。
もちろん、分割で入れていくことも可能ですが、できればこういう初期データの登録作業は一括で一気にやりたいものです。
定期的な再起動処理であれば、そのcronを一時的に停止するか何かしないと動かないということになります。

すぐに発生した問題バックアップ時にDBのバックアップがうまくできないことでした。

この再起動cronを導入していきなり問題が起きました。それは、サーバーのデータバックアップを行うと、このcronのせいでDBのバックアップがうまくできないという問題に直面しました。先ほど述べたように、膨大なデータを持つDBが一つあり、丸ごとバックアップをとろうとすると、その1つのDBだけでも1時間以上時間がかかるようでした。したがって、必ずそのDBのバックアップ中にタイムアウトしてバックアップシステムが中断していました。そこで対応したのはそのバックアップを取得する日時（毎週日曜日2時と決めていたので）から、2～3時間は、cronが走らないようにするというアイディアです。まあ、対応としては悪くはないのですが、なんか微妙に本質からずれてきているなとも思っていました。

ダウンした時だけ再起動してくれればいい

死活監視プログラム

MySQLがダウンした時だけ再起動してくれればそれに越したことはありません。
どんな方法を使ってでもいいので動いているということが認識出来たらなにもしない。
動いていないという認識になったら再起動プログラムを発動させたい。
シンプルにそう考えました。

内部だけでの処理で可能・・・ psコマンドを使って死活監視する

Lockファイルが残ってゾンビ化しているなどといった特殊な状況ではない限り、プロセスを確認すればmariadbのプロセスが常駐で立ち上がっているはずです。
それを監視するようなシェルスクリプトを作ってcronで常時監視すればいいわけです。
シェルスクリプトを作るのであれば中身としては、プロセスチェック、該当するプロセスが存在していればそれで何もしない、該当するプロセスが見当たらないようならmariadbを再起動。
これで、問題ないはずです。
さらに言えば、再起動プロセスが発動したときだけログファイルに記述するようにしておけば、事後にいつ再起動がかかったか確認できます。

ただし、このシェルスクリプトはDBがダウンしている場合起動するスクリプトですから、何か事情があって意図的にダウンさせても、数秒後には再起動スクリプトが発動して立ち上がります。クラッシュ対策や、過負荷でログ確認をしている間ダウンさせたいというような場合にはcronを止めておく必要があります。

実際に動かしてみると…

思ったよりダウンしていた！

DBサーバーなんていうものは放っておけば永遠に動くものくらいに思っていました。しかし、最近のDBは結構落ちるんですよね。（これももしかしたら該当バージョンが問題だったのかもしれませんが、のちに顛末を記載します。）シェルスクリプトを採用して1か月程度で５回の再起動がかかりました。しかし、ほぼノーダメージで切り抜けることができました。

Pleskのmariadbにアップデートが！

アップデートしたら・・安定した？

この記事を書いている最中に、mariadbがアップデートされました。 Pleskを導入している関係からmariadbの最新版が出たからといって安易に採用できません。Pleskが正式採用して、アップデートが出てこないと勝手に更新すると動かなくなる危険があるからです。この度、晴れて正式にリリースされたのでさっそく導入してみました。

導入から１週間程度ですが現在のところ、１度も再起動に至っていません。もしかしたら、旧バージョンが相性が悪かったのか、そんな気がしてなりません。何にしても安定したこと自身は非常にいいことで、少し安心してみていられる感じになりました。まだ１週間程度ですからもう少し様子を見ていかなければいけませんが、今の状態なら大丈夫じゃないかと思っています。