試したこと
- HADRとは何か、図や表に整理して理解する(ことを試みる)
- 2台構成HADR環境をIaaS環境に構築
- 導入時の実行コマンド、標準出力ログを備忘録として記録
HADRとは
- Db2高可用性構成の主要パターンの1つ 【アクティブ・ホットスタンバイ構成】
- ホット・スタンバイ(＝スタンバイはDb2起動済の状態で待機している)のため、プライマリーDB障害時には速やかにスタンバイDBへ切り替えることができる
-
プライマリーDBに更新処理を行うと、書き出されたトランザクションログがスタンバイDBにバックエンドで転送・自動適用され、ほぼリアルタイムにデータの同期が取られている仕組み
-
距離の制約がないため、同一サイト内での冗長構成だけでなく、リモートサイトとの間で災対構成を組む用途でも利用可能
-
プライマリーDBとスタンバイDBの間ではハートビート通信が行われ、お互いの役割を認識している
- ただし自動的に役割を変更する機能はなく、スタンバイDBをプライマリーDBに昇格させるにはTAKEOVER HADRコマンドを実行する必要がある
- 障害検知～TAKEOVERを自動化するには、Pacemaker, TSA, PowerHA, LifeKeeper, CLUSTERPROなどのクラスターソフトウェアをあわせて使用する
セカンダリーデータベースを読取用途で利用する(読取専用スタンバイ)、スタンバイデータベースを複数サイトに構築する(マルチスタンバイ)など、応用構成パターンもありますが、ここではもっともベーシックな2台構成のHADR環境を構築します。
HADR 同期モード
HADRで重要な設計要素として、どの同期モードが最適か、考える必要があります。
HADRはログ転送によってクライアント・アプリケーションからの更新処理をプライマリーDB→スタンバイDBへと伝搬する仕組みですが、もし仮に、2つのデータベースを両方とも更新完了するまで待機しなくてはならない仕組みであるなら、単純計算で1つのDBの更新を行う時間の2倍、かかってしまいそうです。
さらに、プライマリーとスタンバイの両方の更新完了を以ってトランザクション完了と見なす場合、どちらかのデータベースが何らかの理由でアクセスできない状況の場合に応答が戻らなくなってしまい、可用性を高める仕組みのはずが、却って可用性が下がる可能性があります。
いくら冗長性を上げたくても、そこまでの負荷と待機時間発生リスクを許容することはなかなかできません。
そこで、HADRの同期モードは以下の4種類が提供され、トランザクションを保護する度合いとパフォーマンス要件の兼ね合いから、どの同期モードが望ましいか、アプリケーションの要件から判断し選択することができます。
| 同期モード | 備考 | |
|---|---|---|
| 1 | SYNC(同期) | ・プライマリDBのログファイルに加え、ログがスタンバイDBのログファイルにも書き込まれたことの確認通知をプライマリーDBが受信したらログ書き込み成功(コミット済)とみなされる ・トランザクション応答時間は最長 |
| 2 | NEARSYNC (近似同期/準同期) *デフォルト |
・プライマリDBのログファイルに加え、スタンバイDB上のメイン・メモリーにもログが書き込まれたことの確認通知をプライマリDBが受信したら、ログ書き込み成功(コミット済) |
| 3 | ASYNC(非同期) | ・プライマリDBのログファイルに加え、プライマリDBのTCPレイヤーに送信されたら、ログ書き込み成功(コミット済) ・スタンバイDBの確認通知を待たない |
| 4 | SUPER ASYNC (超非同期) |
・プライマリDBのログファイルにログ・レコードが書き込まれた時点で、ログ書き込み成功(コミット済) ・HADR ペアがピア状態および切断ピア状態になることがないモード |
今回は、多くの環境に適するデフォルトのNEARSYNCモードを選択します。
環境
- Db2が既にインストールされた環境に、追加でHADRのデータベースを1セット構成する
- IBM Cloud (IaaS)
- Red Hat Enterprise Linux release 8.8 (Ootpa)
- Db2 11.5.9
- HADR2台構成
作業の流れ
以下の手順を実行します。
| Step | 手順 | 対象サーバ | 実行ユーザ |
|---|---|---|---|
| 1 | OSの構成 | 1号機、2号機 | root |
| 2 | Db2インスタンス作成 | 1号機、2号機 | (db2 instance user) |
| 3 | Db2インスタンス起動 | 1号機、2号機 | 同上 |
| 4 | Db2データベース作成 | 1号機 | 同上 |
| 5 | アーカイブ・ロギングの構成 | 1号機 | 同上 |
| 6 | 索引ロギング/索引再作成 を有効化 | 1号機 | 同上 |
| 7 | DBバックアップ取得 | 1号機 | 同上 |
| 8 | DBバックアップ転送 | 1号機→2号機 | N/A |
| 9 | プライマリーDBのバックアップからのリストア | 2号機 | (db2 instance user) |
| 10 | HADR通信用のOS設定 | 1号機、2号機 | root |
| 11 | HADRのためのDB構成パラメーターの設定 | 1号機、2号機 | (db2 instance user) |
| 12 | HADRサービスの開始 | 2号機 | 同上 |
| 13 | HADRサービスの開始 | 1号機 | 同上 |
※ この手順メモ内では、Db2 instance user名は uk1159 となります
セットアップ作業ログ
Step1. OSの構成(ユーザー, グループ, ディレクトリ作成) (1号機, 2号機)
Step1-1. OSグループ作成
HADR用のDb2インスタンスユーザーが属するOSグループを作成します。
groupadd -g 2031 ukigrp1
※必要に応じて、Fencedユーザー用グループを作成(今回は作成済の環境のため省略)
Step1-2. OSユーザー作成
Db2インスタンスユーザーとなるOSユーザーを作成します。
useradd -g ukigrp1 -u 2031 uk1159
※HADRのインスタンスユーザーは異なっていても問題ないようですが、同名のほうがわかりやすいため1,2号機とも同じユーザーとします。
※必要に応じて、Fencedユーザーを作成(今回は作成済の環境のため省略)
Step1-3. OSユーザーパスワード変更
Step1-2.で作成したユーザーのパスワードを設定します。
passwd uk1159
Step1-4. データ/ログ配置用ディレクトリー作成
デフォルトでは/homeに配置されますが、データやログが増えて/homeが100%到達してしまうとログインできなくなるなど悲惨な状況になるため、サイズが増えそうなものは/homeとは別のファイルシステムに配置するほうが望ましい。今回は以下ディレクトリを作成し利用します
mkdir /data/uk1159
所有者をDb2インスタンスオーナーに変更
chown uk1159:ukigrp1 /data/uk1159
以下、用途別のサブディレクトリを作成しておきます
自動ストレージパス用サブディレクトリ：
mkdir /data/uk1159/stopath
DBPATH用サブディレクトリ：
mkdir /data/uk1159/dbpath
アクティブログパス用サブディレクトリ：
mkdir /data/uk1159/actlog
アーカイブログ用サブディレクトリ：
mkdir /data/uk1159/arclog
Step2. Db2インスタンス作成 (1号機, 2号機)
Db2インスタンスを作成します。
[root@host-1 home]# /opt/ibm/db2/V11.5.9/instance/db2icrt -u db2fenc1 uk1159
DBI1446I db2icrt コマンドの実行中です。
DB2 インストールを初期化しています。
実行されるタスクの合計数: 4
実行される全タスクの合計見積もり時間: 309 秒
タスク #1 を開始します。
説明: デフォルト・グローバル・プロファイル・レジストリー変数の設定
見積もり時間 1 秒
タスク #1 が終了しました。
タスク #2 を開始します。
説明: インスタンス・リストの初期化
見積もり時間 5 秒
タスク #2 が終了しました。
タスク #3 を開始します。
説明: DB2 インスタンスの構成
見積もり時間 300 秒
タスク #3 が終了しました。
タスク #4 を開始します。
説明: グローバル・プロファイル・レジストリーの更新
見積もり時間 3 秒
タスク #4 が終了しました。
正常に実行が完了しました。
詳しくは、「/tmp/db2icrt.log.2285856」にある DB2
インストール・ログを参照してください。
DBI1070I プログラム db2icrt は正常に完了しました。
[root@host-1 home]#
Db2インスタンスが作成されたことを確認します。
[root@host-1 home]# /opt/ibm/db2/V11.5.9/instance/db2ilist
uk1159
Step3. Db2インスタンス起動 (1号機、2号機)
ここから先の作業は、Db2インスタンスオーナーのユーザーにSwitchして操作します。
su - uk1159
Db2インスタンスを起動します。
[uk1159@host-1 ~]$ db2start
03/06/2024 19:07:25 0 0 SQL1063N DB2START の処理が正常に終了しました。
SQL1063N DB2START の処理が正常に終了しました。
[uk1159@host-1 ~]$
Step4. データベース作成 (1号機)
データベースを作成します
[uk1159@host-1 ~]$ db2 create database HADRDB ON /data/uk1159/stopath DBPATH ON /data/uk1159/dbpath USING CODESET UTF-8 TERRITORY JP
DB20000I CREATE DATABASE コマンドが正常に完了しました。
[uk1159@host-1 ~]$
データベースが作成されたことを確認します
[uk1159@host-1 ~]$ db2 list db directory
システム・データベース・ディレクトリー
ディレクトリー中の項目数 = 1
データベース 1 項目:
データベース別名 = HADRDB
データベース名 = HADRDB
ローカル・データベース・ディレクトリー = /data/uk1159/dbpath
データベース・リリース・レベル = 15.00
コメント =
ディレクトリー項目タイプ = 間接
カタログ・データベース・パーティション番号 = 0
代替サーバー・ホスト名 =
代替サーバーのポート番号 =
[uk1159@host-1 ~]$
Step5. アーカイブ・ロギング構成 (1号機)
Db2では2 つのタイプ (循環およびアーカイブ) のデータベース・ロギングがサポートされ、デフォルトは循環ロギングです。
HADRを構成する前提として、アーカイブロギング使用可能の構成に変更しておく必要があります。
DB構成パラメータ LOGARCHMETH1 にアーカイブログ出力先ディレクトリを定義することで、ロギング形式をアーカイブログに変更します。
また、必須ではないですが、/homeに極力ものを置かない方針としてアクティブログパスも一緒に変更します。
DB構成パラメータは、それぞれ db2 update db cfg コマンドで変更することができます。
db2 update db cfg for hadrdb using logarchmeth1 DISK:/data/uk1159/arclog
db2 update db cfg for hadrdb using newlogpath /data/uk1159/actlog
db2 terminate
db2stop
db2start
db2 backup database HADRDB to /data/uk1159/
db2 activate database HADRDB
ログの出力先が変更されたことを確認します。
[uk1159@host-1 ~]$ db2 get db cfg for HADRDB
(中略)
ログ・ファイルのパス = /data/uk1159/actlog/NODE0000/LOGSTREAM0000/
(中略)
第 1 ログ・アーカイブ・メソッド (LOGARCHMETH1) = DISK:/data/uk1159/arclog/
(以下略)
Step6. 索引ロギング/索引再作成 を有効化する (1号機)
HADR環境では以下パラメータの値を構成します。(デフォルトが推奨値である場合、変更不要)
| DB構成パラメータ | 製品デフォルト値 | HADR構成の場合の推奨 | 備考 ※HADRの観点のみ記載 |
|---|---|---|---|
| LOGINDEXBUILD | OFF | ON | 索引作成、再作成、および再編成のために完全な情報をログに記録させる設定。 このパラメータがOFFだと、ログに記録される情報が不完全なためにスタンバイシステムで索引にデータを追加できず、索引は無効状態としてマークされ、HADRテイクオーバー完了後に索引再作成を行う必要が生じる。ONに設定されると索引の作成、再作成、および再編成の実行中に各索引ページがログに記録される。 DB構成パラメータでなく、テーブルのLOG INDEX BUILD属性を指定することでも変更可能。 |
| INDEXREC | RESTART | RESTART | スタンバイ・データベースでのログ適用時に索引作成を再実行するかどうかを決める設定。 フル・ロギングで記録された索引作成は、ロールフォワードまたは HADR ログ適用の間に再実行される。 HADR が開始され、HADR のテークオーバーが行われると、テークオーバーの最後に無効な索引が再作成される。 |
変更コマンド：
db2 UPDATE DB CFG FOR HADRDB USING LOGINDEXBUILD ON
db2 deactivate db HADRDB
db2stop
db2start
db2 activate db HADRDB
参考：Db2 11.5マニュアル[索引ロギングおよび高可用性災害時リカバリー (HADR)]
Step7. バックアップ取得 (1号機)
2号機にスタンバイ・データベースを作成するため、1号機に作成したHADRDBデータベースのオフライン・データベース・フルバックアップを取得します。
db2 backup database HADRDB to /data/uk1159/
実行例：
[uk1159@host-1 ~]$ db2 deactivate database HADRDB
DB20000I DEACTIVATE DATABASE コマンドが正常に完了しました。
[uk1159@host-1 ~]$ db2 backup database HADRDB to /data/uk1159/
バックアップは成功しました。
このバックアップ・イメージのタイム・スタンプは
20240306203842 です。
[uk1159@host-1 ~]$
Step8. バックアップ転送 (1号機→2号機)
Step7.で取得したDBバックアップのイメージ(zip)ファイルを2号機に転送します。
sftpコマンド,WinSCPなどツールは何でも良いですがバイナリモードでの転送が必須です。
転送完了後、2号機でバックアップ・イメージ・ファイルが壊れていないか確認します。
[uk1159@host-2 uk1159]$ db2ckbkp ./HADRDB.0.uk1159.DBPART000.20240306203842.001
[1] Buffers processed: ############
Image Verification Complete - successful.
[uk1159@host-2 uk1159]$ echo $?
0
[uk1159@host-2 uk1159]$
問題なく転送できました(successful)
Step9. プライマリーDBのフル・バックアップ・イメージからのリストア (2号機)
HADRのスタンバイ・データベースを作成する方法はいくつかあるようですが、ここでは1号機で作成したプライマリー・データベースのバックアップ・イメージをリストアすることで、スタンバイ・データベースを作成します。
スタンバイ・データベースは、ロールフォワード・ペンディング状態とする必要があります。そのためロールフォワード不要 (without rolling forward) オプションを付与するのはNGです。
[uk1159@host-2 uk1159]$ db2 restore database HADRDB from /data/uk1159 taken at 20240306203842
DB20000I RESTORE DATABASE コマンドが正常に完了しました。
[uk1159@host-2 uk1159]$
Step10. HADR通信用のOS設定
HADR 1号機と2号機のDb2インスタンス間で通信を行うためには、相手サーバーの通信先のホスト名(IPアドレス)とサービス名(ポート番号) を相互に登録しておく必要があります。
Step10-11にて、OSとDb2双方に必要な構成情報を設定していきます。
IPアドレスとポート番号でDb2を構成することもできます。
その場合、Step10はスキップしてStep11に進みます。
まずはOS側の構成を行います。
Step10-1. 通信に利用するホスト名(IPアドレス)の設定
1号機、2号機 共通の内容でOKです。
10.0.0.1 host-1
10.0.0.2 host-2
補足: DNSサーバが構成される環境ではhostsファイルへの登録は不要です。
Step10-2. 通信に利用するサービス名(ポート番号)の設定
Db2のインスタンスを作成すると、FCM通信用とクライアントからの接続を受け付けるための通信用ポートが /etc/servicesファイルに自動的に登録されます。
しかしHADRノード間通信用ポートはデフォルトでは登録されないため、手動で /etc/services ファイルを編集し、エントリーを追加します。
ファイル編集前に、利用しようとしているポート番号が他サービスによって使用済でないこと(重複がないこと)を確認します。
確認方法としては、以下のような方法があります。
- /etc/servicesファイルの確認
- netstat -an コマンドを実行し、実際にlistenされていないか確認
追記内容は1号機、2号機 共通の内容でOKです。
DB2HADR_P_uk1159 25017/tcp #PrimaryノードHADR通信用
DB2HADR_S_uk1159 25018/tcp #StandbyノードHADR通信用
追記後のイメージとしては以下のようになります。
1号機
DB2_uk1159 20022/tcp
DB2_uk1159_1 20023/tcp
DB2_uk1159_2 20024/tcp
DB2_uk1159_3 20025/tcp
DB2_uk1159_4 20026/tcp
DB2_uk1159_END 20027/tcp
db2c_uk1159 25011/tcp
DB2HADR_P_uk1159 25017/tcp #PrimaryノードHADR通信用
DB2HADR_S_uk1159 25018/tcp #StandbyノードHADR通信用
2号機
DB2_uk1159 20071/tcp
DB2_uk1159_1 20072/tcp
DB2_uk1159_2 20073/tcp
DB2_uk1159_3 20074/tcp
DB2_uk1159_4 20075/tcp
DB2_uk1159_END 20076/tcp
db2c_uk1159 25016/tcp
HADR_P_uk1159 25017/tcp #PrimaryノードHADR通信用
HADR_S_uk1159 25018/tcp #StandbyノードHADR通信用
Step11. HADRのためのDB構成パラメーターの設定
HADR 1号機と2号機のDb2インスタンス間で通信を行うため、Step10で設定した情報に基づいてDb2構成パラメータを設定します。
Step11-1. HADR通信用の設定
HADR 1号機と2号機のDB構成パラメータに、相手サーバとの通信に用いる情報を登録します。
- 自ノード、相手ノードのホスト名(IPアドレスでも可)
- 自ノード、相手ノードのサービス名(ポート番号でも可)
- 相手ノードのDb2インスタンス名
1号機の設定
db2 update db cfg for HADRDB using HADR_LOCAL_HOST host-1
db2 update db cfg for HADRDB using HADR_LOCAL_SVC DB2HADR_P_uk1159
db2 update db cfg for HADRDB using HADR_REMOTE_HOST host-2
db2 update db cfg for HADRDB using HADR_REMOTE_SVC DB2HADR_S_uk1159
db2 update db cfg for HADRDB using HADR_REMOTE_INST uk1159
2号機の設定
db2 update db cfg for HADRDB using HADR_LOCAL_HOST host-2
db2 update db cfg for HADRDB using HADR_LOCAL_SVC DB2HADR_S_uk1159
db2 update db cfg for HADRDB using HADR_REMOTE_HOST host-1
db2 update db cfg for HADRDB using HADR_REMOTE_SVC DB2HADR_P_uk1159
db2 update db cfg for HADRDB using HADR_REMOTE_INST uk1159
補足:
- 通常はIPアドレスやポート番号が万一変わった場合もDb2の構成情報を変更せずに済むよう、Db2の構成パラメータにはホスト名とサービス名を登録し、OSの構成ファイル(hosts, services)を利用して名前解決を行います。
- Db2マニュアル「高可用性災害時リカバリー (HADR) の初期設定」には、「1 次データベースおよびスタンバイ・データベースで、次のように hadr_target_list 構成パラメーターを設定します。(中略) hadr_target_list パラメーターを設定しないと、1 つのスタンバイに制限されます。 HADR を構成するこの方法は、 バージョン 10.5以降非推奨になりました。」と記載されますが、マルチスタンバイ用のパラメータであって必須じゃない、という考え方もあるようで、今回のところはそういうものかと納得してこのパラメータの利用は見送りました
Step11-2. その他の設定
HADR同期モードは、デフォルトではNEARSYNCです。
変更する場合はDB構成パラメータ「HADR_SYNCMODE」を変更します。
その他にもHADRには障害発生時の挙動を制御するためさまざまなDB構成パラメータが存在します。
マニュアルを参照しつつ構成を行います。
高可用性災害時リカバリー (HADR)
Step12. HADRサービスの開始 (2号機)
2号機からサービスを開始します.
[uk1159@host-2 ~]$ db2 start hadr on database HADRDB as standby
DB20000I START HADR ON DATABASE コマンドが正常に完了しました。
[uk1159@host-2 ~]$
HADR2号機の稼働状況確認を行います。
HADR_ROLDはSTANDBY、まだプライマリ(1号機)でのサービスを開始していないことから、HADR_STATEはリモートキャッチアップペンディング, HADR_CONNECT_STATUS は切断状態となっています。
[uk1159@host-2 ~]$ db2pd -d HADRDB -hadr
Database Member 0 -- Database HADRDB -- Standby -- Up 0 days 00:22:00 -- Date 2024-03-08-11.51.03.472501
HADR_ROLE = STANDBY
REPLAY_TYPE = PHYSICAL
HADR_SYNCMODE = NEARSYNC
STANDBY_ID = 0
LOG_STREAM_ID = 0
HADR_STATE = REMOTE_CATCHUP_PENDING
HADR_FLAGS =
PRIMARY_MEMBER_HOST = NULL
PRIMARY_INSTANCE = NULL
PRIMARY_MEMBER = NULL
STANDBY_MEMBER_HOST = host-2
STANDBY_INSTANCE = uk1159
STANDBY_MEMBER = 0
HADR_CONNECT_STATUS = DISCONNECTED
HADR_CONNECT_STATUS_TIME = 2024-03-08 11:29:04.527537 (1709864944)
HEARTBEAT_INTERVAL(seconds) = 5
HEARTBEAT_MISSED = 0
HEARTBEAT_EXPECTED = 0
HADR_TIMEOUT(seconds) = 120
TIME_SINCE_LAST_RECV(seconds) = 0
PEER_WAIT_LIMIT(seconds) = 0
LOG_HADR_WAIT_CUR(seconds) = 0.000
LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000000
LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.000
LOG_HADR_WAIT_COUNT = 0
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 16384
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 87380
PRIMARY_LOG_FILE,PAGE,POS = S0000000.LOG, 0, 0
STANDBY_LOG_FILE,PAGE,POS = S0000001.LOG, 0, 49009825
HADR_LOG_GAP(bytes) = 0
STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000001.LOG, 0, 49009825
STANDBY_RECV_REPLAY_GAP(bytes) = 0
PRIMARY_LOG_TIME = NULL
STANDBY_LOG_TIME = 2024-03-06 20:19:09.000000 (1709723949)
STANDBY_REPLAY_LOG_TIME = 2024-03-06 20:19:09.000000 (1709723949)
STANDBY_RECV_BUF_SIZE(pages) = 16
STANDBY_RECV_BUF_PERCENT = 0
STANDBY_SPOOL_LIMIT(pages) = 25600
STANDBY_SPOOL_PERCENT = 0
STANDBY_ERROR_TIME = NULL
PEER_WINDOW(seconds) = 0
READS_ON_STANDBY_ENABLED = N
HADR_LAST_TAKEOVER_TIME = NULL
[uk1159@host-2 ~]$
Step13. HADRサービスの開始 (1号機)
[uk1159@host-1 ~]$ db2 start hadr on database HADRDB as primary
DB20000I START HADR ON DATABASE コマンドが正常に完了しました。
[uk1159@host-1 ~]$
HADR1号機の稼働状況確認を行います。以下の状態になっていれば問題ないと判断できます。
- HADR_ROLE：PRIMARY
- HADR_STATE：PEER
- HADR_CONNECT_STATUS：CONNECTED
[uk1159@host-1 ~]$ db2pd -d HADRDB -hadr
Database Member 0 -- Database HADRDB -- Active -- Up 0 days 07:07:21 -- Date 2024-03-08-19.04.05.961236
HADR_ROLE = PRIMARY
REPLAY_TYPE = PHYSICAL
HADR_SYNCMODE = NEARSYNC
STANDBY_ID = 1
LOG_STREAM_ID = 0
HADR_STATE = PEER
HADR_FLAGS = TCP_PROTOCOL
PRIMARY_MEMBER_HOST = host-1
PRIMARY_INSTANCE = uk1159
PRIMARY_MEMBER = 0
STANDBY_MEMBER_HOST = host-2
STANDBY_INSTANCE = uk1159
STANDBY_MEMBER = 0
HADR_CONNECT_STATUS = CONNECTED
HADR_CONNECT_STATUS_TIME = 2024-03-08 11:56:47.260363 (1709866607)
HEARTBEAT_INTERVAL(seconds) = 5
HEARTBEAT_MISSED = 0
HEARTBEAT_EXPECTED = 5129
HADR_TIMEOUT(seconds) = 120
TIME_SINCE_LAST_RECV(seconds) = 3
PEER_WAIT_LIMIT(seconds) = 0
LOG_HADR_WAIT_CUR(seconds) = 0.000
LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000020
LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.419
LOG_HADR_WAIT_COUNT = 1239
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 87040
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 369280
PRIMARY_LOG_FILE,PAGE,POS = S0000003.LOG, 800, 60621468
STANDBY_LOG_FILE,PAGE,POS = S0000003.LOG, 794, 60594612
HADR_LOG_GAP(bytes) = 0
STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000003.LOG, 794, 60594612
STANDBY_RECV_REPLAY_GAP(bytes) = 0
PRIMARY_LOG_TIME = 2024-03-08 19:04:02.000000 (1709892242)
STANDBY_LOG_TIME = 2024-03-08 19:03:00.000000 (1709892180)
STANDBY_REPLAY_LOG_TIME = 2024-03-08 19:03:00.000000 (1709892180)
STANDBY_RECV_BUF_SIZE(pages) = 4300
STANDBY_RECV_BUF_PERCENT = 0
STANDBY_SPOOL_LIMIT(pages) = 25600
STANDBY_SPOOL_PERCENT = 0
STANDBY_ERROR_TIME = NULL
PEER_WINDOW(seconds) = 0
READS_ON_STANDBY_ENABLED = N
HADR_LAST_TAKEOVER_TIME = NULL
[uk1159@host-1 ~]$
ここでもう一度HADR2号機の稼働状況確認を行います。以下の状態になっていれば問題ないと判断できます。
- HADR_ROLE：STANDBY
- HADR_STATE：PEER
- HADR_CONNECT_STATUS：CONNECTED
[uk1159@host-2 ~]$ db2pd -d HADRDB -hadr
Database Member 0 -- Database HADRDB -- Standby -- Up 0 days 07:34:39 -- Date 2024-03-08-19.03.42.123171
HADR_ROLE = STANDBY
REPLAY_TYPE = PHYSICAL
HADR_SYNCMODE = NEARSYNC
STANDBY_ID = 0
LOG_STREAM_ID = 0
HADR_STATE = PEER
HADR_FLAGS = TCP_PROTOCOL
PRIMARY_MEMBER_HOST = host-1
PRIMARY_INSTANCE = uk1159
PRIMARY_MEMBER = 0
STANDBY_MEMBER_HOST = host-2
STANDBY_INSTANCE = uk1159
STANDBY_MEMBER = 0
HADR_CONNECT_STATUS = CONNECTED
HADR_CONNECT_STATUS_TIME = 2024-03-08 11:56:47.260924 (1709866607)
HEARTBEAT_INTERVAL(seconds) = 5
HEARTBEAT_MISSED = 0
HEARTBEAT_EXPECTED = 5122
HADR_TIMEOUT(seconds) = 120
TIME_SINCE_LAST_RECV(seconds) = 2
PEER_WAIT_LIMIT(seconds) = 0
LOG_HADR_WAIT_CUR(seconds) = 0.000
LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000020
LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.419
LOG_HADR_WAIT_COUNT = 1235
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 87040
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 367360
PRIMARY_LOG_FILE,PAGE,POS = S0000003.LOG, 794, 60594612
STANDBY_LOG_FILE,PAGE,POS = S0000003.LOG, 794, 60594612
HADR_LOG_GAP(bytes) = 0
STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000003.LOG, 794, 60594612
STANDBY_RECV_REPLAY_GAP(bytes) = 15
PRIMARY_LOG_TIME = 2024-03-08 19:03:00.000000 (1709892180)
STANDBY_LOG_TIME = 2024-03-08 19:03:00.000000 (1709892180)
STANDBY_REPLAY_LOG_TIME = 2024-03-08 19:03:00.000000 (1709892180)
STANDBY_RECV_BUF_SIZE(pages) = 4300
STANDBY_RECV_BUF_PERCENT = 0
STANDBY_SPOOL_LIMIT(pages) = 25600
STANDBY_SPOOL_PERCENT = 0
STANDBY_ERROR_TIME = NULL
PEER_WINDOW(seconds) = 0
READS_ON_STANDBY_ENABLED = N
HADR_LAST_TAKEOVER_TIME = NULL
[uk1159@host-2 ~]$
なお、スタンバイとなっている2号機に接続することはできません。
[uk1159@host-2 ~]$ db2 connect to HADRDB
SQL1776N このコマンドを HADR
データベース上で発行することはできません。
理由コード = "1"。
[uk1159@host-2 ~]$
動作確認
HADR1号機で行ったデータ更新操作の内容が、2号機に伝搬されているか確認します。
(1) テーブル作成、データ挿入、索引定義 (1号機)
[uk1159@host-1 ~]$ db2 connect to hadrdb
データベース接続情報
データベース・サーバー = DB2/LINUXX8664 11.5.9.0
SQL 許可 ID = UK1159
ローカル・データベース別名 = HADRDB
[uk1159@host-1 ~]$ db2 "create table t1 (c1 integer, c2 char(32))"
DB20000I SQL コマンドが正常に完了しました。
[uk1159@host-1 ~]$ db2 "insert into t1 values (1,'A'),(2,'B')"
DB20000I SQL コマンドが正常に完了しました。
[uk1159@host-1 ~]$ db2 "select * from t1"
C1 C2
----------- --------------------------------
1 A
2 B
2 レコードが選択されました。
[uk1159@host-1 ~]$ db2 "create index t1_i1 on t1 (c1)";
DB20000I SQL コマンドが正常に完了しました。
[uk1159@host-1 ~]$
(2) HADR Takeover
2号機でTAKEOVER HADRコマンドを実行します。
[uk1159@host-2 ~]$ db2 takeover hadr on db HADRDB
DB20000I TAKEOVER HADR ON DATABASE
コマンドが正常に完了しました。
2号機がプライマリーになります。
[uk1159@host-2 ~]$ db2pd -d HADRDB -hadr
Database Member 0 -- Database HADRDB -- Active -- Up 0 days 07:40:33 -- Date 2024-03-08-19.09.36.044270
HADR_ROLE = PRIMARY
‥(略)‥
HADR_STATE = PEER
‥(略)‥
HADR_CONNECT_STATUS = CONNECTED
‥(略)‥
(3) 2号機上でのデータ確認
(1)で作成したテーブル、データが2号機にも存在することが確認できます。
[uk1159@host-2 ~]$ db2 "select * from t1"
C1 C2
----------- --------------------------------
1 A
2 B
2 レコードが選択されました。
[uk1159@host-2 ~]$
索引も利用可能状態です。(無効化されていない)
[uk1159@host-2 ~]$ db2 "select substr(tabschema,1,32) as tabschema, substr(tabname,1,32) as tabname, indexes_require_rebuild from sysibmadm.admintabinfo where indexes_require_rebuild='Y'"
TABSCHEMA TABNAME INDEXES_REQUIRE_REBUILD
-------------------------------- -------------------------------- -----------------------
0 レコードが選択されました。
[uk1159@host-2 ~]$
索引の状態確認方法はこちらのTechnoteで確認しました
→ [Db2] 無効化された索引の確認方法 (ibm.com)
(3) 2号機でデータ更新
2号機がプライマリーになっている状態で、データを追加します。
[uk1159@host-2 ~]$ db2 "insert into t1 values(3,'host-2 primary')"
DB20000I SQL コマンドが正常に完了しました。
[uk1159@host-2 ~]$ db2 "select * from t1"
C1 C2
----------- --------------------------------
1 A
2 B
3 host-2 primary
3 レコードが選択されました。
[uk1159@host-2 ~]$
(4) 1号機にTakeover
1号機でTAKEOVER HADRコマンドを実行し、1号機が稼働系となるよう切戻しを行います。
[uk1159@host-1 ~]$ db2 takeover hadr on db HADRDB
DB20000I TAKEOVER HADR ON DATABASE
コマンドが正常に完了しました。
[uk1159@host-1 ~]$
データを確認すると、2号機上で追加したデータが1号機のHADRDBデータベースに反映されていることがわかります。
[uk1159@host-1 ~]$ db2 "select * from t1"
C1 C2
----------- --------------------------------
1 A
2 B
3 host-2 primary
3 レコードが選択されました。
[uk1159@host-1 ~]$
参考情報