3
0

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.

Db2 for OpenShift/Kubernetes の Storage Snapshot 取得手順

3
Last updated at Posted at 2023-03-28

はじめに

OpenShift/Kubernetes環境でDb2を動かすには、マイクロサービスとして開発される、k8s環境専用のDb2製品を導入します。
このDb2は、Db2 for Red Hat OpenShift and Kubernetes、別名Db2Uとも呼ばれます。
Db2として公式の Kubernetes Operator が提供されています。

Db2 for OpenShift のバックアップには、いくつかの方法が提供されます。

このうち、ストレージ機能を利用したスナップショット取得リストアを試すことができたので、この手順を備忘録として残します。
スナップショット取得/リストアの操作はコマンドラインでも実行可能ですが、オプション指定が不要で使い勝手の良いGUI(OCP Webコンソール)を利用します。

環境

全体構成

  • Red Hat OpenShift Kubernetes Service (ROKS) 上に Db2 for OpenShift をデプロイ
  • 最小構成である、2つのPVCにDb2関連データを保持する構成とする
    • ユーザデータ、トランザクションログ、メタデータ等を配置するため
    • より多くのPVCに分散配置し、I/Oを分散させる構成も可能 → Link)
  • ストレージは、OpenShift Data Foundation を利用

image.png

コンポーネント バージョン
OpenShift 4.10.52
OpenShift Data Foundation odf-operator.v4.10.9
Db2 for OpenShift s11.5.8.0

参考:Db2マニュアル Db2 for RHOS and K8s > 11.5.8 > Installing Db2

ボリュームスナップショットクラス

cephfs用、cephrbd用のスナップショットクラスを利用してSnapshot取得、リストアを行います。

root@IBM-PF2E8K5F:~# oc get volumesnapshotclass
NAME                                        DRIVER                                  DELETIONPOLICY   AGE
ocs-storagecluster-cephfsplugin-snapclass   openshift-storage.cephfs.csi.ceph.com   Delete           35d
ocs-storagecluster-rbdplugin-snapclass      openshift-storage.rbd.csi.ceph.com      Delete           35d
root@IBM-PF2E8K5F:~#

Snapshot取得検証

全体の流れ

以下の流れで取得します。
Snapshotを取得した後、データを追加しておきます。(ユーザミスにより不要データが混入した状態とみなす)
取得したSnapshotのリストアにより、この不要なデータは消えて元の状態に戻ったことを確認します。

  1. 検証開始前のデータ内容確認
  2. Snapshot取得
  3. Snapshot取得後のデータ編集
  4. リストア
  5. リストア後のデータ内容確認

Step1. 検証開始前のデータ内容確認

T1表に1行のみ格納した状態でSnapshotを取得します。

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

C1          C2                               C3

----------- -------------------------------- --------------------------
          1 before snapshot                  2023-02-28-06.56.11.996187

  1 record(s) selected.

Step2. Snapshot取得

スナップショット取得にあたり、静止点を作る必要があります。
この点は従来からあるオンプレミス版Db2と同じです。
Db2 for OpenShift/Kubernetes環境においてDb2によるデータ領域へのwrite処理を静止するための専用コマンドが用意されています。書き込み処理をサスペンドしている間に、Snapshotを取得します。

以下のマニュアルに従って進めます。
Performing a snapshot backup with Db2 container commands

Step2-1. 書き込み処理の静止

date ; oc exec -it c-db2ucluster-2-db2u-0 -- manage_snapshots --action suspend
2023年  2月 28日 火曜日 16:00:19 JST
Defaulted container "db2u" out of: db2u, init-labels (init), init-kernel (init)
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
Wolverine HA management state was disabled successfully.

connect to SAMPLEDB

   Database Connection Information

 Database server        = DB2/LINUXX8664 11.5.8.0
 SQL authorization ID   = DB2INST1
 Local database alias   = SAMPLEDB


terminate
DB20000I  The TERMINATE command completed successfully.

*************************************************

Suspending write on the databases...this may take a while
Database Member 0 -- Database SAMPLEDB -- Active -- Up 10 days 19:56:36 -- Date 2023-02-28-07.00.29.315480
Database is in write suspend state NO                   NO
Database: SAMPLEDB
Validating if write suspend on SAMPLEDB was successful ...
Database Member 0 -- Database SAMPLEDB -- Active -- Up 10 days 19:56:43 -- Date 2023-02-28-07.00.36.896384
Database is in write suspend state YES                  YES

*************************************************
Successfully suspended writes on the database(s)
*************************************************

db2diag.logにも、write suspended が実行された際のログが出力されます。
出力量が多いため、当記事末尾に添付します。

Step2-2. Db2 HA モニターを停止

Db2 for OpenShift/Kubernetes同梱のHAモニターを停止します。

date ; oc exec -it c-db2ucluster-2-db2u-0 -- wvcli system status
2023年  2月 28日 火曜日 16:00:59 JST
Defaulted container "db2u" out of: db2u, init-labels (init), init-kernel (init)
HA Management is DISABLED at 2023-02-28 07:01:02.657.
root@IBM-PF2E8K5F:~#

