Db2 HADR on OpenShift かんたんデプロイ

## HADR とは
HADR(High availability disaster recovery)とは、Db2において提供される、データベース単位の高可用性を実現する機能です。
データベースが2つ稼働した状態で、プライマリの役割を担うデータベース上の更新情報（ログ情報）をスタンバイ・データベースに転送＆再生することで本番データベースのコピーを作成し、有事の際にはスタンバイ・データベースに切り替えてサービスが継続することができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/3f4c9d25-3ec4-c5cc-8f47-30bc43a4c3f4.png)
データベース・サーバの高可用性構成として従来から使われているのはアクティブ・スタンバイ方式（主DBサーバがダウンしたら、共有ディスクを引き継いで副DBサーバが起動する）で、Db2でも多く採用されます。
HADRを利用する高可用性構成では、ディスク引継ぎおよび破損回復が不要となることと、またスタンバイDBが既に活動化されている状態であるため、高速な引継ぎが可能となるメリットがあります。

参考：Db2製品マニュアル  [[高可用性災害時リカバリー (HADR)]](
https://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.5.0/com.ibm.db2.luw.admin.ha.doc/doc/c0011267.html)

## Db2 on OpenShift における HADR
Db2 on OpenShift 環境でも、HADRによる高可用性構成を利用することができます。
Db2 11.5.5 on OpenShift からの新機能として、Db2 Operatorの登場により、HADR構成も簡単に組むことができるようになりました(※同一ネームスペース内のHADR)。

 * HADR構成前に、以下のセットアップが済んでいることを前提とします
    * Db2 Operatorが導入済みであること (補足：[Db2 Operatorとは](https://qiita.com/mi-kana/items/c3fb640d671caf624eb8))
    * Db2u Cluster(Db2本体) のインスタンスを2セット導入済みであること<br>(HADRのプライマリとスタンバイ)
        * プライマリ、スタンバイは同一のリリース・レベルである必要があります
    
 * Db2u Cluster導入手順はこちらに書いていますので、ここでは割愛します
    * [Db2 11.5.5 on OpenShift デプロイ手順](https://qiita.com/mi-kana/items/6266fcdcdc3b71d8a0fb)
    * [Db2 on OpenShift 11.5.6-cn3 導入手順](https://qiita.com/mi-kana/items/b1cc3018b0df32414d64)

 * Db2 on OpenShift でHADR構成を組むには下記3つの構成パターンがあり、今回は①の構成です
    * ① 同一ネームスペース(プロジェクト)内
    * ② 同一クラスター内 / 異なるネームスペース間
    * ③ 異なるクラスター間

 * Db2 HADRには複数の同期モードが提供されますが、下記手順で構成したHADRの同期モードは、<br>デフォルトの「NEARSYNC」となります
 * Db2 11.5.6 では、HADR マルチスタンバイ構成がサポートされるようになりました
    * 複製するスタンバイを3つまで構成することが可能です
    * ただし、自動引き継ぎは1次スタンバイのみがサポートされます（この制約はオンプレ版と同じ）

参考：

 * [Db2製品マニュアル [Db2のコンテナー化デプロイメント ＞ Db2 高可用性災害時リカバリー (HADR)]](https://www.ibm.com/docs/ja/db2/11.5?topic=db2-high-availability-disaster-recovery-hadr)
 * [Db2 on OpenShift 高可用性構成のパターンとその考慮点](https://qiita.com/kgw/items/db70283f81565856af38)


## 導入環境
以下の環境に Db2 11.5.5 on OpenShift をデプロイし、HADR構成としました。

| 項目                    | バージョン         |
|:------------------------|:------------------|
| OS(bastion)             |          RHEL 7.7 |
| OS(worker)       |          RHEL 7.7 |
| OCP(Client) ※            | 4.5.0-202007240519.p0-b66f2d3 |
| OCP(Server) ※           | 4.5.7             |
| Kubernetes              |  v1.18.3+2cf11e2  |
| NFS                     |  4.2  |
| Db2 OLTP               |            11.5.5 |


###検証環境の構成
下記構成のOCP環境にDb2をデプロイします。

 - Bastion Node x1
 - Master Node x3
 - Worker Node x3

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/96371ddb-41cb-c6cc-bd13-089640055b1e.png)


### 作業を行うノード / ユーザ

コマンドはすべてBastionノードから実行しています。
また、ユーザは以下の用途で使い分けています。

| ユーザ | 用途/補足 |
|:------------|:----------------|
|rootユーザ   |NFSサーバのセットアップ用   |
|OCPユーザ   |ocコマンド実行<br>(cluster-admin権限付与)   |


コマンド実行ノード、ユーザについてはご使用の環境に応じて決めてください。
また、ocコマンド実行前には、oc login が必要となります。


## 導入の流れ
同一ネームスペース(プロジェクト)内にプライマリ/セカンダリのPodを両方稼働させるシンプルな構成であれば、以下のようなごく少ない手順でHADR構成を組むことができます。

1. Db2uHADRカスタムリソース作成
2. プライマリPod -> セカンダリPod へのバックアップイメージ/キーストア転送
3. Db2uHADRカスタムリソースのステータス確認
4. HADRの状態確認

< 補足 >
Db2は、製品提供のDb2uClusterカスタムリソースのインスタンスを新規作成することで、StatefulSetとしてデプロイされます。
その後、作成済のDb2uClusterインスタンス2つと紐づける形でDb2uHADRカスタムリソースのインスタンスを新規作成します。

HADRの初期構成においては、プライマリDBのバックアップをスタンバイにリストアすることでスタンバイDBの初期セットアップを行います。OpenShift環境でもこの点は共通で、PVCを共有するか、oc rsync コマンドを利用して、プライマリのPodからセカンダリのPodへとデータベースのバックアップ・イメージを共有する必要があります。
ここでは、後者の方法(oc rsyncコマンドにより、プライマリDBのバックアップ・イメージをセカンダリにコピー)を選択しています。

同一ネームスペース(プロジェクト)内に定義されるDB間のHADR 構成は、こちらのマニュアルに従ってセットアップします。
　→ [Db2 11.5 KnowledgeCenter[Setting up HADR in a single OpenShift project]](
https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.5.0/com.ibm.db2.luw.db2u_openshift.doc/aese-hadr-sameproj.html)

[](1. は OCP Webコンソールから GUIでポチリで完了できそうでしたが、時間切れで環境が無くなってしまったので、残念ながら試すことはできず..)

##Step1. Db2uHADRカスタムリソース作成

####1-1. Yaml作成
Db2uHADRカスタム・リソースを新規作成するためのYamlファイルを作成します。
HADRのプライマリ、スタンバイとなるシングル構成Db2(Db2uCluster) の名前は、以下のとおりです。

 * プライマリ ---> db2ucluster-1
 * スタンバイ ---> db2ucluster-2

導入済みのDb2uClusterの名前を指定し、yamlファイルを保存します。

```yaml:db2u-hadr-test.yaml
apiVersion: db2u.databases.ibm.com/v1alpha1
kind: Db2uHadr
metadata:
  name: example-hadr
spec:
  primary:
    db2uCluster: "db2ucluster-1"
  standby:
    db2uCluster: "db2ucluster-2"

```


####1-2. Db2uHADRカスタム・リソース作成
oc create コマンドでカスタム・リソースを作成します。(即時に応答が戻ります)

```
$ oc create -f /work/db2-11.5.5/db2u-hadr-test.yaml
db2uhadr.db2u.databases.ibm.com/example-hadr created
```

####1-3. ステータス確認
Db2uHadrカスタム・リソースのステータスを確認します。
example-hadrという名前でDeployされていることがわかります。
(この時点では STATE: NotReadyとなっていて、まだHADRセットアップは完了していません。)

```
$ oc get Db2uHadr
NAME           HADRPRIMARY      HADRSTANDBY     STATE      AGE
example-hadr   db2ucluster-1   db2ucluster-2   NotReady   9s
```

HADRのセットアップ状況は、以下のコマンドで確認することができます。

```
$ oc get db2uhadr <Db2uHadr-Name> -o yaml | awk '/^status:/,/hadrSettings:/'
```

実行例：

```yaml

$ oc get db2uhadr example-hadr -o yaml | awk '/^status:/,/hadrSettings:/'

status:
  conditions:
  - lastTransitionTime: "2020-12-25T10:47:30Z"
    message: Done
    status: "True"
    type: Creating Db2u HADR configuration files
  - lastTransitionTime: "2020-12-25T10:47:28Z"
    message: Done
    status: "True"
    type: Creating Service endpoints for HADR Primary and Standby
  - lastTransitionTime: "2020-12-25T10:50:38Z"
    message: Done
    status: "True"
    type: Setting up Primary database copy for HADR
  - lastTransitionTime: "2020-12-25T10:47:25Z"
    message: Setting up Standby database copy for HADR
    status: "False"　　　　　　　　　　　　<--- 「True」に変わったら次のステップへ進む
    type: latestPhase
  hadrSettings:

```

上記ステータス・メッセージの「type: Setting up Primary database copy for HADR」が「True」の状態になったら次の手順に進みます。

##Step2. バックアップイメージ/キーストア転送
プライマリPod -> セカンダリPod へ、バックアップイメージとキーストアを転送します。
この2つは、現時点ではプライマリPodの「/mnt/blumeta0/db2/backup」ディレクトリに配置されています。
　(※)スタンバイPodの同ディレクトリは、この時点では空です

プライマリDBからスタンバイDBにバックアップ・イメージを転送するには、Persistent Volumeの共有もしくは rsync を利用することができます。

####① プライマリの /mnt/blumeta0/db2/backup ディレクトリの確認

転送をはじめる前に、プライマリのPodにログインし、転送すべきファイルが作成されていることを確認します。

```
$ oc rsh c-db2ucluster-1-db2u-0 /bin/bash
$ su - db2inst1
$ date ; pwd ; ls -la /mnt/blumeta0/db2/backup
Fri Dec 25 10:58:29 UTC 2020
/mnt/blumeta0/home/db2inst1
total 540844
drwxrwxrwx.  2 db2inst1 db2iadm1        79 Dec 25 10:50 .
drwxr-xr-x. 10      700 wheel          135 Dec 24 07:31 ..
-rw-r--r--.  1 db2inst1 db2iadm1 553816064 Dec 25 10:49 BLUDB.0.db2inst1.DBPART000.20201225104803.001
-rw-r--r--.  1 db2inst1 db2iadm1      4328 Dec 25 10:50 keystore.tar

```

スタンバイにコピーする必要のあるアセットである、

 1. DBバックアップファイル(BLUDB.0.db2inst1.DBPART000.20201225104803.001) 
 2. キーストアファイル(keystore.tar)

が存在することが確認できました。

####② rsyncコマンドによる転送

スタンバイ側の /mnt/blumeta0/db2 ディレクトリー直下に、プライマリ側の /mnt/blumeta0/db2/backup ディレクトリーをコピーします。

 * rsyncコマンドは、ノード <-> Pod 間で、ディレクトリの転送を行うことのできるツールです
    * Pod <-> Pod 間のコピーは出来ない
    * ファイル単位の転送は出来ず、ディレクトリを指定してコピーする
 * 今回は以下のようにファイル転送を行っています
    * 転送元：BastionノードのNFSディレクトリパス (プライマリの/mnt/blumeta0/db2/backupに相当)
    * 転送先：スタンバイPodの/mnt/blumeta0/db2ディレクトリ

```
$ oc rsync /work/nfsdir/Db2NFS_Meta1/db2/backup c-db2ucluster-2-db2u-0:/mnt/blumeta0/db2
sending incremental file list
backup/BLUDB.0.db2inst1.DBPART000.20201225104803.001
backup/keystore.tar

sent 553,955,829 bytes  received 55 bytes  7,970,588.26 bytes/sec
total size is 553,820,392  speedup is 1.00
```

スタンバイPodにログインし、バックアップ・イメージとkeystore tarファイルが転送されていることを確認します。

```
$ ls -la /mnt/blumeta0/db2/backup
total 540844
drwxrwxrwx.  2 db2inst1 db2iadm1        79 Dec 25 11:08 .
drwxr-xr-x. 10      700 wheel          135 Dec 24 08:51 ..
-rw-r--r--.  1 db2uadm  wheel    553816064 Dec 25 10:49 BLUDB.0.db2inst1.DBPART000.20201225104803.001
-rw-r--r--.  1 db2uadm  wheel         4328 Dec 25 10:50 keystore.tar
```

補足：
スタンバイ側に手動コピーしたバックアップ・ファイルとkeystore.tarファイルは、HADRセットアップ完了後は自動削除されるようです。

##Step3. Db2uHADRカスタムリソースのステータス確認
ファイルコピー後、しばらく待機すると、HADR構成は自動的に完了します。
HADRセットアップの進捗は、下記コマンドにて確認することができます。

oc get db2uhadrコマンド出力のSTATEが”Complete"となっていたら、HADR構成が完了しています。

```
$ oc get db2uhadr
NAME           HADRPRIMARY      HADRSTANDBY     STATE      AGE
example-hadr   db2ucluster-1   db2ucluster-2   Complete   2d14h
```

補足：
HADR構成完了時点の詳細ステータスメッセージは下記のようになります。

```
$ oc get db2uhadr example-hadr -o yaml | awk '/^status:/,/hadrSettings:/'
status:
  conditions:
  - lastTransitionTime: "2020-12-25T10:47:30Z"
    message: Done
    status: "True"
    type: Creating Db2u HADR configuration files
  - lastTransitionTime: "2020-12-25T10:47:28Z"
    message: Done
    status: "True"
    type: Creating Service endpoints for HADR Primary and Standby
  - lastTransitionTime: "2020-12-25T11:17:00Z"
    message: Done
    status: "True"
    type: Enabling ACR feature for HADR
  - lastTransitionTime: "2020-12-25T10:50:38Z"
    message: Done
    status: "True"
    type: Setting up Primary database copy for HADR
  - lastTransitionTime: "2020-12-25T11:16:50Z"
    message: Done
    status: "True"
    type: Starting HADR on the Primary database copy
  - lastTransitionTime: "2020-12-25T10:47:25Z"
    message: Setting up Db2u HADR completed
    status: "False"
    type: latestPhase
  hadrSettings:

```


##Step4. HADRの状態確認
HADRの状態確認は、manage-hadr ツールで行うことができます。

コマンド構文：

```
$ oc exec -it <Db2uCluster-Pod-Name> -- manage_hadr -status
```

#### ① スタンバイの状態確認

```
$ oc exec -it c-db2ucluster-2-db2u-0 -- manage_hadr -status


#######################################################################
###           Db2 Advanced Edition high availability and               ###
###             disaster recovery (HADR) management                 ###
#######################################################################


Running HADR action -status on the database BLUDB ...
################################################################################
###                       The HADR status summary                            ###
################################################################################
Database Member 0 -- Database BLUDB -- Standby -- Up 1 days 02:05:33 -- Date 2020-12-28-02.05.47.857426
                            HADR_ROLE = STANDBY
                           HADR_STATE = PEER
                  PRIMARY_MEMBER_HOST = c-db2ucluster-1-db2u-0
                  STANDBY_MEMBER_HOST = c-db2ucluster-2-db2u-0
                  HADR_CONNECT_STATUS = CONNECTED
             HADR_CONNECT_STATUS_TIME = 12/27/2020 00:00:17.102237 (1609027217)
            PRIMARY_LOG_FILE,PAGE,POS = S0000012.LOG, 629, 328647048
            STANDBY_LOG_FILE,PAGE,POS = S0000012.LOG, 629, 328647048
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000012.LOG, 629, 328647048
                      PEER_WINDOW_END = 12/28/2020 02:07:46.000000 (1609121266)

GOVERNOR: RUNNING
The HADR action -status was successful

```

#### ② プライマリの状態確認

```
$ oc exec -it c-db2ucluster-1-db2u-0 -- manage_hadr -status


#######################################################################
###           Db2 Advanced Edition high availability and               ###
###             disaster recovery (HADR) management                 ###
#######################################################################


Running HADR action -status on the database BLUDB ...
################################################################################
###                       The HADR status summary                            ###
################################################################################
Database Member 0 -- Database BLUDB -- Active -- Up 1 days 02:08:40 -- Date 2020-12-28-02.07.21.217258
                            HADR_ROLE = PRIMARY
                           HADR_STATE = PEER
                  PRIMARY_MEMBER_HOST = c-db2ucluster-1-db2u-0
                  STANDBY_MEMBER_HOST = c-db2ucluster-2-db2u-0
                  HADR_CONNECT_STATUS = CONNECTED
             HADR_CONNECT_STATUS_TIME = 12/27/2020 00:00:17.092367 (1609027217)
            PRIMARY_LOG_FILE,PAGE,POS = S0000012.LOG, 629, 328647048
            STANDBY_LOG_FILE,PAGE,POS = S0000012.LOG, 629, 328647048
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000012.LOG, 629, 328647048
                      PEER_WINDOW_END = 12/28/2020 02:09:21.000000 (1609121361)

GOVERNOR: RUNNING
The HADR action -status was successful

```

## 動作確認1: 切り替え(failover)
現スタンバイPodからtakeoverコマンドを実行し、プライマリ -> スタンバイへの切替を行います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/99211aa2-8f8d-03ec-7766-2fa326edb43c.png)



####① フェイルオーバー実行
takeoverコマンドは即時に戻ります。切替自体も数分程度で完了します。
（トランザクションが無い状態）

```
$ oc exec -it c-db2ucluster-2-db2u-0 -- manage_hadr  -takeover


#######################################################################
###           Db2 Advanced Edition high availability and               ###
###             disaster recovery (HADR) management                 ###
#######################################################################


Running HADR action -takeover on the database BLUDB ...
################################################################################
###                     Running takeover HADR on bludb                       ###
################################################################################
Executing HADR role-switch via Db2 Governor ...
current leader is c-db2ucluster-1-db2u-0
new leader is c-db2ucluster-2-db2u-0


################################################################################
###            The manage_hadr command completed an HADR takeover.           ###
################################################################################


The HADR action -takeover was successful

```

####② フェイルオーバー後の新Primaryデータベースの状態確認
新プライマリ(旧スタンバイ) の「HADR_ROLE」が「PRIMARY」に変わっていることが確認できます。

```
$ oc exec -it c-db2ucluster-2-db2u-0 -- manage_hadr -status


#######################################################################
###           Db2 Advanced Edition high availability and               ###
###             disaster recovery (HADR) management                 ###
#######################################################################


Running HADR action -status on the database BLUDB ...
################################################################################
###                       The HADR status summary                            ###
################################################################################
Database Member 0 -- Database BLUDB -- Active -- Up 1 days 03:11:08 -- Date 2020-12-28-03.11.22.516943
                            HADR_ROLE = PRIMARY
                           HADR_STATE = PEER
                  PRIMARY_MEMBER_HOST = c-db2ucluster-2-db2u-0
                  STANDBY_MEMBER_HOST = c-db2ucluster-1-db2u-0
                  HADR_CONNECT_STATUS = CONNECTED
             HADR_CONNECT_STATUS_TIME = 12/28/2020 03:11:07.878952 (1609125067)
            PRIMARY_LOG_FILE,PAGE,POS = S0000013.LOG, 4, 346478652
            STANDBY_LOG_FILE,PAGE,POS = S0000013.LOG, 4, 346478652
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000013.LOG, 4, 346478652
                      PEER_WINDOW_END = 12/28/2020 03:13:18.000000 (1609125198)

GOVERNOR: RUNNING
The HADR action -status was successful
```

新プライマリのPodにログインし、データの参照ができることも確認します。

```
$ oc exec -it c-db2ucluster-2-db2u-0 -- /bin/bash
[db2uadm@c-db2ucluster-2-db2u-0 /]$ su - db2inst1
Last login: Mon Dec 28 03:13:10 UTC 2020 on pts/3
[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ db2 connect to bludb

   Database Connection Information

 Database server        = DB2/LINUXX8664 11.5.5.0
 SQL authorization ID   = DB2INST1
 Local database alias   = BLUDB

[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ db2 "insert into t1 values (11,'aa')"
DB20000I  The SQL command completed successfully.
[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ db2 "select * from t1"

C1          C2
----------- --------
          1 a
          2 b
         11 aa

  3 record(s) selected.

[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ db2 terminate
DB20000I  The TERMINATE command completed successfully.
[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ exit
[db2uadm@c-db2ucluster-2-db2u-0 /]$ exit

```

takeoverが成功し、新プライマリ上のDBに接続しデータアクセス(参照・更新)できるようになっていることが確認できました。



## 動作確認2: 切り戻し(failback)
テイクオーバー後(＝元々のスタンバイPodが新プライマリとしてサービスを提供している状態)、
再度takeoverを行うと、旧プライマリPod のロールがプライマリに戻ります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/002cbd9b-319a-90d3-553b-1bff5c25af03.png)



####① フェイルバック実行
takeoverコマンドは即時に戻ります。切替自体も数分程度で完了します。
（トランザクションが無い状態）

```
$ oc exec -it c-db2ucluster-1-db2u-0 -- manage_hadr  -takeover


#######################################################################
###           Db2 Advanced Edition high availability and               ###
###             disaster recovery (HADR) management                 ###
#######################################################################


Running HADR action -takeover on the database BLUDB ...
################################################################################
###                     Running takeover HADR on bludb                       ###
################################################################################
Executing HADR role-switch via Db2 Governor ...
current leader is c-db2ucluster-2-db2u-0
new leader is c-db2ucluster-1-db2u-0


################################################################################
###            The manage_hadr command completed an HADR takeover.           ###
################################################################################


The HADR action -takeover was successful

```


####② フェイルバック後の新Primaryデータベースの状態確認
Primary の「HADR_ROLE」が「PRIMARY」に戻っていることが確認できます。

```
$ oc exec -it c-db2ucluster-1-db2u-0 -- manage_hadr -status


#######################################################################
###           Db2 Advanced Edition high availability and               ###
###             disaster recovery (HADR) management                 ###
#######################################################################


Running HADR action -status on the database BLUDB ...
################################################################################
###                       The HADR status summary                            ###
################################################################################
Database Member 0 -- Database BLUDB -- Active -- Up 0 days 00:17:18 -- Date 2020-12-28-03.28.17.033400
                            HADR_ROLE = PRIMARY
                           HADR_STATE = PEER
                  PRIMARY_MEMBER_HOST = c-db2ucluster-1-db2u-0
                  STANDBY_MEMBER_HOST = c-db2ucluster-2-db2u-0
                  HADR_CONNECT_STATUS = CONNECTED
             HADR_CONNECT_STATUS_TIME = 12/28/2020 03:26:23.011800 (1609125983)
            PRIMARY_LOG_FILE,PAGE,POS = S0000014.LOG, 4, 366858652
            STANDBY_LOG_FILE,PAGE,POS = S0000014.LOG, 4, 366858652
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000014.LOG, 4, 366858652
                      PEER_WINDOW_END = 12/28/2020 03:30:14.000000 (1609126214)

GOVERNOR: RUNNING
The HADR action -status was successful

```

『動作確認1: 切り替え(failover)』でINSERTしたレコードが存在することを、切り戻し後のプライマリPodで確認します。

◇切替後に追加したレコード：
> $ db2 "insert into t1 values (11,'aa')"


```
$ oc exec -it c-db2ucluster-1-db2u-0 -- /bin/bash
[db2uadm@c-db2ucluster-1-db2u-0 /]$ su - db2inst1
Last login: Mon Dec 28 03:34:30 UTC 2020 on pts/3
[db2inst1@c-db2ucluster-1-db2u-0 - Db2U db2inst1]$ db2 connect to bludb

   Database Connection Information

 Database server        = DB2/LINUXX8664 11.5.5.0
 SQL authorization ID   = DB2INST1
 Local database alias   = BLUDB

[db2inst1@c-db2ucluster-1-db2u-0 - Db2U db2inst1]$ db2 "select * from t1"

C1          C2
----------- --------
          1 a
          2 b
         11 aa

  3 record(s) selected.

[db2inst1@c-db2ucluster-1-db2u-0 - Db2U db2inst1]$ db2 terminate
DB20000I  The TERMINATE command completed successfully.
[db2inst1@c-db2ucluster-1-db2u-0 - Db2U db2inst1]$ exit
[db2uadm@c-db2ucluster-1-db2u-0 /]$ exit
exit

```

 ---> スタンバイDBへの切替後にレコード追加を行った処理についてHADRデータベース間で無事にログ転送が行われ、切り戻し後のプライマリDBでも該当の更新処理内容が反映されていることが確認できました。


##付録 db2pd -hadr 出力
プライマリ、スタンバイそれぞれのPodにログインし、db2pdにてHADRステータス情報を確認した結果を添付しておきます。

####① プライマリ

```
$ oc exec -it c-db2ucluster-1-db2u-0
$ su - db2inst1
$ db2pd -hadr -db bludb

Database Member 0 -- Database BLUDB -- Active -- Up 1 days 02:37:33 -- Date 2020-12-28-02.36.14.870306

                            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 = c-db2ucluster-1-db2u-0
                     PRIMARY_INSTANCE = db2inst1
                       PRIMARY_MEMBER = 0
                  STANDBY_MEMBER_HOST = c-db2ucluster-2-db2u-0
                     STANDBY_INSTANCE = db2inst1
                       STANDBY_MEMBER = 0
                  HADR_CONNECT_STATUS = CONNECTED
             HADR_CONNECT_STATUS_TIME = 12/27/2020 00:00:17.092367 (1609027217)
          HEARTBEAT_INTERVAL(seconds) = 5
                     HEARTBEAT_MISSED = 0
                   HEARTBEAT_EXPECTED = 19152
                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.000024
   LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.125
                  LOG_HADR_WAIT_COUNT = 3152
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 361280
            PRIMARY_LOG_FILE,PAGE,POS = S0000012.LOG, 629, 328647048
            STANDBY_LOG_FILE,PAGE,POS = S0000012.LOG, 629, 328647048
                  HADR_LOG_GAP(bytes) = 0
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000012.LOG, 629, 328647048
       STANDBY_RECV_REPLAY_GAP(bytes) = 0
                     PRIMARY_LOG_TIME = 12/28/2020 01:00:31.000000 (1609117231)
                     STANDBY_LOG_TIME = 12/28/2020 01:00:31.000000 (1609117231)
              STANDBY_REPLAY_LOG_TIME = 12/28/2020 01:00:31.000000 (1609117231)
         STANDBY_RECV_BUF_SIZE(pages) = 4300
             STANDBY_RECV_BUF_PERCENT = 0
           STANDBY_SPOOL_LIMIT(pages) = 125000
                STANDBY_SPOOL_PERCENT = 0
                   STANDBY_ERROR_TIME = NULL
                 PEER_WINDOW(seconds) = 120
                      PEER_WINDOW_END = 12/28/2020 02:38:11.000000 (1609123091)
             READS_ON_STANDBY_ENABLED = N
              HADR_LAST_TAKEOVER_TIME = 12/26/2020 23:58:16.000000 (1609027096)

```

####② スタンバイ

```
$ oc exec -it c-db2ucluster-2-db2u-0 -- /bin/bash
$ su - db2inst1
$ db2pd -hadr -db bludb

Database Member 0 -- Database BLUDB -- Standby -- Up 1 days 02:25:57 -- Date 2020-12-28-02.26.11.213499

                            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 = c-db2ucluster-1-db2u-0
                     PRIMARY_INSTANCE = db2inst1
                       PRIMARY_MEMBER = 0
                  STANDBY_MEMBER_HOST = c-db2ucluster-2-db2u-0
                     STANDBY_INSTANCE = db2inst1
                       STANDBY_MEMBER = 0
                  HADR_CONNECT_STATUS = CONNECTED
             HADR_CONNECT_STATUS_TIME = 12/27/2020 00:00:17.102237 (1609027217)
          HEARTBEAT_INTERVAL(seconds) = 5
                     HEARTBEAT_MISSED = 0
                   HEARTBEAT_EXPECTED = 19030
                HADR_TIMEOUT(seconds) = 120
        TIME_SINCE_LAST_RECV(seconds) = 1
             PEER_WAIT_LIMIT(seconds) = 0
           LOG_HADR_WAIT_CUR(seconds) = 0.000
    LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000024
   LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.125
                  LOG_HADR_WAIT_COUNT = 3152
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 359360
            PRIMARY_LOG_FILE,PAGE,POS = S0000012.LOG, 629, 328647048
            STANDBY_LOG_FILE,PAGE,POS = S0000012.LOG, 629, 328647048
                  HADR_LOG_GAP(bytes) = 0
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000012.LOG, 629, 328647048
       STANDBY_RECV_REPLAY_GAP(bytes) = 0
                     PRIMARY_LOG_TIME = 12/28/2020 01:00:31.000000 (1609117231)
                     STANDBY_LOG_TIME = 12/28/2020 01:00:31.000000 (1609117231)
              STANDBY_REPLAY_LOG_TIME = 12/28/2020 01:00:31.000000 (1609117231)
         STANDBY_RECV_BUF_SIZE(pages) = 4300
             STANDBY_RECV_BUF_PERCENT = 0
           STANDBY_SPOOL_LIMIT(pages) = 125000
                STANDBY_SPOOL_PERCENT = 0
                   STANDBY_ERROR_TIME = NULL
                 PEER_WINDOW(seconds) = 120
                      PEER_WINDOW_END = 12/28/2020 02:28:11.000000 (1609122491)
             READS_ON_STANDBY_ENABLED = N
              HADR_LAST_TAKEOVER_TIME = NULL

```

## 関連記事

◆Db2 11.5.5 on OpenShift デプロイ手順
https://qiita.com/mi-kana/items/6266fcdcdc3b71d8a0fb
◆OpenShift環境へのDb2 Operator導入手順
https://qiita.com/mi-kana/items/c3fb640d671caf624eb8
◆Db2 11.5.5 on OpenShift：GUIベースのデプロイ手順
https://qiita.com/mi-kana/items/f429c7e4e86f6077df84


-------
以上です。