LoginSignup
5
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@mi-kana

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

Last updated at Posted at 2021-02-01

HADR とは

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

参考：Db2製品マニュアル [高可用性災害時リカバリー (HADR)]

Db2 on OpenShift における HADR

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

  • HADR構成前に、以下のセットアップが済んでいることを前提とします

    • Db2 Operatorが導入済みであること (補足：Db2 Operatorとは)
    • Db2u Cluster(Db2本体) のインスタンスを2セット導入済みであること
      (HADRのプライマリとスタンバイ)
      • プライマリ、スタンバイは同一のリリース・レベルである必要があります

  • Db2u Cluster導入手順はこちらに書いていますので、ここでは割愛します

  • Db2 on OpenShift でHADR構成を組むには下記3つの構成パターンがあり、今回は①の構成です

    • ① 同一ネームスペース(プロジェクト)内
    • ② 同一クラスター内 / 異なるネームスペース間
    • ③ 異なるクラスター間

  • Db2 HADRには複数の同期モードが提供されますが、下記手順で構成したHADRの同期モードは、
    デフォルトの「NEARSYNC」となります

  • Db2 11.5.6 では、HADR マルチスタンバイ構成がサポートされるようになりました

    • 複製するスタンバイを3つまで構成することが可能です
    • ただし、自動引き継ぎは1次スタンバイのみがサポートされます（この制約はオンプレ版と同じ）

参考：

導入環境

以下の環境に 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

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

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

ユーザ 用途/補足
rootユーザ NFSサーバのセットアップ用
OCPユーザ ocコマンド実行
(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]

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

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

1-1. Yaml作成

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

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

導入済みのDb2uClusterの名前を指定し、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:/'

実行例：


$ 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

① フェイルオーバー実行

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

① フェイルバック実行

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

以上です。

5
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
5
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?