Step2-3. ODF Snapshot取得(VolumeSnapshot作成)

ストレージスナップショットをOCP Webコンソールから取得します。
Db2マニュアルでは、各ストレージ製品のマニュアルを参照するようガイドされます。
今回はODFを利用するためODFのスナップショット作成手順に従い作業します。
Documentation > OpenShift Container Platform > Storage Using Container Storage Interface (CSI) > CSI volume snapshot > Creating a volume snapshot

Step2-3-1. メタデータ用領域のSnapshot取得

左メニューリストより、ストレージ > ボリュームスナップショットを選択
image.png

「ボリュームスナップショットの作成」を押下
image.png

「永続ボリューム要求」のドロップダウンリストから、Db2が利用するPVCを選択
 ※ 複数あるため、利用するPVCについて同じ作業を繰り返します。(順不同)

PVC Db2uClusterデプロイ時のPVC名
メタデータ用PVC c-db2ucluster-2-meta
データ用PVC data-c-db2ucluster-2-db2u-0

image.png

Db2メタデータ用PVCのバックアップを取得

  • PVCを選択すると、スナップショット名もスナップショットクラスも自動選択される
    • cephfs:ocs-storagecluster-cephfsplugin-snapclass
    • cephrdb:ocs-storagecluster-rbdplugin-snapclass

image.png

取得中の画面:
「作成した時間」が「進行中」と表記されます。1分程度で遷移します
image.png

取得されたスナップショットは、「ボリュームスナップショット」の画面で確認することができます。
image.png

Step2-3-2. データ用領域のSnapshot取得

手順は、「Step2-3-1. メタデータ用領域のSnapshot取得」と同一のため割愛します

  • スナップショットクラス:ocs-storagecluster-rbdplugin-snapclass
    image.png

(Snapshot取得完了後のWebコンソール画面。2つのPVCのボリュームスナップショットが取得済)
image.png

Step2-3-3. (蛇足) 書き込み静止中のSQL実行可否を確認

従来のオンプレミス版Db2であれば、以下のようになります。Db2Uでも同様か、確認しました。

  • 表スペース、ログ領域への書き込みを伴わない読取処理(SELECT文など) → 実行可能
  • 上記を伴う書き込み処理(INSERT文など) → 待機させられる

結果としてはオンプレミス版同様の挙動となりました。

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

C1          C2                               C3

----------- -------------------------------- --------------------------
          1 before snapshot                  2023-02-28-06.56.11.996187

  1 record(s) selected.

