開発のことだけ考えてると、考慮し漏れるので備忘録。
何かあれば追記する予定。
疑問、質問、指摘あればコメントください。
答えられるかは分かりませんが、考えるキッカケになるので。
ログを出す
基本ですね。
障害発生時はまずはログを確認します。
ログに情報が出ていないと障害調査が進みません。
ログに出す情報も重要です。
なんでもかんでも出せばいいものではありません。
ログでサーバーの容量圧迫してあぼーんは避けましょう。
Javaだとlog4jとかね。
障害発生時のリラン方法について考慮する
例えばバッチ処理でcsvファイルをDBに登録する必要がある。
csvファイルを読み込んでDBに登録するだけなら非常に簡単。
でもその処理はいつも必ず成功するだろうか？
たとえば1,000レコードあって100レコード目のデータがおかしくて異常終了した場合どうする？
テーブルをトランケートして入れなおす？
もしも、そのテーブルには既に以前入れたデータが入っていて、そいつは消せないとしたら？
異常の原因調査して取り除いて、どこまで処理されたかを確認して・・・ってやればいい？
バタバタしている障害時にそんなことやってらんないのよ。
いかにリランを簡単にするか。
これが結構重要。障害時にはスピードが命。
障害時に更にエラーを発生させうる手順は極力避けたいところ。
上記ページには
すべてのデータを実行前の状態に戻し(ロールバック)てから再起動する方法と、障害で処理ができなかったデータのみを対象に途中から処理を再開する方法の二通りがある。
とある。その二通りについて以下に記載する。
ロールバック
一つ目のロールバックは簡単。
csvファイルのデータをすべて読み込んで、最後にコミットするようにすればいい。
それが許されるなら、それができるならそれで問題ない。
でも、それが出来ない場合もある。
そういう場合はどうするか。
それが2つ目。
ワークテーブル
そのような場合にはワークテーブル（TEMPテーブル）を用意する方法がある。
データをいきなり本テーブルに入れるのではなく、一旦ワークテーブルに入れるのである。
ワークテーブルはあくまでワークテーブルなので、処理前にはテーブルは綺麗さっぱりトランケートしている。（トランケートし放題！！！✿(ღ✪ｖ✪)｡ﾟ）
手順
- csvファイルのデータをワークテーブルに入れて、ワークテーブルから本テーブルに入れる。
- 本テーブルに入れることが出来たレコードの処理済みフラグをtrueにする。
こうすることで、レコードを二重にテーブルへ登録することを避けられ、単純リランが可能となる。