Db2 HADR on GCP – Part 10 Db2 代替サーバー設定

1,437 views

リモートカタログ設定

ノードカタログ

$ db2 "CATALOG TCPIP NODE FIRESE REMOTE 10.146.0.4 SERVER db2c_db2inst1"

ノード名、ホスト名、サービス名を確認します。

$ db2 "LIST NODE DIRECTORY"

ノード・ディレクトリー

ディレクトリー中の項目数 = 1

ノード 1 項目:

ノード名 = FIRESE
コメント =
ディレクトリー項目タイプ = LOCAL
プロトコル = TCPIP
ホスト名 = 10.146.0.4
サービス名 = db2c_db2inst1

データベースカタログ

HADRをリモートの HADRDB_R として追加登録します。

$ db2 "CATALOG DB HADRDB AS HADRDB_R AT NODE FIRESE"

データベース別名に HADRDB_R が入っていることを確認します。
また、カタログ直後は 代替サーバー・ホスト名、代替サーバーのポート名 に何も設定されてない事がわかります。

$ db2 "LIST DB DIRECTORY"
:
:
:
データベース 2 項目:

データベース別名 = HADRDB_R
データベース名 = HADRDB
ノード名 = FIRESE
データベース・リリース・レベル = 15.00
コメント =
ディレクトリー項目タイプ = リモート
カタログ・データベース・パーティション番号 = -1
代替サーバー・ホスト名 =
代替サーバーのポート番号 =

接続確認

一度接続してみます、この際接続ユーザーのパスワードを求められますので、Part 1 からの流れで読んでいただいてる方は passwd コマンドで db2inst1 ユーザーのパスワードを設定しておいてください。

$ db2 "CONNECT TO HADRDB_R USER db2inst1 USING <PASSWORD>"

接続状態を確認してみます。

$ db2 "LIST APPLICATIONS"

“LIST APPLICATIONS” の出力の中で、Application Id の列が “10.146.0.4.39386.201118052849” のような出力になっていると思います。リモート接続の場合 “接続元IP.接続元ポート.TIMESTAMP” になり、ローカル接続の場合は “*LOCAL.インスタンス名.TIMESTAMP” になります。
例えば “10.146.0.4.39386.201118052849″ だった場合、netstat コマンドで確認すると以下のようになります。grep 5000 は /etc/services に定義した Db2 インスタンスの LISTEN ポート になります。

$ netstat -an | grep 50000
tcp        0      0 0.0.0.0:50000           0.0.0.0:*               LISTEN
tcp        0      0 10.146.0.4:50000        10.146.0.4:39386        ESTABLISHED
tcp        0      0 10.146.0.4:39386        10.146.0.4:50000        ESTABLISHED

代替サーバー確認

初回接続後のDB情報を確認してみます。

$ db2 "LIST DB DIRECTORY"
:
:
:
データベース 2 項目:

 データベース別名                     = HADRDB_R
 データベース名                             = HADRDB
 ノード名                             = FIRESE
 データベース・リリース・レベル       = 15.00
 コメント                       =
 ディレクトリー項目タイプ             = リモート
 カタログ・データベース・パーティション番号 = -1
 代替サーバー・ホスト名               = 10.146.0.8
 代替サーバーのポート番号             = 50000

カタログ直後の確認時には入ってなかった 代替サーバー・ホスト名、代替サーバーのポート名 が入っていることがわかります。初回接続時に代替サーバーの情報を受け取ったということですね。
Db2 クライアントを使用している場合、受け取った代替サーバーの情報は
“/home/db2inst1/sqllib/sqldbdir/sqldbdir” に保存されますので、Db2 や サーバーの再起動で消えることありません。バイナリファイルですが無理やり確認してみます。

$ strings /home/db2inst1/sqllib/sqldbdir/sqldbdir
:
:
:
 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQ
UTF-8
10.146.0.8
50000
HADRDB_R
HADRDB
FIRESE

10.146.0.4
50000
10.146.0.8
50000

HADRDB を暗号化DBとして作成しているのでまったく読めない箇所がありますが、代替サーバーらしき情報があるのが確認できます。障害時、Db2クライアントはこの情報に従って再接続を試みることになります。

“TERMINATE” で切断、”FORCE APPLICATION ALL” でアプリケーション切断後に、プライマリー スタンバイ の順番で ”DEACTIVATE DB <データベース名> でデータベースの非活動化を実施し、”db2stop force” で Db2 を停止しておきます。

$ db2 "TERMINATE"
$ db2 "FORCE APPLICATON ALL"
$ db2 "DEACTIVATE DB HADRDB"
$ db2stop force

はい、ここまでで代替サーバーの設定を行い、Db2 インスタンスのローカルクライアント設定、リモートカタログ設定、初回接続時に代替サーバー情報を受け取っていることまで確認できました。
次回は HADR TAKEOVER を実施した際の動作を確認してみたいと思います。

それでは、ありがとうございました!

関連記事

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA