概要
Db2 on OpenShift バックアップ・リストアを試してみました。
サマリー：
- 2021/04現在、Db2 on OpenShift のバックアップをサービス無停止で取得できる方法は、Db2 BACKUP DATABASE コマンドのみ
- Db2 11.5.5-cn2 時点では Operator によるバックアップ取得機能は未提供
- OCS(OpenShift Container Storage) のスナップショット取得には、対象となるPodの停止が必要となる
- ここでは、Db2 on OpenShift 環境で、Db2 BACKUP DATABASE / RESTORE コマンドによるリストアが可能であることと手順、考慮点を把握する目的で実機検証を行う
奇しくも、OpenShift(Kubernetes)環境が不安定な状態でバックアップ、リストア、ロールフォワードをフォアグラウンドで実行するとどういった状態となるかが確認できた
-
以下は2021.12加筆：
- Db2 on OpenShift マニュアルのバックアップ・リストアのページに以下の加筆あり
- Persistent Volume のバックアップを取得する運用方針も選択可能
- Db2 on OpenShift マニュアルのバックアップ・リストアのページに以下の加筆あり
Note: You can also back up and restore persistent volumes in the Red Hat® OpenShift® project (namespace) where the Db2 service is installed. For information, see Backing up and restoring your project.
参考：Db2マニュアル[Backing up and restoring Db2]
結果
- オンプレミスの環境同様、Db2 BACKUPコマンドによりオンライン状態でバックアップを取得し、DBをリストアすることができた(これは当たり前ですね)
- フォアグラウンド実行したコマンドの応答が戻らないくらい不安定な状態であっても、バックアップ / リストア / ロールフォワードは成功
- 今回の環境は単純なリソース不足で、時間はかかるものの待てば完了できる状態だったという話で、例えばストレージ障害が起きていて書き込みができないような環境ではこの限りではありません
Lessons & Learned：
- 基本的にはオンプレミス環境と同じ手順で実施できる。作業フローにおける大きな違いは、リストア時に Db2 on OpenShift に同梱される HAモニタリングソフト(Wolverine high availability monitoring process) の停止・起動を行う必要がある点
- バックアップ、リストア、ロールフォワードの各コマンドをバックグラウンドでの実行とし、いずれも標準出力を後から確認できるようファイルにリダイレクトしておくなど、状況確認ができる手段は1つでも多く確保しておきたい
例) db2 backup db ${DB_NAME} online to \${DB_BKUP_DIR} include logs without prompting > bkup_`date "+%Y%m%d_%H%M%S"`.log 2>&1 &
環境：
今回利用した環境は以下の通りで、こちらの手順(->Link)で構築したものです。
- OpenShift Container Platform (OCP) V4.6.19
- OpenShift Container Storage (OCS) V4.6.3
- Db2 on OpenShift V11.5.5.0-cn2 (Db2 Operator V1.0.3)
ここから先では、バックアップとリストア、それぞれの手順(検証ログ)を残します。
補足：
- 今回はあくまで機能検証ですので、Db2 Pod(コンテナ)内のローカル・ディレクトリー上にバックアップ・イメージを出力する手順としています
- 厳密にデータ保全を考えるなら、取得したバックアップ・イメージを他ロケーションに oc cp (kubectl cp) コマンドでローカルに移動させるか、BACKUPコマンドのバックアップ・イメージ出力先をオブジェクトストレージにするなど、検討することになるかと思います
バックアップ取得手順
下記マニュアルに沿って、Db2オンライン・バックアップを取得します。
https://www.ibm.com/docs/en/db2/11.5?topic=up-online-backup
Step1. oc login ~ Pod へのログイン
Db2 Operator / Db2uCluster(CR) がDeployされているワークスペースにログインします。
[user1@k3bastion ~]$ oc login -u ser1 -p xxxxx --server=https://api.isvsol.jp-ise.com:6443
Login successful.
You have access to 66 projects, the list has been suppressed. You can list all projects with ' projects'
Using project "db2u-ocs1".
[user1@k3bastion ~]$ oc get pods -n db2u-ocs1 | grep db2u
c-db2ucluster-ocs1-db2u-0 1/1 Running 0 20d
c-db2ucluster-ocs1-etcd-0 1/1 Running 0 20d
c-db2ucluster-ocs1-instdb-ckt77 0/1 Completed 0 20d
c-db2ucluster-ocs1-ldap-7dfc5c6968-lv4vw 1/1 Running 0 20d
c-db2ucluster-ocs1-restore-morph-kzqg5 0/1 Completed 0 20d
c-db2ucluster-ocs1-tools-756dcd89b5-nhp24 1/1 Running 0 20d
db2u-operator-manager-5c8d59f5db-ckl5g 0/1 CrashLoopBackOff 1660 20d
[ser1@k3bastion ~]$
[user1@k3bastion ~]$ oc rsh c-db2ucluster-ocs1-db2u-0 /bin/bash
[db2uadm@c-db2ucluster-ocs1-db2u-0 /]$
Step2. バックアップ事前準備
カタログノードにログインし、インスタンスオーナー db2inst1 にスイッチユーザし、バックアップイメージ配置用ディレクトリを作成します。
バックアップイメージを配置するディレクトリとして、コンテナが稼働するノード間で共有されるディレクトリを作成します。
su - db2inst1
DB_NAME=SAMPLEDB
DB_BKUP_DIR="/mnt/blumeta0/db2/backup/sampledb_001"
mkdir ${DB_BKUP_DIR}
Step3. バックアップ前のデータを確認
DBに接続します。
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ DB_NAME=SAMPLEDB
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ db2 connect to $DB_NAME
Database Connection Information
Database server = DB2/LINUXX8664 11.5.5.0
SQL authorization ID = DB2INST1
Local database alias = SAMPLEDB
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$
テスト用テーブルに格納されたデータの内容を確認しておきます
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ db2 "select * from t1"
C1 C2
----------- --------------------------------------------------------------------------------------------------------------------------------
1 A
2 B
3 C
3 record(s) selected.
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$
パーティション数も確認：
db2 LIST DBPARTITIONNUMS
---> 1パーティションの環境であることが確認できました
Step4. オンラインバックアップ取得
4-1. バックアップ取得
オンライン・バックアップ取得コマンドは下記の通り。
- シングルパーティションDBの場合
- db2 backup db \${DB_NAME} online to \${DB_BKUP_DIR} include logs without prompting
- 複数パーティションDBの場合
- db2 backup db \${DB_NAME} on all dbpartitionnums online to \${DB_BKUP_DIR} include logs without prompting
今回はシングルパーティション環境で、以下のコマンドにより取得。
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U backup]$ db2 backup db ${DB_NAME} online to ${DB_BKUP_DIR} include logs without prompting
---> 上記コマンド実行後、数秒でDb2 Podのプロンプトが落ちて、ログイン元のbastionノードに制御が戻される
4-2. バックアップ進行状況の確認
環境によって、リソースの搭載状況や他Podからの利用状況により、OCPクラスタ全体が不安定になることが時折あります。
そのあおりを受けてOCPの認証系Podが不安定になっている状態だと、すぐにログイン済Podからログアウトさせられてしまうこともあります。
今回は、そういったタイミングとDb2バックアップ取得が折悪く重なってしまい、バックアップコマンドは実行出来たものの即ログアウトさせられ、果たしてさっき取得したバックアップはどうなったかわからない！という状況になりました。
こういった状況下では、db2 list utilities コマンドが有用です。
BACKUP , RESTORE 等現在Db2として実行中のユーティリティの進行状況を確認することができます。
確認(バックアップ進行中)
[user1@k3bastion ~]$ oc rsh c-db2ucluster-ocs1-db2u-0 /bin/bash
[db2uadm@c-db2ucluster-ocs1-db2u-0 /]$su - db2inst1
Last login: Mon Mar 29 08:14:42 UTC 2021 on pts/7
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ db2 list utilities
ID = 130
Type = BACKUP
Database Name = SAMPLEDB
Member Number = 0
Description = online db
Start Time = 03/29/2021 08:14:27.494459
State = Executing
Invocation Type = User
Throttling:
Priority = Unthrottled
Progress Monitoring:
Estimated Percentage Complete = 46
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$
---> プロンプトは落ちても、オンラインバックアップ取得自体は正常に進んでいるように見える
---> list utilitities コマンドの応答が戻ってすぐまたプロンプトが落ちてbastionノードに戻される
確認(完了後)
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ db2 list utilities
SQL1611W No data was returned by Database System Monitor. SQLSTATE=00000
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$
---> 実行中のバックアップ処理はない (バックアップ取得処理は完了している状態と推測される)
4-3. バックアップイメージが正常に取得できているかを確認
- ls コマンドによるファイルの存在確認
- db2ckbkp コマンドによる、Db2バックアップファイルとしての妥当性確認
を行います。
ls コマンド：
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ ls -ltr
total 557224
-rw-------. 1 db2inst1 db2iadm1 570597376 Mar 29 08:17 SAMPLEDB.0.db2inst1.DBPART000.20210329081425.001
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$
---> バックアップイメージは作成されている
db2ckbkp コマンド：
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ db2ckbkp SAMPLEDB.0.db2inst1.DBPART000.20210329081425.001
[1] Buffers processed: ###################################
Image Verification Complete - successful.
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$
---> バックアップの検査コマンドで確認する限り、問題なく取得できている
上記の通り、BACKUP実行コマンドの応答が戻る前にPodとのセッションが強制終了された場合もバックアップ取得自体は正常に完了することがわかりました。
ですが、こんなの怖いので、今後はバックグラウンド実行とします！
(とはいえ、どうなるのかにも興味はあり、後続のリストア、ロールフォワードはフォアグラウンドで実行してみます)
リストア
下記マニュアルに沿って、Db2オンライン・バックアップをリストアします。
https://www.ibm.com/docs/en/db2/11.5?topic=restoring-online-backup
* リストア操作は、オフラインで実行します。(バックアップ・イメージ取得はオンライン状態で行うことができますが、リストア時にはオフラインとする必要があります)
Step1. データ行の削除
「削除してしまったデータが、後に行うリストアによって復元できた」ことを確認するため、バックアップ取得後、データの1行を削除しておく。
データ削除：
(もともと3行入っていた行データのうち、1行を削除)
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ db2 "select * from t1"
C1 C2
----------- --------------------------------------------------------------------------------------------------------------------------------
1 A
2 B
3 C
3 record(s) selected.
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ db2 "delete from t1 where c2='C'"
DB20000I The SQL command completed successfully.
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ db2 "select * from t1"
C1 C2
----------- --------------------------------------------------------------------------------------------------------------------------------
1 A
2 B
2 record(s) selected.
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$
Step2 . バックアップ・イメージのタイムスタンプの確認
リストアコマンドにオプションとして指定するため、バックアップファイルファイル名のタイムスタンプ部分を確認しておきます。
[user1@k3bastion ~]$ oc rsh c-db2ucluster-ocs1-db2u-0 /bin/bash
[db2uadm@c-db2ucluster-ocs1-db2u-0 /]$ su - db2inst1
Last login: Mon Mar 29 09:42:20 UTC 2021 on pts/2
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ DB_BKUP_DIR="/mnt/blumeta0/db2/backup/sampledb_001"
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ DB_NAME=SAMPLEDB
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ cd ${DB_BKUP_DIR}
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ ls -ltr ${DB_NAME}*
-rw-------. 1 db2inst1 db2iadm1 570597376 Mar 29 08:17 SAMPLEDB.0.db2inst1.DBPART000.20210329081425.001
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ BKUP_TIMESTAMP=20210329081425
Step3. Db2 on OpenShift 内のHAモニタリングソフトの無効化
built-in HA(Wolverine high availability monitoring process) を一時的に無効化しておく
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ sudo wvcli system disable -m "Disable HA before Db2 maintenance"
Wolverine HA management state was disabled successfully.
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$
Step4. 残存するデータベース接続の切断
4-1. アプリケーションの残存状況を確認する
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ db2 list applications
Auth Id Application Appl. Application Id DB # of
Name Handle Name Agents
-------- -------------- ---------- -------------------------------------------------------------- -------- -----
DB2INST1 db2bp 3749 *LOCAL.db2inst1.210430070145 SAMPLEDB 1
DB2INST1 db2bp 1270 *LOCAL.db2inst1.210423111217 SAMPLEDB 1
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$
4-2. 残存する接続を強制終了させる
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ db2 force application all
DB20000I The FORCE APPLICATION command completed successfully.
DB21024I This command is asynchronous and may not be effective immediately.
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$
4-3. 接続が残っていない状態であることを確認
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ db2 list applications
SQL1611W No data was returned by Database System Monitor.
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$
Step5. データベースを非活動化する
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ db2 deactivate db ${DB_NAME}
DB20000I The DEACTIVATE DATABASE command completed successfully.
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$
Step6. データベースを停止させる
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ db2stop force
03/29/2021 09:43:43 0 0 SQL1064N DB2STOP processing was successful.
SQL1064N DB2STOP processing was successful.
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$
Step7. ipcleanコマンドにより、IPC通信のための残存オブジェクトをクリーンアップする
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ ipclean -a
Application ipclean: Removing all IPC resources for db2inst1(500)
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$
Step8. 外部からの接続を受け付けないようDB2COMMレジストリ変数を変更する
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ db2set -null DB2COMM
Null値が設定されたことを確認：
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ db2set -all | grep DB2COMM
[i] DB2COMM=NULL
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$
Step9. Db2を制限アクセスモードで起動する
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ db2start admin mode restricted access
03/29/2021 09:44:40 0 0 SQL1063N DB2START processing was successful.
SQL1063N DB2START processing was successful.
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$
Step10. リストア
10-1. リストアコマンドの実行
- リストア・コマンド
- db2 RESTORE DATABASE \${DB_NAME} FROM \${DB_BKUP_DIR} TAKEN AT \${BKUP_TIMESTAMP} INTO \${DB_NAME} REPLACE EXISTING
- 補足：マニュアルの記載はこちら(↓)ですが、オンラインバックアップのリストアには指定できないオプションが含まれるため、実際これではエラーになります。
db2 RESTORE DATABASE \${DB_NAME} FROM \${DB_BKUP_DIR} TAKEN AT \${BKUP_TIMESTAMP} INTO \${DB_NAME} REPLACE EXISTING WITHOUT ROLLING FORWARD
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ db2 RESTORE DATABASE ${DB_NAME} FROM ${DB_BKUP_DIR} TAKEN AT ${BKUP_TIMESTAMP} INTO ${DB_NAME} REPLACE EXISTING
SQL2539W The specified name of the backup image to restore is the same as the
name of the target database. Restoring to an existing database that is the
same as the backup image database will cause the current database to be
overwritten by the backup version.
10-2. リストアコマンドの進行状況の確認
リストア処理が実行されている間は、バックアップ同様、db2 list utilities コマンドで進行状況を確認することができます。
どのDBに対するリストア処理がいつ開始されたものかがわかります。
確認(リストア進行中)：
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ db2 list utilities
ID = 3
Type = RESTORE
Database Name = SAMPLEDB
Member Number = 0
Description = db
Start Time = 03/30/2021 06:15:23.866009
State = Executing
Invocation Type = User
確認(完了後)：
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ db2 list utilities
SQL1611W No data was returned by Database System Monitor. SQLSTATE=00000
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$
Step11. ロールフォワード
オンライン・バックアップをリストアした後はロールフォワードを行う必要があります。
Db2のオンライン・バックアップ・イメージにはデフォルトでバックアップ取得時点までロールフォワードを行うためのログが含まれます。
11-1. ロールフォワードコマンドの実行
- ロールフォワード・コマンド
- (シングル環境) db2 rollforward db ${DB_NAME} to end of backup and stop
- (マルチDB環境) db2 rollforward db ${DB_NAME} to end of backup on all dbpartitionnums and stop
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ db2 rollforward database sampledb to end of backup and stop
---> 不安定な環境だったため、rollforward database コマンドの応答を待たず Db2 Pod のセッションが切断されてしまう
---> 追ってDb2 Podに再ログインし、ロールフォワードの進行状況を確認する
11-2. ロールフォワードコマンドの進行状況の確認
確認(ロールフォワード進行中)：
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ db2 list utilities
ID = 1
Type = ROLLFORWARD RECOVERY
Database Name = SAMPLEDB
Member Number = 0
Description = Database Rollforward Recovery
Start Time = 03/30/2021 08:37:25.862631
State = Executing
Invocation Type = User
Progress Monitoring:
Estimated Percentage Complete = 92
確認(完了後)：
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ db2 list utilities
SQL1611W No data was returned by Database System Monitor. SQLSTATE=00000
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$
Step12. Db2を停止する
実行するコマンド：
db2stop force
ipclean -a
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ db2stop force
03/30/2021 09:34:52 0 0 SQL1064N DB2STOP processing was successful.
SQL1064N DB2STOP processing was successful.
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ ipclean -a
Application ipclean: Removing all IPC resources for db2inst1(500)
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$
Step13. DB2COMMレジストリ変数を元の設定値(TCPIP,SSL)に戻す
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ db2set DB2COMM=TCPIP,SSL
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$
想定通り設定が戻っていることを確認
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ db2set DB2COMM
TCPIP,SSL
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$
Step14. Db2を通常起動する
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ db2start
03/30/2021 09:35:46 0 0 SQL1063N DB2START processing was successful.
SQL1063N DB2START processing was successful.
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$
Step15. DBの活動化を行う
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ db2 activate database ${DB_NAME}
DB20000I The ACTIVATE DATABASE command completed successfully.
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$
Step16. build-in HA (Wolverine high availability monitoring process)を再度有効化する
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$ wvcli system enable -m "Enable HA after Db2 maintenance"
Wolverine HA management state was enabled successfully.
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U db2inst1]$
Step17. Db2に接続する
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ db2 connect to ${DB_NAME}
Database Connection Information
Database server = DB2/LINUXX8664 11.5.5.0
SQL authorization ID = DB2INST1
Local database alias = SAMPLEDB
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$
Step18. データを確認する
リストアのStep1. (バックアップ後 / リストア前) に削除したレコード(c2列=2) が、リストアにより復元していることを確認する
db2 "select * from t1"
---> リストア直前に削除した「c1=2」の列が存在することを確認
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$ db2 "select * from t1"
C1 C2
----------- --------------------------------------------------------------------------------------------------------------------------------
1 A
2 B
3 C
3 record(s) selected.
[db2inst1@c-db2ucluster-ocs1-db2u-0 - Db2U sampledb_001]$
---> Backup取得後に削除した行データがリストアにより復元されたことを確認できた
参考
(以上)