Db2 HADR「SQL1770N テイクオーバーできない」を理由コードで切り分ける

HADRのテイクオーバーを実行したら失敗する、あるいは応答が返ってこない。そのとき返るのがこれです。

SQL1770N  Takeover HADR cannot complete. Reason code = "1".

テイクオーバーの失敗は理由コードとHADRの状態を見れば機械的に切り分けられます。失敗する理由はほぼ「peer状態でない」か「撃つノードが違う」かのどちらかです。この記事では判断の順序を逆引きでまとめます。

まず見る（結論）

テイクオーバーには2種類あります。計画切替（TAKEOVER HADR ON DATABASE <db>）はスタンバイ側で実行し、peer状態が前提です。緊急切替（... BY FORCE）はpeerでなくても昇格できますが、データロストのリスクがあります。

撃つ前に、状態とログギャップを確認します。

SELECT HADR_STATE, HADR_CONNECT_STATUS, HADR_LOG_GAP,
       LOG_HADR_WAIT_TIME, HADR_SYNCMODE
  FROM TABLE(MON_GET_HADR(NULL)) AS T;

db2pd -db SAMPLE -hadr

HADR_STATE = PEER かつ HADR_CONNECT_STATUS = CONNECTED なら計画切替が可能な状態です。REMOTE_CATCHUP などのときに計画切替を撃つと理由コード1で弾かれます。

症状 → 原因 → 対処（逆引き）

BY FORCE の後は、旧プライマリを新プライマリのスタンバイとして再統合します。ログが分岐していると START HADR ... AS STANDBY が拒否されるので、BY FORCE は「後で作り直す覚悟」とセットで考えます。

それでも切り分からないとき（実機ログつきの詳解）

2ノードHADR環境での失敗再現、BY FORCE 昇格後の状態、旧プライマリの再統合手順、計画切替の正常系まで含めた詳しい解説は、Zennのフル記事にまとめています。

関連: SQL30108N はエラーではない（ACRの扱い） ／ Db2 強制TKO後のスプリットブレイン時の動作 ／ db2cm を使用した Pacemaker の構成

HADRは設定より「切り替え後に何が起きるか」が本番の勝負どころです。テイクオーバー後の再接続対応まで、本書 第5章「HADRの構築と切り替え運用」で扱っています。