午前中のセンター作業はあっけなく終わって。
HA構成のサーバをフェールオーバーさせて、
スタンバイ機の方でちゃんと動くかっていうだけだったんだけど。
でもって、午後はオフィスでのほほんと、
自分の作業をする予定だった。
が、オフィスに戻ってきたら、
データベースに接続できないんですけど〜、と。
またか、、、。
今のプロジェクトのトラブルシューティングは難しい。
接続URL、ユーザー、パスワードの類は全て、
乱数ファイルを元に、メモリ上で鍵を作って暗号化した文字列を
設定ファイル上に持っていて。
お客さんのインフラの人(3人だけ)しか平文の状態は知りえない。
Javaの中では平文で文字列を扱ってるわけだけど、
当然、紳士的協定で、文字列を標準出力等に出してはいけない。
今回は、別セグメントにあるデータベースに対する接続。
で、エラーメッセージが、”No Suitable Driver”。
“invalid user/password”ではない、と。
そんなこんなで、今日のトラブルシューティングは完全に失敗。
マニアックな部分から攻めすぎた。
・文字列の復号設定が間違っているのではないか、とか
・設定ファイル(JavaのProperty)は基本的に後勝ちな仕掛けで、
設定ファイルの構成もかなり複雑なので、
ひょっとして、どっかに上書いてるやつがいるんじゃないか、とか
・クラスパス上に意図せず同じパッケージで同じ名前のクラスが
いるんじゃないか、とか
・別セグメント上のサーバーのリスナーが落ちてるんじゃないか、とか
まぁ、何やるにも手間がかかるわけです。
俺みたいな外注には満足のいく権限なんてもらえない。
ただ、見るべき、もっとも大切な1つの事を見落としてた。
最初にも書いたけど、バッチ処理を担当するサーバはHA構成。
アクティブ機がいて、それと全く同じ構成のサーバがスタンバってる。
アクティブ機が落ちて、フェールオーバーすると、
バーチャルIPがスタンバイ機に付けかわって。
データベースのマウントがスタンバイ機に付けかわって。
共有ディスクのマウントもスタンバイ機に付けかわっ。
今日はわざとフェールオーバーさせて、
スタンバイ機側で、ちゃんとものが動くかどうかなんてことをしてる。
しかも、アクティブ機側では動作実績があったらしい。
基本的にデータベースの接続情報が暗号文字で書いてあるファイルは
アクティブ機側でも、スタンバイ機側でも、全く同じはずで。
データベース接続の設定ファイルに暗号化文字列を記述する作業は
俺が置いたファイルをお客さんにsedで置換してもらってるだけなので。
まさか、アクティブ機とスタンバイ機で設定が違ってるなんて思わなかった。
しかも、メッセージがinvalid user/passwordじゃなかったし。
しょうもないただの設定ミスだったのに、
2〜3時間かかってしまった。
これからは足元から1つ1つ。
いい教訓になりました。
オフィスに戻ってようやく自分の作業。
明らかに、最近、センターに行き過ぎて、
俺の作業は滞ってる。
夜遅くまで残業してると、
センターのお客さんから電話がかかってくる。
フレームワークの処理の話。
今まで、いろんな案件やってきたけど。
お客さんは”技術者”には優しい。
実装を知らずに、案件仕切ってるリーダーとか
しんどいだろうなぁと思います。
—
んで、夜はチョロっと飲みいって。
帰りは大人な事をしてみる。
自分ちの方が手前で、一緒に帰る人の家の方が遠い場合。
フツウは自分が先に降りて、バイバイするじゃないっすか。
相手の家まで行ってバイバイしてから、
折り返して自分の家に帰るっていう。
コメント