少々可愛がり方が足りなかったのか、SecondaryNameNodeでメモリ不足が発生して、機能が停止してしまいました。

その際の調査や修復の記録になります。

SecondaryNameNodeのおさらい

SNNの機能を復習するとこんな感じ。

SNNが定期的にNameNodeからfsimageとeditsログを取得する

SNNでfsimageにeditsを適用する

NameNodeにfsimageを送り返す

NameNodeとSNNにデフォで2世代分のfsimageが残る

NameNodeのedits_inprogressがeditsにローテートされて新しいedits_inprogressが始まる

障害内容

現象

SNN起動時は正常にfsimageを送り返してるように見える

period秒後の2回目以降はNameNodeに接続しようとすらしない

SNN管理画面 http://localhost:50090/ がレスポンスを返さなくなる。タイムアウトしない

最新のfsimageがどこにもない危険な状態になる

NameNodeのedits_inprogressが肥大化する

エラーログ

NameNodeの .log にもSNNの .log にも記録されず、SNNの .out にのみ記録されていました。内容は

容量

fsimageが 約550MB
SNNプロセスの最大ヒープサイズがデフォの -Xmx1000m

修復方法

/etc/hadoop/conf/hadoop-env.sh でSNNオプションのみ環境変数を設定していなかったので、書いてSNNを再起動しました。

SNN再起動後は、全て正常に動作し、定期チェックも行われました。

反省

今回の反省点は２つ。

ヒープサイズいじってない

監視してない

ヒープサイズの方はSNNを信用していたというか、甘く見ていたというか。
fsimageの容量に対して倍近いメモリでエラーになるとすると、将来的に結構・・・どうなんでしょう。
SNNはいくらでも再起動できるから、監視さえちゃんとしていれば大事にはならないかもですが。

監視の方はひと通りやってたつもりでしたが、SNNだけ抜けてました・・・
わりと危ない状態が続いていたので、久々の冷や汗モンでしたね。
なんとCDH4.1へのアップグレード作業中に気づきました。。

大事な注意点

SNNのマージ処理が完了すると、このようなログが .log に記録されます。障害発生時はこれが記録されていませんでした。
WARN以上にしているとこれだけ延々と記録されます。

なので、SNNの監視としてはこのどちらかでよさそうです。

このログが定期的に記録されているか

HTTP管理画面の Last Checkpoint Time が period 以内になっているか（※接続タイムアウトを仕込むこと）

今後

とりあえずSNNはこれで良しとしますが、SNN自体がもうアレなので、
CheckpointNodeやBackupNodeが今どうなってるか調べたいところ。
どうやら設定項目はあるようですが、まだ何も試していません。

あとは Quorum Journal Design も仕組みは読んだけど試してないのでやらなくては。

Impalaもあるし、CDHだけでもお腹いっぱいでエンジニア冥利に尽きますね。