Db2 HADRの基礎と構成手順を整理する

### 試したこと

* HADRとは何か、図や表に整理して理解する(ことを試みる)
* 2台構成HADR環境をIaaS環境に構築
* 導入時の実行コマンド、標準出力ログを備忘録として記録

### HADRとは

 * Db2高可用性構成の主要パターンの1つ __【アクティブ・ホットスタンバイ構成】__
     * ホット・スタンバイ(＝スタンバイはDb2起動済の状態で待機している)のため、プライマリーDB障害時には速やかにスタンバイDBへ切り替えることができる

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/4b94c815-24f9-240f-0f46-971cfc0aa1f3.png)

 * プライマリーDBに更新処理を行うと、書き出されたトランザクションログがスタンバイDBにバックエンドで転送・自動適用され、ほぼリアルタイムにデータの同期が取られている仕組み
 * 距離の制約がないため、同一サイト内での冗長構成だけでなく、リモートサイトとの間で災対構成を組む用途でも利用可能<br>

 * プライマリーDBとスタンバイDBの間ではハートビート通信が行われ、お互いの役割を認識している
     * ただし自動的に役割を変更する機能はなく、スタンバイDBをプライマリーDBに昇格させるにはTAKEOVER HADRコマンドを実行する必要がある
     * 障害検知～TAKEOVERを自動化するには、Pacemaker, TSA, PowerHA, LifeKeeper, CLUSTERPROなどのクラスターソフトウェアをあわせて使用する


セカンダリーデータベースを読取用途で利用する(読取専用スタンバイ)、スタンバイデータベースを複数サイトに構築する(マルチスタンバイ)など、応用構成パターンもありますが、ここではもっともベーシックな2台構成のHADR環境を構築します。

### HADR 同期モード

HADRで重要な設計要素として、どの同期モードが最適か、考える必要があります。

HADRはログ転送によってクライアント・アプリケーションからの更新処理をプライマリーDB→スタンバイDBへと伝搬する仕組みですが、もし仮に、2つのデータベースを両方とも更新完了するまで待機しなくてはならない仕組みであるなら、単純計算で1つのDBの更新を行う時間の2倍、かかってしまいそうです。

さらに、プライマリーとスタンバイの両方の更新完了を以ってトランザクション完了と見なす場合、どちらかのデータベースが何らかの理由でアクセスできない状況の場合に応答が戻らなくなってしまい、可用性を高める仕組みのはずが、却って可用性が下がる可能性があります。

いくら冗長性を上げたくても、そこまでの負荷と待機時間発生リスクを許容することはなかなかできません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/d7919b37-7b39-449f-81d1-73fa07bc7662.png)

そこで、HADRの同期モードは以下の4種類が提供され、トランザクションを保護する度合いとパフォーマンス要件の兼ね合いから、どの同期モードが望ましいか、アプリケーションの要件から判断し選択することができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/ad06e49a-4006-25ae-bc0f-28e915e0d71e.png)


|| 同期モード | 備考 | 
|:-:|:-|:-
| 1  |SYNC(同期)   |・プライマリDBのログファイルに加え、ログがスタンバイDBのログファイルにも書き込まれたことの確認通知をプライマリーDBが受信したらログ書き込み成功(コミット済)とみなされる<br>・トランザクション応答時間は最長   |
| 2  |NEARSYNC<br>(近似同期/準同期)<br> *デフォルト  | ・プライマリDBのログファイルに加え、スタンバイDB上のメイン・メモリーにもログが書き込まれたことの確認通知をプライマリDBが受信したら、ログ書き込み成功(コミット済)  |
| 3  |ASYNC(非同期)   |・プライマリDBのログファイルに加え、プライマリDBのTCPレイヤーに送信されたら、ログ書き込み成功(コミット済)<br>・スタンバイDBの確認通知を待たない   |
| 4  |SUPER ASYNC<br>(超非同期)   |・プライマリDBのログファイルにログ・レコードが書き込まれた時点で、ログ書き込み成功(コミット済) <br>・HADR ペアがピア状態および切断ピア状態になることがないモード  |


今回は、多くの環境に適するデフォルトのNEARSYNCモードを選択します。

### 環境

* Db2が既にインストールされた環境に、追加でHADRのデータベースを1セット構成する
    * IBM Cloud (IaaS)
    * Red Hat Enterprise Linux release 8.8 (Ootpa)
    * Db2 11.5.9
* HADR2台構成

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/38b907ec-1787-832b-6276-fb9b338f3e09.png)


  

