FMS17にしてから、本当に安定していて再起動自体があまりない。安定していることはよいことなのだが、いざ障害が発生した特の手順やノウハウがあまりないというのも事実。昨日はまさにそんな瞬間だった。
原因は単純。連携用VMのハードディスク領域が一杯になった。ということで、復旧が大変なんですが対応は簡単。だったはず。でもそうじゃなかった。まず、受け取れていない大量のジャーナルがあるため、送り元にジャーナルの再送を依頼する必要がある。これは避けて通れないので、帰宅途中のSEにお願いした。
しかし、ハードディスク領域がそれほどまでに消失されたのは、実は数百件にもおよぶ電文が何千回もリトライしていたからである。さて、このリトライの原因がわからない。十数本あるJDBCのラインの一本が滞留し一個もデータが流れない。
よく観察すると、正常と思われる電文さえ流れずどんどん滞留してリトライしている。これはデータベース本体の損傷？を疑い、バックアップからデータベースをデプロイし直して試すもだめ。データベースサーバーの再起動（データベース再起動は、起動後２回目という珍しさ）までしたが、全く反応しない。
さらにログの解析をしつつ、データなしのデータベースをアップロードして試すも動かず。すると、一瞬xDBCインターフェースが起動するがすぐに落ちるというのが繰り返されていることも気付く。たった一つの電文がインターフェースをクラッシュさせ、それが復旧しても、最初のリトライで再びクラッシュ。延々と何千ものリトライが続く流れになっていた。その連続するクラッシュがさらなるエラーログを発生させ、半端ない性能のVMが大量のハードディスク領域を消費して、電文欠落が発生したと。
さらに、この原因電文が半年前の障害と同じ原因であることも判明。（FileMakerのxDBCにはSQL長の限界があるみたいで、それを超えるとクラッシュする）しかも、その対処用の新バージョンのミドルウェアの納品を受けているのに、それをアクティベートするプログラム側の更新を怠り、古いまま動き続けていたと。
とにかく自分の間抜けを思い知った一瞬である。なので、対応昨として失敗ブログにしてみた。
文章化することは、いろいろな意味で記憶の強化となる。たとえ失敗でも。