[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$
[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ db2 "insert into t1 values (2, 'during write suspend' , current timestamp)" 
    ←--- 待機させられる
    ←--- 後続 Step2-4. の Write Suspend Resume コマンド実行中にDB20000I メッセージが戻りINSERT完了
DB20000I  The SQL command completed successfully.
[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$

(事後確認結果:INSERT文はWRITE SUSPEND中は待機させられていたが、無事完了)

[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ date ; db2 "select * from t1"
Tue Feb 28 07:25:55 UTC 2023
C1          C2                               C3
----------- -------------------------------- --------------------------
          1 before snapshot                  2023-02-28-06.56.11.996187
          2 during write suspend             2023-02-28-07.19.10.095425

  2 record(s) selected.

[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$

Step2-4. 書き込み静止の解除

date ; oc exec -it c-db2ucluster-2-db2u-0 -- manage_snapshots --action resume
2023年  2月 28日 火曜日 16:20:57 JST
Defaulted container "db2u" out of: db2u, init-labels (init), init-kernel (init)
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

connect to SAMPLEDB

   Database Connection Information

 Database server        = DB2/LINUXX8664 11.5.8.0
 SQL authorization ID   = DB2INST1
 Local database alias   = SAMPLEDB

terminate
DB20000I  The TERMINATE command completed successfully.

connect to SAMPLEDB

   Database Connection Information

 Database server        = DB2/LINUXX8664 11.5.8.0
 SQL authorization ID   = DB2INST1
 Local database alias   = SAMPLEDB

terminate
DB20000I  The TERMINATE command completed successfully.

*************************************************
Resuming write on SAMPLEDB...this may take a while

   Database Connection Information

 Database server        = DB2/LINUXX8664 11.5.8.0
 SQL authorization ID   = DB2INST1
 Local database alias   = SAMPLEDB

DB20000I  The SET WRITE command completed successfully.
connect to SAMPLEDB

   Database Connection Information

 Database server        = DB2/LINUXX8664 11.5.8.0
 SQL authorization ID   = DB2INST1
 Local database alias   = SAMPLEDB

terminate
DB20000I  The TERMINATE command completed successfully.

Successfully resumed write on SAMPLEDB
*************************************************

System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
Wolverine HA management state was enabled successfully.

※上記のとおりコマンド出力として下記メッセージが出力されますが、この間、db2diag.logには何もメッセージが出ません。ただしこのコマンド実行中に、仕掛けておいたINSERT文も成功しているので書き込み静止状態の解除処理は想定どおり実行されているようです。

DB20000I The SET WRITE command completed successfully.

Step2-5. Db2 HA モニターの再開

Db2 for OpenShift/Kubernetes同梱のHAモニターを開始します。

date ; oc exec -it c-db2ucluster-2-db2u-0 -- wvcli system status
2023年  2月 28日 火曜日 16:26:14 JST
Defaulted container "db2u" out of: db2u, init-labels (init), init-kernel (init)
HA Management is RUNNING at 2023-02-28 07:26:17.920.

Step3. Snapshot取得後のデータ編集

WRITE SUSPEND状態を解除しHAモニターを再開した状態で、データベースに更新(新規データ追加)を行います。

◆データ行追加
[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ date ; db2 "insert into t1 values (3, 'after snapshot', current timestamp)"
Tue Feb 28 07:27:51 UTC 2023
DB20000I  The SQL command completed successfully.

◆データ確認
[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ date ; db2 "select * from t1 order by c3"
Tue Feb 28 07:28:09 UTC 2023
C1          C2                               C3
----------- -------------------------------- --------------------------
          1 before snapshot                  2023-02-28-06.56.11.996187
          2 during write suspend             2023-02-28-07.19.10.095425
          3 after snapshot                   2023-02-28-07.27.51.146033  ← 追加されている
  3 record(s) selected.

[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$

Step4. リストア

PVC Snapshotリストアにあたっては、Db2マニュアルに記載される通り、事前にDb2クラスタをメンテナンスモードとし、すべてのPodを停止(replicas数=0)しておく必要があります。

ODF Snapshotのリストア作業自体は、以下のマニュアルに従って進めます。
Performing a snapshot restore with Db2 container commands in Db2

Step4-2で設定するOS環境変数はリストア操作を通じて利用することになるため、リストア作業が終わるまで同じターミナルを利用しつづけるほうが楽です。

Step4-1. Db2クラスタをメンテナンスモードにする

date ; oc annotate db2ucluster $DB2U_CLUSTER db2u.databases.ibm.com/maintenance-pause-reconcile=true --overwrite
2023年  2月 28日 火曜日 19:55:36 JST
db2ucluster.db2u.databases.ibm.com/db2ucluster-2 annotated

Step4-2. Deployment 停止

Db2UではDb2エンジン本体のPodだけでなく、LDAP, etcdなど複数種類のPodが連動しサービス提供を行うものです。
Db2uClusterカスタムリソース配下すべてのDepoyment/StatefulSetのレプリカ数を0に変更し、Podを停止します。

Db2uClusterカスタムリソース名をOS環境変数にセットします

DB2U_CLUSTER=db2ucluster-2

Db2uClusterのStatefulSet名称を取得します(→c-db2ucluster-2-db2u)

DB2U_STS=$(oc get sts --selector="app=${DB2U_CLUSTER},type=engine" --no-headers | awk '{print $1}');echo $DB2U_STS
c-db2ucluster-2-db2u

Db2uエンジン本体(StatefulSet)のレプリカ数を取得し、OS環境変数にセットします
(→NEW_REPLICAS=1)

NUM_REPLICAS=$(oc get sts ${DB2U_STS} -ojsonpath={.spec.replicas}) ; echo $NUM_REPLICAS
1

Db2U StatefulSetのレプリカ数を0に変更しPodを停止します

date ; oc scale sts ${DB2U_STS} --replicas=0
2023年  2月 28日 火曜日 20:03:59 JST
statefulset.apps/c-db2ucluster-2-db2u scaled

etcdのStatefulSet名を取得します(→ c-db2ucluster-2-etcd)

ETCD_STS=$(oc get sts --selector="app=${DB2U_CLUSTER},component=etcd" --no-headers | awk '{print $1}'); echo $ETCD_STS
c-db2ucluster-2-etcd

etcd StatefulSetのレプリカ数を0に変更しPodを停止します

date ; oc scale sts ${ETCD_STS} --replicas=0
2023年  2月 28日 火曜日 20:04:07 JST
statefulset.apps/c-db2ucluster-2-etcd scaled

LDAP Deploymentのレプリカ数を0に変更しPodを停止します

date ; oc scale deploy c-db2ucluster-2-ldap --replicas=0
2023年  2月 28日 火曜日 20:28:51 JST
deployment.apps/c-db2ucluster-2-ldap scaled

※今回検証した時点ではDb2マニュアルに不備がありLDAP Deploymentを停止する手順がありませんでした。事後(リストア失敗後)にLDAPレプリカ数を0としたため、タイムスタンプが他と一致しません。

マニュアルに提示される、"role=tools"に該当するDeploymentは今回の環境には存在しないため、Deployment停止(レプリカ数変更)操作の対象外とします

TOOLS_DEPLOY=$(oc get deploy --selector="app=${DB2U_CLUSTER},role=tools" --no-headers | awk '{print $1}'); echo $TOOLS_DEPLOY
No resources found in db2u-1 namespace.

補足:
マニュアルを見ると、role=toolsに該当するDeploymentが存在する環境ではc--tools-xxxxx というPodが稼働するようでした。
Enabling the Db2 REST interface

Step4-3. 既存PVC定義をコピー

リストア対象となるPVC2つにラベルを付与します

date ; oc label pvc c-${DB2U_CLUSTER}-meta app=${DB2U_CLUSTER}
2023年  2月 28日 火曜日 20:06:54 JST
persistentvolumeclaim/c-db2ucluster-2-meta labeled

PVC定義Yamlのコピーを作成します

for PVC in $(oc get pvc -l app=$DB2U_CLUSTER --no-headers | awk '{print $1}'); do oc get pvc $PVC -o yaml > ${PVC}_copy.yaml ; done

Yamlファイルが作成されたことを確認します。(Yamlは当記事末尾に添付)

ls -ltr
合計 8
-rw-r--r-- 1 root root 1143  2月 28 20:18 c-db2ucluster-2-meta_copy.yaml
-rw-r--r-- 1 root root 1180  2月 28 20:18 data-c-db2ucluster-2-db2u-0_copy.yaml

Step4-4. 有事に備え、既存PVのReclaim PolicyをRetainに変更

OpenShift(Kubernetes)ではPVCのデフォルトとしてReclaim Policy=Deleteとなっていて、PVCを削除すると紐づけられていたPVは自動削除されます。
ここでは、万が一Snapshotリストア前の状態のデータを復元する必要が生じた場合に備えて、PVC削除後もPVがそのまま残存する構成に変更しておきます。

変更前:Reclaim Policy=Delete

date ; oc get pv | grep -i db2ucluster-2
2023年  2月 28日 火曜日 20:21:04 JST
pvc-5c9cd839-470e-47bc-b6e3-190520325572   10Gi       RWO            Delete           Bound    db2u-1/data-c-db2ucluster-2-db2u-0                                   ocs-storagecluster-ceph-rbd                11d
pvc-d2b126cc-a486-419b-b239-39c4e90b2ea6   10Gi       RWX            Delete           Bound    db2u-1/c-db2ucluster-2-meta                                          ocs-storagecluster-cephfs                  11d

Reclaim Policy変更:

for PV in $(oc get pv --no-headers | grep $DB2U_CLUSTER | awk '{print $1}'); do oc patch pv $PV -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}" ; done
persistentvolume/pvc-5c9cd839-470e-47bc-b6e3-190520325572 patched
persistentvolume/pvc-d2b126cc-a486-419b-b239-39c4e90b2ea6 patched

変更後:Reclaim Policy=Retain

date ; oc get pv | grep -i db2ucluster-2
2023年  2月 28日 火曜日 20:21:40 JST
pvc-5c9cd839-470e-47bc-b6e3-190520325572   10Gi       RWO            Retain           Bound    db2u-1/data-c-db2ucluster-2-db2u-0                                   ocs-storagecluster-ceph-rbd                11d
pvc-d2b126cc-a486-419b-b239-39c4e90b2ea6   10Gi       RWX            Retain           Bound    db2u-1/c-db2ucluster-2-meta                                          ocs-storagecluster-cephfs                  11d

Step4-5. 既存PVCの削除

PVCを削除します。

date ; oc delete pvc -l app=${DB2U_CLUSTER}
2023年  2月 28日 火曜日 20:22:04 JST
persistentvolumeclaim "c-db2ucluster-2-meta" deleted
persistentvolumeclaim "data-c-db2ucluster-2-db2u-0" deleted

PVCが削除されている(→存在しない)ことを確認します。

date ; oc get pvc | grep -i db2ucluster-2
2023年  2月 28日 火曜日 20:38:00 JST
  ←--- 出力無となった
root@IBM-PF2E8K5F:~/db2u/pvc#

PVはReleased状態として残存していることも確認できました。

oc get pv | grep -i db2ucluster-2
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM
                                              STORAGECLASS                      REASON   AGE
(中略)
pvc-5c9cd839-470e-47bc-b6e3-190520325572   10Gi       RWO            Retain           Released   db2u-1/data-c-db2ucluster-2-db2u-0                                   ocs-storagecluster-ceph-rbd                38d
pvc-d2b126cc-a486-419b-b239-39c4e90b2ea6   10Gi       RWX            Retain           Released   db2u-1/c-db2ucluster-2-meta                                          ocs-storagecluster-cephfs                  38d

※後日取得のためdateコマンド取得せず

Step4-6. 元のnamespaceへ、同名PVCとして、volumesnapshotをリストアする (Webコンソール)

こちらのマニュアルの手順に従い操作します。
Documentation > OpenShift Container Platform > Storage Using Container Storage Interface (CSI) > CSI volume snapshots > Restoring a volume snapshot

復元対象は、Db2uClusterからmountされるすべてのPVCです。
今回の環境では下記2つで、特に順序依存性はなく対象PVCをすべて復元します。

PVC Db2uClusterデプロイ時のPVC名 Step2で取得したVolume Snapshot名
メタデータ用PVC c-db2ucluster-2-meta c-db2ucluster-2-meta-snapshot
データ用PVC data-c-db2ucluster-2-db2u-0 data-c-db2ucluster-2-db2u-0-snapshot

ここではメタデータ用PVCから復元します。

Webコンソールから、ストレージ > ボリュームスナップショット の画面を開きます。
取得されているボリュームスナップショットの一覧から、
Db2メタデータ用PVC(もしくはデータ)を探し、最右列の縦三点リーダーボタンをクリックします。
image.png

「新規PVCとして復元」を選択します
image.png

復元されるPVCの名前だけ変更します。
(デフォルトでSnapshot取得した場合、元のPVC名末尾に[-snapshot-restore]と付与されているのを削除する)
その他の設定項目は、自動選択されているものを受け入れて「復元」します。
image.png

開始直後しばらくは以下のようなPending / 進行中 というステータスとなります
image.png

1分程度でBOUND状態になりました。
image.png

同じ要領で、データ用PVCも復元します。
  ※ PVC名を、元のPVC名に編集すること
image.png

Step4-7. Deployment, StatefulSetの起動

Step4-2.で確認したレプリカ数に戻し、Podを再稼働させます。
今回の環境では、replicas=1 に戻すことになります。

※ 再掲:Snapshotリストア前の確認結果では、db2u(StatefulSet)のレプリカ数は1でした

(再掲) レプリカ数確認結果
NUM_REPLICAS=$(oc get sts ${DB2U_STS} -ojsonpath={.spec.replicas}) ; echo $NUM_REPLICAS
1

引き続き同じターミナルで作業しているためNUM_REPLICAS変数は維持されています

echo ${NUM_REPLICAS}
1

※この環境変数が失われている場合は、NUM_REPLICAS=1と設定しなおした上で後続コマンドを実行します。

etcd のレプリカ数を1に戻し、起動します

date ; oc scale sts ${ETCD_STS} --replicas=${NUM_REPLICAS}
2023年  2月 28日 火曜日 20:52:55 JST
statefulset.apps/c-db2ucluster-2-etcd scaled

ldap のレプリカ数を1に戻し、起動します

date ; oc scale deploy c-db2ucluster-2-ldap --replicas=${NUM_REPLICAS}
2023年  2月 28日 火曜日 20:53:13 JST
deployment.apps/c-db2ucluster-2-ldap scaled

Db2u (Db2エンジン本体の載るStatefulSet) のレプリカ数を1に戻し、起動します

date ; oc scale sts ${DB2U_STS} --replicas=${NUM_REPLICAS}
2023年  2月 28日 火曜日 20:53:19 JST
statefulset.apps/c-db2ucluster-2-db2u scaled

稼働状況を取得します。
db2u, ldap, etcd のPodのSTATUSがRunning、READY 1/1の状態となっていて正常稼働状態に復旧できていることが確認できます

oc get all

NAME                                         READY   STATUS      RESTARTS     AGE
pod/c-db2ucluster-2-db2u-0                   1/1     Running     0            86s
pod/c-db2ucluster-2-etcd-0                   1/1     Running     0            112s
pod/c-db2ucluster-2-instdb-2tlpk             0/1     Completed   0            11d
pod/c-db2ucluster-2-ldap-557898d945-2kr4r    1/1     Running     0            94s
pod/c-db2ucluster-2-restore-morph-kwn5d      0/1     Completed   0            11d
pod/db2u-operator-manager-74c8746449-ncplx   1/1     Running     1 (8d ago)   25d

NAME                                         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
service/c-db2ucluster-2-db2u                 ClusterIP   172.21.229.55    <none>        50000/TCP,50001/TCP,25000/TCP,25001/TCP,25002/TCP,25003/TCP,25004/TCP,25005/TCP   11d
service/c-db2ucluster-2-db2u-engn-svc        NodePort    172.21.173.50    <none>        50000:30770/TCP,50001:31605/TCP                                                   11d
service/c-db2ucluster-2-db2u-head-engn-svc   NodePort    172.21.236.242   <none>        50000:31406/TCP,50001:31701/TCP                                                   11d
service/c-db2ucluster-2-db2u-internal        ClusterIP   None             <none>        50000/TCP,9443/TCP,50052/TCP                                                      11d
service/c-db2ucluster-2-etcd                 ClusterIP   None             <none>        2379/TCP,2380/TCP                                                                 11d
service/c-db2ucluster-2-ldap                 ClusterIP   172.21.124.70    <none>        50389/TCP
                                                                                  11d

NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/c-db2ucluster-2-ldap    1/1     1            1           11d
deployment.apps/db2u-operator-manager   1/1     1            1           25d

NAME                                               DESIRED   CURRENT   READY   AGE
replicaset.apps/c-db2ucluster-2-ldap-557898d945    1         1         1       11d
replicaset.apps/db2u-operator-manager-74c8746449   1         1         1       25d

NAME                                    READY   AGE
statefulset.apps/c-db2ucluster-2-db2u   1/1     11d
statefulset.apps/c-db2ucluster-2-etcd   1/1     11d

NAME                                      COMPLETIONS   DURATION   AGE
job.batch/c-db2ucluster-2-instdb          1/1           16s        11d
job.batch/c-db2ucluster-2-restore-morph   1/1           11m        11d

Step4-8. 書き込み静止状態の解除

Snapshotを取得したタイミングでは、書き込み静止処理が行われた状態となっているため、これを解除します。
manage_snapshots --action restore コマンドの実行により以下のような操作が行われるようです。

  • RESTART DATABASE コマンドの実行
  • 書き込み静止状態の解除
  • データベース活動化
  • HAモニターの有効化

Db2uのエンジンのPod名を取得します

CATALOG_POD=$(oc get po -l name=dashmpp-head-0,app=${DB2U_CLUSTER} --no-headers | awk '{print $1}') ; echo ${CATALOG_POD}

c-db2ucluster-2-db2u-0

manage_snapshots --action restore コマンド実行します

date ; oc exec -it ${CATALOG_POD} -- manage_snapshots --action restore
2023年  2月 28日 火曜日 20:57:49 JST
Defaulted container "db2u" out of: db2u, init-labels (init), init-kernel (init)
/db2u/.db2u_initialized
WV is not running yet...sleep 30
WV is not running yet...sleep 30
*************************************************
Restart and activate the database(s)...this may take a while
Wolverine HA management state was disabled successfully.
DB20000I  The RESTART DATABASE command completed successfully.
activate db SAMPLEDB
SQL1493N  The command failed because the application is already connected to
an active database.

Database was activated successfully
connect to SAMPLEDB

   Database Connection Information

 Database server        = DB2/LINUXX8664 11.5.8.0
 SQL authorization ID   = DB2INST1
 Local database alias   = SAMPLEDB

terminate
DB20000I  The TERMINATE command completed successfully.

Successfully resumed writes and activated SAMPLEDB

*************************************************
Wolverine HA management state was enabled successfully.

※db2diag.logに下記メッセージが出力されます。

ADM6045I The database is no longer in the WRITE SUSPEND state.

Step4-9. メンテナンスモードの終了

リストア処理冒頭でメンテナンスモードに設定していたため、これを解除します。

date ; oc annotate db2ucluster $DB2U_CLUSTER db2u.databases.ibm.com/maintenance-pause-reconcile=true --overwrite
2023年  2月 28日 火曜日 21:38:55 JST
db2ucluster.db2u.databases.ibm.com/db2ucluster-2 annotated

Step5. リストア後のデータ内容確認

Snapshot取得前にINSERTしたデータのみ確認できました。
これは想定通りの結果で、Snapshot取得中(write suspend状態)やSnapshot取得後にINSERTした結果行のない状態に戻すことができました。

[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ db2 "select * from t1 order by c3"

C1          C2                               C3
----------- -------------------------------- --------------------------
          1 before snapshot                  2023-02-28-06.56.11.996187

  1 record(s) selected.

[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$

最後に

OpenShift Webコンソールを使うと、非常に簡単にSnapshotの取得・リストアができます。
Yamlを書いても同じことが出来ますが、コンソールを使うと、以下の項目は自動入力されユーザーが確認・判断を行う必要が無くなります。

  • Snapshot取得時

    • スナップショット名
    • スナップショットクラス
  • リストア時

    • アクセスモード
    • ボリュームモード(ファイルシステム or Block)
    • サイズ (Snapshot取得時点サイズが反映され、さらに増減の選択も可能)

このメリットは非常に大きくて、環境理解不足やコーディングのミスによる操作ミスを防ぎ、確実にSnapshotの取得、リストアを遂行することができるようになります。
ストレージの知識がなくても、安全確実しかも手軽にOpenShift環境のPVC Snapshotを取得できる、とても良いユーティリティでした。

memo

補足1:PVC削除に失敗した場合の解消手順

対象となるPVCをmountしているPodが稼働状態のままoc delete pvc コマンドを実行すると、PVC削除は完了せず、Terminatingステータスのまま残存してしまいます。
このような状態になっても、こちらの手順に従って解除した上でpvcを削除するとうまくいきます。
参考:Qiita記事: PersistentVolumeClaim (pvc)削除できず、Terminating ステータスのままとの問題

削除に失敗したPVCの状態を確認。pvc-protection となっている

root@IBM-PF2E8K5F:~/db2u/pvc# date ; oc describe pvc c-db2ucluster-2-meta | grep Finalizers
2023年  2月 28日 火曜日 20:37:35 JST
Finalizers:    [kubernetes.io/pvc-protection]

Protected状態を解除すると、PVC削除処理が再開される

date ; oc patch pvc c-db2ucluster-2-meta -p '{"metadata":{"finalizers": []}}' --type=merge
2023年  2月 28日 火曜日 20:37:44 JST
persistentvolumeclaim/c-db2ucluster-2-meta patched

削除が完了すると、get pvc コマンド出力からも消える

date ; oc get pvc | grep -i db2ucluster-2
2023年  2月 28日 火曜日 20:38:00 JST
root@IBM-PF2E8K5F:~/db2u/pvc#

補足2:書き込み静止/解除時の db2diag.log 出力

(1) Snapshot取得前の書き込み静止 (SET WRITE SUSPEND)

実行コマンド
oc exec -it c-db2ucluster-2-db2u-0 -- manage_snapshots --action suspend
db2diag.log
2023-02-28-07.00.31.460411+000 I477537E532           LEVEL: Info
PID     : 21363                TID : 140438413502208 PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000            DB   : SAMPLEDB
APPHDL  : 0-33295              APPID: *LOCAL.db2inst1.230228070031
AUTHID  : DB2INST1             HOSTNAME: c-db2ucluster-2-db2u-0
EDUID   : 51                   EDUNAME: db2agent (SAMPLEDB) 0
FUNCTION: DB2 UDB, base sys utilities, sqleSetWriteSuspend, probe:4596
DATA #1 : <preformatted>
Set Write Suspend issued from member 0

2023-02-28-07.00.31.606775+000 I478070E561           LEVEL: Warning
PID     : 21363                TID : 140438413502208 PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000            DB   : SAMPLEDB
APPHDL  : 0-33295              APPID: *LOCAL.db2inst1.230228070031
AUTHID  : DB2INST1             HOSTNAME: c-db2ucluster-2-db2u-0
EDUID   : 51                   EDUNAME: db2agent (SAMPLEDB) 0
FUNCTION: DB2 UDB, data protection services, sqlpSuspendLog, probe:205
DATA #1 : <preformatted>
LSO at suspend time is 395588553. Log file at suspend time is 15

2023-02-28-07.00.31.608307+000 I478632E547           LEVEL: Info
PID     : 21363                TID : 140438413502208 PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000            DB   : SAMPLEDB
APPHDL  : 0-33295              APPID: *LOCAL.db2inst1.230228070031
AUTHID  : DB2INST1             HOSTNAME: c-db2ucluster-2-db2u-0
EDUID   : 51                   EDUNAME: db2agent (SAMPLEDB) 0
FUNCTION: DB2 UDB, data protection services, sqlpSuspendLog, probe:205
DATA #1 : <preformatted>
LSO/LSN at suspend time is 395588553/0000000000161F5F

2023-02-28-07.00.31.632810+000 E479180E588           LEVEL: Warning
PID     : 21363                TID : 140438413502208 PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000            DB   : SAMPLEDB
APPHDL  : 0-33295              APPID: *LOCAL.db2inst1.230228070031
AUTHID  : DB2INST1             HOSTNAME: c-db2ucluster-2-db2u-0
EDUID   : 51                   EDUNAME: db2agent (SAMPLEDB) 0
FUNCTION: DB2 UDB, base sys utilities, sqleSetWriteSuspend, probe:5300
MESSAGE : ADM6075W  The database has been placed in the WRITE SUSPENDED state.
          Database name: "SAMPLEDB".

2023-02-28-07.00.32.094343+000 E479769E445           LEVEL: Info
PID     : 21363                TID : 140438509971200 PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000            DB   : SAMPLEDB
HOSTNAME: c-db2ucluster-2-db2u-0
EDUID   : 27                   EDUNAME: db2logmgr (SAMPLEDB) 0
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3108
DATA #1 : <preformatted>
Started archive for log file S0000015.LOG.

2023-02-28-07.00.32.096411+000 E480215E441           LEVEL: Info
PID     : 21363                TID : 140438509971200 PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000            DB   : SAMPLEDB
HOSTNAME: c-db2ucluster-2-db2u-0
EDUID   : 27                   EDUNAME: db2logmgr (SAMPLEDB) 0
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3109
MESSAGE : ADM1844I  Started archive for log file "S0000015.LOG"

2023-02-28-07.00.32.247631+000 I480657E606           LEVEL: Info
PID     : 21363                TID : 140438509971200 PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000            DB   : SAMPLEDB
HOSTNAME: c-db2ucluster-2-db2u-0
EDUID   : 27                   EDUNAME: db2logmgr (SAMPLEDB) 0
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3180
DATA #1 : <preformatted>
Completed archive for log file S0000015.LOG to /mnt/bludata0/db2/archive_log/db2inst1/SAMPLEDB/NODE0000/LOGSTREAM0000/C0000000/ from /mnt/blumeta0/db2/databases/db2inst1/NODE0000/SQL00001/LOGSTREAM0000/.

2023-02-28-07.00.32.249554+000 E481264E651           LEVEL: Info
PID     : 21363                TID : 140438509971200 PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000            DB   : SAMPLEDB
HOSTNAME: c-db2ucluster-2-db2u-0
EDUID   : 27                   EDUNAME: db2logmgr (SAMPLEDB) 0
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3175
MESSAGE : ADM1846I  Completed archive for log file "S0000015.LOG" to
          "/mnt/bludata0/db2/archive_log/db2inst1/SAMPLEDB/NODE0000/LOGSTREAM00
          00/C0000000/" from
          "/mnt/blumeta0/db2/databases/db2inst1/NODE0000/SQL00001/LOGSTREAM0000
          /".

2023-02-28-07.03.47.839876+000 E481916E803           LEVEL: Warning
PID     : 21363                TID : 140438522554112 PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000            DB   :
APPHDL  : 0-33296              APPID: *LOCAL.db2inst1.230228070347
AUTHID  : DB2INST1             HOSTNAME: c-db2ucluster-2-db2u-0
EDUID   : 24                   EDUNAME: db2agent (instance) 0
FUNCTION: DB2 UDB, database monitor, sqm___sqlmonssagnt, probe:14
DATA #1 : <preformatted>

This occurs when snapshot is run on a database iswrite suspended.
Due to latching contention, we will obtain minimal snapshot info for
the current database 'SAMPLEDB'. We will process other databases normally.

For more information on write suspend, please see the
'db2 set write suspend for database' command.

(2) Snapshotリストア後の書き込み静止解除 (SET WRITE RESUME)

実行コマンド
oc exec -it c-db2ucluster-2-db2u-0 -- manage_snapshots --action restore
db2diag.log
2023-02-28-11.59.00.782641+000 E688288E587           LEVEL: Info
PID     : 2716                 TID : 140344624670464 PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000            DB   : SAMPLEDB
APPHDL  : 0-30                 APPID: *LOCAL.db2inst1.230228115900
AUTHID  : DB2INST1             HOSTNAME: c-db2ucluster-2-db2u-0
EDUID   : 24                   EDUNAME: db2agent (SAMPLEDB) 0
FUNCTION: DB2 UDB, base sys utilities, sqleDoRestartDBWriteResume, probe:2777
MESSAGE : ADM6045I  The database is no longer in the WRITE SUSPEND state.
          Database name: "SAMPLEDB".

補足3:Step4-3.で出力されたYaml

(1) メタデータ用PVC

c-db2ucluster-2-meta_copy.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    formation_id: db2ucluster-2
    pv.kubernetes.io/bind-completed: "yes"
    pv.kubernetes.io/bound-by-controller: "yes"
    storageConfigType: create
    volume.beta.kubernetes.io/storage-provisioner: openshift-storage.cephfs.csi.ceph.com
    volume.kubernetes.io/storage-provisioner: openshift-storage.cephfs.csi.ceph.com
  creationTimestamp: "2023-02-17T10:50:48Z"
  finalizers:
  - kubernetes.io/pvc-protection
  labels:
    app: db2ucluster-2
    formation_id: db2ucluster-2
  name: c-db2ucluster-2-meta
  namespace: db2u-1
  ownerReferences:
  - apiVersion: db2u.databases.ibm.com/v1
    controller: true
    kind: Formation
    name: db2ucluster-2
    uid: f4bf8c75-5986-497a-bf72-3b0610b52ecb
  resourceVersion: "75175063"
  uid: d2b126cc-a486-419b-b239-39c4e90b2ea6
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: ocs-storagecluster-cephfs
  volumeMode: Filesystem
  volumeName: pvc-d2b126cc-a486-419b-b239-39c4e90b2ea6
status:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 10Gi
  phase: Bound

(2) データ用PVC

data-c-db2ucluster-2-db2u-0_copy.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    formation_id: db2ucluster-2
    pv.kubernetes.io/bind-completed: "yes"
    pv.kubernetes.io/bound-by-controller: "yes"
    storageConfigType: template
    volume.beta.kubernetes.io/storage-provisioner: openshift-storage.rbd.csi.ceph.com
    volume.kubernetes.io/storage-provisioner: openshift-storage.rbd.csi.ceph.com
  creationTimestamp: "2023-02-17T10:51:32Z"
  finalizers:
  - kubernetes.io/pvc-protection
  labels:
    app: db2ucluster-2
    component: db2oltp
    formation_id: db2ucluster-2
    role: db
    type: engine
  name: data-c-db2ucluster-2-db2u-0
  namespace: db2u-1
  ownerReferences:
  - apiVersion: db2u.databases.ibm.com/v1
    kind: Formation
    name: db2ucluster-2
    uid: f4bf8c75-5986-497a-bf72-3b0610b52ecb
  resourceVersion: "74786853"
  uid: 5c9cd839-470e-47bc-b6e3-190520325572
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: ocs-storagecluster-ceph-rbd
  volumeMode: Filesystem
  volumeName: pvc-5c9cd839-470e-47bc-b6e3-190520325572
status:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 10Gi
  phase: Bound
3
0
1

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
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?