### 作業の流れ

以下の手順を実行します。

| Step | 手順                                                       | 対象サーバ   |実行ユーザ  |
| ---- | :---------------------------------------------------------- | :------------ |:-------|
| 1    | OSの構成                                                   | 1号機、2号機  |  root |
| 2    | Db2インスタンス作成                                        | 1号機、2号機 | (db2 <br>instance user)|
| 3    | Db2インスタンス起動                                        | 1号機、2号機 |同上|
| 4    | Db2データベース作成                                        | 1号機        |同上|
| 5    | アーカイブ・ロギングの構成                                 | 1号機        |同上|
| 6    | 索引ロギング/索引再作成　を有効化                          | 1号機        |同上|
| 7    | DBバックアップ取得                                         | 1号機        |同上|
| 8    | DBバックアップ転送                                         | 1号機→2号機  | N/A |
| 9    | プライマリーDBのバックアップからのリストア                   | 2号機        | (db2 <br>instance user)|
| 10   | HADR通信用のOS設定                                         | 1号機、2号機 |root|
| 11   | HADRのためのDB構成パラメーターの設定                       | 1号機、2号機 | (db2 <br>instance user)|
| 12   | HADRサービスの開始                                         | 2号機        |同上|
| 13   | HADRサービスの開始                                         | 1号機        |同上|

※ この手順メモ内では、Db2 instance user名は uk1159 となります

### セットアップ作業ログ

#### Step1. OSの構成(ユーザー, グループ, ディレクトリ作成) (1号機, 2号機)

##### Step1-1. OSグループ作成

HADR用のDb2インスタンスユーザーが属するOSグループを作成します。

```
groupadd -g 2031 ukigrp1
```

　※必要に応じて、Fencedユーザー用グループを作成(今回は作成済の環境のため省略)

##### Step1-2. OSユーザー作成

Db2インスタンスユーザーとなるOSユーザーを作成します。

```
useradd -g ukigrp1 -u 2031 uk1159
```

　※HADRのインスタンスユーザーは異なっていても問題ないようですが、同名のほうがわかりやすいため1,2号機とも同じユーザーとします。
　※必要に応じて、Fencedユーザーを作成(今回は作成済の環境のため省略)

##### Step1-3. OSユーザーパスワード変更

Step1-2.で作成したユーザーのパスワードを設定します。

```
passwd uk1159
```

##### Step1-4. データ/ログ配置用ディレクトリー作成

デフォルトでは/homeに配置されますが、データやログが増えて/homeが100%到達してしまうとログインできなくなるなど悲惨な状況になるため、サイズが増えそうなものは/homeとは別のファイルシステムに配置するほうが望ましい。今回は以下ディレクトリを作成し利用します

```
mkdir /data/uk1159
```

所有者をDb2インスタンスオーナーに変更

```
chown uk1159:ukigrp1 /data/uk1159
```

以下、用途別のサブディレクトリを作成しておきます

__自動ストレージパス用サブディレクトリ：__

```
mkdir /data/uk1159/stopath
```

__DBPATH用サブディレクトリ：__

```
mkdir /data/uk1159/dbpath
```

__アクティブログパス用サブディレクトリ：__

```
mkdir /data/uk1159/actlog
```

__アーカイブログ用サブディレクトリ：__

```
mkdir /data/uk1159/arclog
```

 

#### Step2. Db2インスタンス作成 (1号機, 2号機)

Db2インスタンスを作成します。

```
[root@host-1 home]# /opt/ibm/db2/V11.5.9/instance/db2icrt -u db2fenc1 uk1159
DBI1446I  db2icrt コマンドの実行中です。


DB2 インストールを初期化しています。

 実行されるタスクの合計数: 4
実行される全タスクの合計見積もり時間: 309 秒

タスク #1 を開始します。
説明: デフォルト・グローバル・プロファイル・レジストリー変数の設定
見積もり時間 1 秒
タスク #1 が終了しました。

タスク #2 を開始します。
説明: インスタンス・リストの初期化
見積もり時間 5 秒
タスク #2 が終了しました。

タスク #3 を開始します。
説明: DB2 インスタンスの構成
見積もり時間 300 秒
タスク #3 が終了しました。

タスク #4 を開始します。
説明: グローバル・プロファイル・レジストリーの更新
見積もり時間 3 秒
タスク #4 が終了しました。

正常に実行が完了しました。

詳しくは、「/tmp/db2icrt.log.2285856」にある DB2
インストール・ログを参照してください。
DBI1070I  プログラム db2icrt は正常に完了しました。


[root@host-1 home]#
```

Db2インスタンスが作成されたことを確認します。
```
[root@host-1 home]# /opt/ibm/db2/V11.5.9/instance/db2ilist
uk1159
```



#### Step3. Db2インスタンス起動 (1号機、2号機)

ここから先の作業は、Db2インスタンスオーナーのユーザーにSwitchして操作します。

```
su - uk1159
```

Db2インスタンスを起動します。

```
[uk1159@host-1 ~]$ db2start
03/06/2024 19:07:25     0   0   SQL1063N  DB2START の処理が正常に終了しました。
SQL1063N  DB2START の処理が正常に終了しました。
[uk1159@host-1 ~]$
```

#### Step4. データベース作成 (1号機)

データベースを作成します

```
[uk1159@host-1 ~]$ db2 create database HADRDB ON /data/uk1159/stopath DBPATH ON /data/uk1159/dbpath USING CODESET UTF-8 TERRITORY JP
DB20000I  CREATE DATABASE コマンドが正常に完了しました。
[uk1159@host-1 ~]$
```

データベースが作成されたことを確認します

```
[uk1159@host-1 ~]$ db2 list db directory

 システム・データベース・ディレクトリー

 ディレクトリー中の項目数 = 1

データベース 1 項目:

 データベース別名                     = HADRDB
 データベース名                             = HADRDB
 ローカル・データベース・ディレクトリー = /data/uk1159/dbpath
 データベース・リリース・レベル       = 15.00
 コメント                       =
 ディレクトリー項目タイプ             = 間接
 カタログ・データベース・パーティション番号 = 0
 代替サーバー・ホスト名               =
 代替サーバーのポート番号             =

[uk1159@host-1 ~]$

```



#### Step5. アーカイブ・ロギング構成 (1号機)

Db2では2 つのタイプ (*循環*および*アーカイブ*) のデータベース・ロギングがサポートされ、デフォルトは循環ロギングです。
HADRを構成する前提として、アーカイブロギング使用可能の構成に変更しておく必要があります。

DB構成パラメータ LOGARCHMETH1 にアーカイブログ出力先ディレクトリを定義することで、ロギング形式をアーカイブログに変更します。
また、必須ではないですが、/homeに極力ものを置かない方針としてアクティブログパスも一緒に変更します。

DB構成パラメータは、それぞれ `db2 update db cfg` コマンドで変更することができます。

```
db2 update db cfg for hadrdb using logarchmeth1 DISK:/data/uk1159/arclog
db2 update db cfg for hadrdb using newlogpath /data/uk1159/actlog
db2 terminate
db2stop
db2start
db2 backup database HADRDB to /data/uk1159/
db2 activate database HADRDB
```

ログの出力先が変更されたことを確認します。

```
[uk1159@host-1 ~]$ db2 get db cfg for HADRDB 
(中略)
 ログ・ファイルのパス      = /data/uk1159/actlog/NODE0000/LOGSTREAM0000/
(中略)
 第 1 ログ・アーカイブ・メソッド   (LOGARCHMETH1) = DISK:/data/uk1159/arclog/
(以下略)
```

#### Step6. 索引ロギング/索引再作成　を有効化する (1号機)

HADR環境では以下パラメータの値を構成します。(デフォルトが推奨値である場合、変更不要)

| DB構成パラメータ | 製品デフォルト値 | HADR構成の場合の推奨 | 備考<br>※HADRの観点のみ記載                                  |
| ---------------- | ---------------- | -------------------- | ------------------------------------------------------------ |
| LOGINDEXBUILD    | OFF              | ON                   | 索引作成、再作成、および再編成のために完全な情報をログに記録させる設定。<br>このパラメータがOFFだと、ログに記録される情報が不完全なためにスタンバイシステムで索引にデータを追加できず、索引は無効状態としてマークされ、HADRテイクオーバー完了後に索引再作成を行う必要が生じる。ONに設定されると索引の作成、再作成、および再編成の実行中に各索引ページがログに記録される。<br>DB構成パラメータでなく、テーブルのLOG INDEX BUILD属性を指定することでも変更可能。 |
| INDEXREC         | RESTART          | RESTART              | スタンバイ・データベースでのログ適用時に索引作成を再実行するかどうかを決める設定。<br>フル・ロギングで記録された索引作成は、ロールフォワードまたは HADR ログ適用の間に再実行される。 HADR が開始され、HADR のテークオーバーが行われると、テークオーバーの最後に無効な索引が再作成される。 |

