HADRのテイクオーバー試験をしたら、切り替え直後にアプリが軒並み落ちた。ログを見るとこれが出ている、という場面があります。
SQL30108N A connection failed but has been re-established.
The hostname or IP address is "db2node2" and the service name or
port number is "50000". ... SQLSTATE=08506これはエラーではなく「再接続できました」という通知です。SQL30108N をエラーとして扱ったアプリが自分から処理を中断し、続行できたはずの業務を止めている、というのが実際のところです。この記事では扱い方を逆引きで整理します。
まず見る（結論）
押さえるのは2点です。
SQL30108NはACRが再接続を成功させた通知。失敗したときには返らない。本当に繋がらないときはSQL30081Nなど通信系のエラーが返る。- ただし切断時に走っていたトランザクションはロールバック済み。再接続できたから続行、ではなく、そのトランザクションは再実行が必要。
代替サーバーの登録状況はサーバー側で確認します。
db2 "UPDATE ALTERNATE SERVER FOR DATABASE SAMPLE
USING HOSTNAME db2node2 PORT 50000"
db2 "LIST DATABASE DIRECTORY" -- 対象DBの Alternate server 欄を確認症状 → 原因 → 対処（逆引き）
| 症状 | 原因 | まず打つ手 |
|---|---|---|
| テイクオーバー後にアプリが大量にエラー終了する | SQLSTATEが 00000 以外なら一律エラー、という実装 |
08506 は再接続成功として扱い、そのUOWを再実行する |
| 再接続はできたのにデータが入っていない | 切断時のトランザクションがロールバックされている | アプリ側で再実行する。ACRは接続の張り直しまでしかやらない |
SQL30108N ではなく SQL30081N が返る |
代替サーバーにも繋がっていない（本当の通信障害） | 代替サーバーの登録内容とネットワークを確認 |
| ACRを設定したのに切り替わらない | 代替サーバーが未登録、または片系にしか登録していない | 両系に UPDATE ALTERNATE SERVER を設定する |
| DB側は正常に切り替わっているのに業務が止まる | アプリが SQL30108N を握りつぶしている |
接続ラッパーの例外処理を見直す |
ACRがやるのは接続の張り直しまでで、走っていたトランザクションのやり直しはしません。切断された瞬間の作業は失われる前提で、再実行の責任はアプリ側に残ります。ここを期待しすぎると「切り替えたのにデータが欠けた」という話になります。
「フェイルオーバーが危ない」のではなく、「フェイルオーバー後の1件をアプリが再実行しない」だけ、というケースが多くあります。HADRを導入するときは、この扱いをアプリ開発チームと事前に合意しておきます。
それでも切り分からないとき（実機ログつきの詳解）
2ノードHADR環境での再現ログ、ACRが成功した場合と失敗した場合の挙動の違い、JDBCでの実装イメージ、アプリ開発チームと事前に握るべき項目まで含めた詳しい解説は、Zennのフル記事にまとめています。
関連: SQL1770N テイクオーバーできないときの切り分け ／ SQL30081N 通信エラーの切り分け ／ Db2 強制TKO後のスプリットブレイン時の動作
HADRは設定より「切り替え後に何が起きるか」が本番の勝負どころです。テイクオーバー後の再接続対応まで、本書 第5章「HADRの構築と切り替え運用」で扱っています。
現場で引ける Db2 の教科書
現場で引ける！Db2実践エンジニア・バイブル
Db2はRDBMS市場でシェア数%。情報が少なく、頼れるのは膨大な公式マニュアルだけ―― そんな現状を変えたくて、「なぜこの値にするのか」「この障害のとき次に何を見るのか」という、マニュアルに載っていない現場の文脈を1冊にまとめました。書いてあることはすべて実際の現場で経験したことです。
アーキテクチャ／構成パラメーター選定／セキュリティ／バックアップ・リカバリ／HADR／pureScale／日常点検の自動化／メモリ・ロック競合／SQLチューニング／RUNSTATS・REORG／MON_GET監視／現場の難題集 ―― 全12章＋運用シェルスクリプト集。