変更コマンド：

```
db2 UPDATE DB CFG FOR HADRDB USING LOGINDEXBUILD ON
db2 deactivate db HADRDB
db2stop
db2start
db2 activate db HADRDB
```

参考：[Db2 11.5マニュアル[索引ロギングおよび高可用性災害時リカバリー (HADR)]](https://www.ibm.com/docs/ja/db2/11.5?topic=hadr-index-logging)



#### Step7. バックアップ取得 (1号機)

2号機にスタンバイ・データベースを作成するため、1号機に作成したHADRDBデータベースのオフライン・データベース・フルバックアップを取得します。

```
db2 backup database HADRDB to /data/uk1159/
```

実行例：

```
[uk1159@host-1 ~]$ db2 deactivate database HADRDB
DB20000I  DEACTIVATE DATABASE コマンドが正常に完了しました。
[uk1159@host-1 ~]$ db2 backup database HADRDB to /data/uk1159/

バックアップは成功しました。
このバックアップ・イメージのタイム・スタンプは
20240306203842 です。

[uk1159@host-1 ~]$

```



#### Step8. バックアップ転送 (1号機→2号機)

Step7.で取得したDBバックアップのイメージ(zip)ファイルを2号機に転送します。
sftpコマンド,WinSCPなどツールは何でも良いですがバイナリモードでの転送が必須です。

転送完了後、2号機でバックアップ・イメージ・ファイルが壊れていないか確認します。

```
[uk1159@host-2 uk1159]$ db2ckbkp ./HADRDB.0.uk1159.DBPART000.20240306203842.001

[1] Buffers processed:  ############

Image Verification Complete - successful.

[uk1159@host-2 uk1159]$ echo $?
0
[uk1159@host-2 uk1159]$

```
問題なく転送できました(successful)


#### Step9. プライマリーDBのフル・バックアップ・イメージからのリストア (2号機)

HADRのスタンバイ・データベースを作成する方法はいくつかあるようですが、ここでは1号機で作成したプライマリー・データベースのバックアップ・イメージをリストアすることで、スタンバイ・データベースを作成します。

スタンバイ・データベースは、ロールフォワード・ペンディング状態とする必要があります。そのためロールフォワード不要 (without rolling forward) オプションを付与するのはNGです。

```
[uk1159@host-2 uk1159]$ db2 restore database HADRDB from /data/uk1159 taken at 20240306203842
DB20000I  RESTORE DATABASE コマンドが正常に完了しました。
[uk1159@host-2 uk1159]$
```



#### Step10. HADR通信用のOS設定

HADR 1号機と2号機のDb2インスタンス間で通信を行うためには、相手サーバーの通信先のホスト名(IPアドレス)とサービス名(ポート番号) を相互に登録しておく必要があります。
Step10-11にて、OSとDb2双方に必要な構成情報を設定していきます。

:::note
IPアドレスとポート番号でDb2を構成することもできます。
その場合、Step10はスキップしてStep11に進みます。
:::

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/9981fc57-7f35-05e6-1c0c-04f19377e870.png)

まずはOS側の構成を行います。


##### Step10-1. 通信に利用するホスト名(IPアドレス)の設定

1号機、2号機　共通の内容でOKです。

```text: /etc/hosts 
10.0.0.1	host-1
10.0.0.2	host-2
```

__補足__: DNSサーバが構成される環境ではhostsファイルへの登録は不要です。


##### Step10-2. 通信に利用するサービス名(ポート番号)の設定

Db2のインスタンスを作成すると、FCM通信用とクライアントからの接続を受け付けるための通信用ポートが /etc/servicesファイルに自動的に登録されます。
しかしHADRノード間通信用ポートはデフォルトでは登録されないため、手動で /etc/services ファイルを編集し、エントリーを追加します。

ファイル編集前に、利用しようとしているポート番号が他サービスによって使用済でないこと(重複がないこと)を確認します。
確認方法としては、以下のような方法があります。
 * /etc/servicesファイルの確認
 * netstat -an コマンドを実行し、実際にlistenされていないか確認

追記内容は1号機、2号機　共通の内容でOKです。
```text: /etc/services への追記内容例
DB2HADR_P_uk1159   25017/tcp #PrimaryノードHADR通信用
DB2HADR_S_uk1159   25018/tcp #StandbyノードHADR通信用
```

追記後のイメージとしては以下のようになります。
###### 1号機

```text: /etc/services
DB2_uk1159      20022/tcp
DB2_uk1159_1    20023/tcp
DB2_uk1159_2    20024/tcp
DB2_uk1159_3    20025/tcp
DB2_uk1159_4    20026/tcp
DB2_uk1159_END  20027/tcp
db2c_uk1159     25011/tcp
DB2HADR_P_uk1159   25017/tcp #PrimaryノードHADR通信用
DB2HADR_S_uk1159   25018/tcp #StandbyノードHADR通信用
```
###### 2号機

```text: /etc/services
DB2_uk1159      20071/tcp
DB2_uk1159_1    20072/tcp
DB2_uk1159_2    20073/tcp
DB2_uk1159_3    20074/tcp
DB2_uk1159_4    20075/tcp
DB2_uk1159_END  20076/tcp
db2c_uk1159     25016/tcp
HADR_P_uk1159   25017/tcp #PrimaryノードHADR通信用
HADR_S_uk1159   25018/tcp #StandbyノードHADR通信用
```


#### Step11. HADRのためのDB構成パラメーターの設定

HADR 1号機と2号機のDb2インスタンス間で通信を行うため、Step10で設定した情報に基づいてDb2構成パラメータを設定します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/b7243668-38c4-bd7c-abae-b05f34acc9fc.png)


##### Step11-1. HADR通信用の設定

HADR 1号機と2号機のDB構成パラメータに、相手サーバとの通信に用いる情報を登録します。

* 自ノード、相手ノードのホスト名(IPアドレスでも可)
* 自ノード、相手ノードのサービス名(ポート番号でも可)
* 相手ノードのDb2インスタンス名

###### 1号機の設定

```
db2 update db cfg for HADRDB using HADR_LOCAL_HOST host-1
db2 update db cfg for HADRDB using HADR_LOCAL_SVC DB2HADR_P_uk1159
db2 update db cfg for HADRDB using HADR_REMOTE_HOST host-2
db2 update db cfg for HADRDB using HADR_REMOTE_SVC DB2HADR_S_uk1159
db2 update db cfg for HADRDB using HADR_REMOTE_INST uk1159
```

###### 2号機の設定
```
db2 update db cfg for HADRDB using HADR_LOCAL_HOST host-2
db2 update db cfg for HADRDB using HADR_LOCAL_SVC DB2HADR_S_uk1159
db2 update db cfg for HADRDB using HADR_REMOTE_HOST host-1
db2 update db cfg for HADRDB using HADR_REMOTE_SVC DB2HADR_P_uk1159
db2 update db cfg for HADRDB using HADR_REMOTE_INST uk1159
```


__補足:__

 * 通常はIPアドレスやポート番号が万一変わった場合もDb2の構成情報を変更せずに済むよう、Db2の構成パラメータにはホスト名とサービス名を登録し、OSの構成ファイル(hosts, services)を利用して名前解決を行います。
 * Db2マニュアル「[高可用性災害時リカバリー (HADR) の初期設定](https://www.ibm.com/docs/ja/db2/11.5?topic=availability-initializing-hadr)」には、「1 次データベースおよびスタンバイ・データベースで、次のように hadr_target_list 構成パラメーターを設定します。(中略) hadr_target_list パラメーターを設定しないと、1 つのスタンバイに制限されます。 HADR を構成するこの方法は、 バージョン 10.5以降非推奨になりました。」と記載されますが、マルチスタンバイ用のパラメータであって必須じゃない、という考え方もあるようで、今回のところはそういうものかと納得してこのパラメータの利用は見送りました

##### Step11-2. その他の設定

HADR同期モードは、デフォルトではNEARSYNCです。
変更する場合はDB構成パラメータ「HADR_SYNCMODE」を変更します。

その他にもHADRには障害発生時の挙動を制御するためさまざまなDB構成パラメータが存在します。

マニュアルを参照しつつ構成を行います。
[高可用性災害時リカバリー (HADR)](https://www.ibm.com/docs/ja/db2/11.5?topic=server-high-availability-disaster-recovery-hadr)



#### Step12. HADRサービスの開始 (2号機)

2号機からサービスを開始します.



```
[uk1159@host-2 ~]$ db2 start hadr on database HADRDB as standby
DB20000I  START HADR ON DATABASE コマンドが正常に完了しました。
[uk1159@host-2 ~]$

```



HADR2号機の稼働状況確認を行います。

HADR_ROLDはSTANDBY、まだプライマリ(1号機)でのサービスを開始していないことから、HADR_STATEはリモートキャッチアップペンディング, HADR_CONNECT_STATUS は切断状態となっています。

```
[uk1159@host-2 ~]$ db2pd -d HADRDB -hadr

Database Member 0 -- Database HADRDB -- Standby -- Up 0 days 00:22:00 -- Date 2024-03-08-11.51.03.472501

                            HADR_ROLE = STANDBY
                          REPLAY_TYPE = PHYSICAL
                        HADR_SYNCMODE = NEARSYNC
                           STANDBY_ID = 0
                        LOG_STREAM_ID = 0
                           HADR_STATE = REMOTE_CATCHUP_PENDING
                           HADR_FLAGS =
                  PRIMARY_MEMBER_HOST = NULL
                     PRIMARY_INSTANCE = NULL
                       PRIMARY_MEMBER = NULL
                  STANDBY_MEMBER_HOST = host-2
                     STANDBY_INSTANCE = uk1159
                       STANDBY_MEMBER = 0
                  HADR_CONNECT_STATUS = DISCONNECTED
             HADR_CONNECT_STATUS_TIME = 2024-03-08 11:29:04.527537 (1709864944)
          HEARTBEAT_INTERVAL(seconds) = 5
                     HEARTBEAT_MISSED = 0
                   HEARTBEAT_EXPECTED = 0
                HADR_TIMEOUT(seconds) = 120
        TIME_SINCE_LAST_RECV(seconds) = 0
             PEER_WAIT_LIMIT(seconds) = 0
           LOG_HADR_WAIT_CUR(seconds) = 0.000
    LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000000
   LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.000
                  LOG_HADR_WAIT_COUNT = 0
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 16384
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 87380
            PRIMARY_LOG_FILE,PAGE,POS = S0000000.LOG, 0, 0
            STANDBY_LOG_FILE,PAGE,POS = S0000001.LOG, 0, 49009825
                  HADR_LOG_GAP(bytes) = 0
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000001.LOG, 0, 49009825
       STANDBY_RECV_REPLAY_GAP(bytes) = 0
                     PRIMARY_LOG_TIME = NULL
                     STANDBY_LOG_TIME = 2024-03-06 20:19:09.000000 (1709723949)
              STANDBY_REPLAY_LOG_TIME = 2024-03-06 20:19:09.000000 (1709723949)
         STANDBY_RECV_BUF_SIZE(pages) = 16
             STANDBY_RECV_BUF_PERCENT = 0
           STANDBY_SPOOL_LIMIT(pages) = 25600
                STANDBY_SPOOL_PERCENT = 0
                   STANDBY_ERROR_TIME = NULL
                 PEER_WINDOW(seconds) = 0
             READS_ON_STANDBY_ENABLED = N
              HADR_LAST_TAKEOVER_TIME = NULL

[uk1159@host-2 ~]$

```



#### Step13. HADRサービスの開始 (1号機)

```
[uk1159@host-1 ~]$ db2 start hadr on database HADRDB as primary
DB20000I  START HADR ON DATABASE コマンドが正常に完了しました。
[uk1159@host-1 ~]$

```

HADR1号機の稼働状況確認を行います。以下の状態になっていれば問題ないと判断できます。

* HADR_ROLE：PRIMARY
* HADR_STATE：PEER
* HADR_CONNECT_STATUS：CONNECTED

```
[uk1159@host-1 ~]$ db2pd -d HADRDB -hadr

Database Member 0 -- Database HADRDB -- Active -- Up 0 days 07:07:21 -- Date 2024-03-08-19.04.05.961236

                            HADR_ROLE = PRIMARY
                          REPLAY_TYPE = PHYSICAL
                        HADR_SYNCMODE = NEARSYNC
                           STANDBY_ID = 1
                        LOG_STREAM_ID = 0
                           HADR_STATE = PEER
                           HADR_FLAGS = TCP_PROTOCOL
                  PRIMARY_MEMBER_HOST = host-1
                     PRIMARY_INSTANCE = uk1159
                       PRIMARY_MEMBER = 0
                  STANDBY_MEMBER_HOST = host-2
                     STANDBY_INSTANCE = uk1159
                       STANDBY_MEMBER = 0
                  HADR_CONNECT_STATUS = CONNECTED
             HADR_CONNECT_STATUS_TIME = 2024-03-08 11:56:47.260363 (1709866607)
          HEARTBEAT_INTERVAL(seconds) = 5
                     HEARTBEAT_MISSED = 0
                   HEARTBEAT_EXPECTED = 5129
                HADR_TIMEOUT(seconds) = 120
        TIME_SINCE_LAST_RECV(seconds) = 3
             PEER_WAIT_LIMIT(seconds) = 0
           LOG_HADR_WAIT_CUR(seconds) = 0.000
    LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000020
   LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.419
                  LOG_HADR_WAIT_COUNT = 1239
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 87040
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 369280
            PRIMARY_LOG_FILE,PAGE,POS = S0000003.LOG, 800, 60621468
            STANDBY_LOG_FILE,PAGE,POS = S0000003.LOG, 794, 60594612
                  HADR_LOG_GAP(bytes) = 0
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000003.LOG, 794, 60594612
       STANDBY_RECV_REPLAY_GAP(bytes) = 0
                     PRIMARY_LOG_TIME = 2024-03-08 19:04:02.000000 (1709892242)
                     STANDBY_LOG_TIME = 2024-03-08 19:03:00.000000 (1709892180)
              STANDBY_REPLAY_LOG_TIME = 2024-03-08 19:03:00.000000 (1709892180)
         STANDBY_RECV_BUF_SIZE(pages) = 4300
             STANDBY_RECV_BUF_PERCENT = 0
           STANDBY_SPOOL_LIMIT(pages) = 25600
                STANDBY_SPOOL_PERCENT = 0
                   STANDBY_ERROR_TIME = NULL
                 PEER_WINDOW(seconds) = 0
             READS_ON_STANDBY_ENABLED = N
              HADR_LAST_TAKEOVER_TIME = NULL

[uk1159@host-1 ~]$

```



ここでもう一度HADR2号機の稼働状況確認を行います。以下の状態になっていれば問題ないと判断できます。

* HADR_ROLE：STANDBY
* HADR_STATE：PEER
* HADR_CONNECT_STATUS：CONNECTED

```
[uk1159@host-2 ~]$ db2pd -d HADRDB -hadr

Database Member 0 -- Database HADRDB -- Standby -- Up 0 days 07:34:39 -- Date 2024-03-08-19.03.42.123171

                            HADR_ROLE = STANDBY
                          REPLAY_TYPE = PHYSICAL
                        HADR_SYNCMODE = NEARSYNC
                           STANDBY_ID = 0
                        LOG_STREAM_ID = 0
                           HADR_STATE = PEER
                           HADR_FLAGS = TCP_PROTOCOL
                  PRIMARY_MEMBER_HOST = host-1
                     PRIMARY_INSTANCE = uk1159
                       PRIMARY_MEMBER = 0
                  STANDBY_MEMBER_HOST = host-2
                     STANDBY_INSTANCE = uk1159
                       STANDBY_MEMBER = 0
                  HADR_CONNECT_STATUS = CONNECTED
             HADR_CONNECT_STATUS_TIME = 2024-03-08 11:56:47.260924 (1709866607)
          HEARTBEAT_INTERVAL(seconds) = 5
                     HEARTBEAT_MISSED = 0
                   HEARTBEAT_EXPECTED = 5122
                HADR_TIMEOUT(seconds) = 120
        TIME_SINCE_LAST_RECV(seconds) = 2
             PEER_WAIT_LIMIT(seconds) = 0
           LOG_HADR_WAIT_CUR(seconds) = 0.000
    LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000020
   LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.419
                  LOG_HADR_WAIT_COUNT = 1235
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 87040
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 367360
            PRIMARY_LOG_FILE,PAGE,POS = S0000003.LOG, 794, 60594612
            STANDBY_LOG_FILE,PAGE,POS = S0000003.LOG, 794, 60594612
                  HADR_LOG_GAP(bytes) = 0
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000003.LOG, 794, 60594612
       STANDBY_RECV_REPLAY_GAP(bytes) = 15
                     PRIMARY_LOG_TIME = 2024-03-08 19:03:00.000000 (1709892180)
                     STANDBY_LOG_TIME = 2024-03-08 19:03:00.000000 (1709892180)
              STANDBY_REPLAY_LOG_TIME = 2024-03-08 19:03:00.000000 (1709892180)
         STANDBY_RECV_BUF_SIZE(pages) = 4300
             STANDBY_RECV_BUF_PERCENT = 0
           STANDBY_SPOOL_LIMIT(pages) = 25600
                STANDBY_SPOOL_PERCENT = 0
                   STANDBY_ERROR_TIME = NULL
                 PEER_WINDOW(seconds) = 0
             READS_ON_STANDBY_ENABLED = N
              HADR_LAST_TAKEOVER_TIME = NULL

[uk1159@host-2 ~]$

```

なお、スタンバイとなっている2号機に接続することはできません。

```
[uk1159@host-2 ~]$ db2 connect to HADRDB
SQL1776N  このコマンドを HADR
データベース上で発行することはできません。
理由コード = "1"。
[uk1159@host-2 ~]$
```







### 動作確認

HADR1号機で行ったデータ更新操作の内容が、2号機に伝搬されているか確認します。

#### (1) テーブル作成、データ挿入、索引定義 (1号機)

```
[uk1159@host-1 ~]$ db2 connect to hadrdb

   データベース接続情報

 データベース・サーバー = DB2/LINUXX8664 11.5.9.0
 SQL 許可 ID            = UK1159
 ローカル・データベース別名 = HADRDB

[uk1159@host-1 ~]$ db2 "create table t1 (c1 integer, c2 char(32))"
DB20000I  SQL コマンドが正常に完了しました。
[uk1159@host-1 ~]$ db2 "insert into t1 values (1,'A'),(2,'B')"
DB20000I  SQL コマンドが正常に完了しました。
[uk1159@host-1 ~]$ db2 "select * from t1"

C1          C2
----------- --------------------------------
          1 A
          2 B

  2 レコードが選択されました。

[uk1159@host-1 ~]$ db2 "create index t1_i1 on t1 (c1)";
DB20000I  SQL コマンドが正常に完了しました。
[uk1159@host-1 ~]$

```





#### (2) HADR Takeover

2号機でTAKEOVER HADRコマンドを実行します。

```
[uk1159@host-2 ~]$ db2 takeover hadr on db HADRDB
DB20000I  TAKEOVER HADR ON DATABASE
コマンドが正常に完了しました。

```

2号機がプライマリーになります。

```
[uk1159@host-2 ~]$ db2pd -d HADRDB -hadr

Database Member 0 -- Database HADRDB -- Active -- Up 0 days 07:40:33 -- Date 2024-03-08-19.09.36.044270
                            HADR_ROLE = PRIMARY
                            ‥(略)‥
                           HADR_STATE = PEER
                            ‥(略)‥
                  HADR_CONNECT_STATUS = CONNECTED
                            ‥(略)‥
```





#### (3) 2号機上でのデータ確認

(1)で作成したテーブル、データが2号機にも存在することが確認できます。

```
[uk1159@host-2 ~]$ db2 "select * from t1"

C1          C2
----------- --------------------------------
          1 A
          2 B

  2 レコードが選択されました。

[uk1159@host-2 ~]$

```



索引も利用可能状態です。(無効化されていない)

```
[uk1159@host-2 ~]$ db2 "select substr(tabschema,1,32) as tabschema, substr(tabname,1,32) as tabname, indexes_require_rebuild from sysibmadm.admintabinfo where indexes_require_rebuild='Y'"

TABSCHEMA                        TABNAME                          INDEXES_REQUIRE_REBUILD
-------------------------------- -------------------------------- -----------------------

  0 レコードが選択されました。

[uk1159@host-2 ~]$
```



索引の状態確認方法はこちらのTechnoteで確認しました

 → [[Db2\] 無効化された索引の確認方法 (ibm.com)](https://www.ibm.com/support/pages/node/7091180)



##### (3) 2号機でデータ更新

2号機がプライマリーになっている状態で、データを追加します。

```
[uk1159@host-2 ~]$ db2 "insert into t1 values(3,'host-2 primary')"
DB20000I  SQL コマンドが正常に完了しました。
[uk1159@host-2 ~]$ db2 "select * from t1"

C1          C2
----------- --------------------------------
          1 A
          2 B
          3 host-2 primary

  3 レコードが選択されました。

[uk1159@host-2 ~]$

```



##### (4) 1号機にTakeover

1号機でTAKEOVER HADRコマンドを実行し、1号機が稼働系となるよう切戻しを行います。

```
[uk1159@host-1 ~]$ db2 takeover hadr on db HADRDB
DB20000I  TAKEOVER HADR ON DATABASE
コマンドが正常に完了しました。
[uk1159@host-1 ~]$
```



データを確認すると、2号機上で追加したデータが1号機のHADRDBデータベースに反映されていることがわかります。

```
[uk1159@host-1 ~]$ db2 "select * from t1"

C1          C2
----------- --------------------------------
          1 A
          2 B
          3 host-2 primary

  3 レコードが選択されました。

[uk1159@host-1 ~]$
```



### 参考情報
https://www.ibm.com/docs/ja/db2/11.5?topic=availability-initializing-hadr