正系ノードにおけるDBミラーリングシステムの運用中に、データベース二重化処理が異常となった場合のリカバリ方法について示します。
異常事象 | 異常事象を通知するモニタデーモンのメッセージ | 異常事象を通知するSymfoware/RDBのメッセージ |
|---|---|---|
RLCファイルの交替不可 | － | RDBREPORTにqdg20157w,qdg20080uの異常メッセージを出力 |
BCログ管理ファイルの異常 | － | RDBREPORTにqdg20162u,qdg20165u,qdg20166uの異常メッセージを出力 |
RLP閉塞 | イベントログに32021の異常メッセージを出力 | RDBREPORTにqdg20122eの異常メッセージを出力 |
ディスコネクション状態 | イベントログに32031の異常メッセージを出力 | RDBREPORTにqdg20154iのメッセージを出力 |
RERUNログを蓄積するRLCの容量が枯渇した場合には、利用者業務の継続は可能ですが、RLCファイルの交替が不可能となり、RLCファイルにRERUNログを蓄積できなくなります。
RLCファイルの交替が不可能になった場合（RLC容量不足）、DBミラーリングシステムは自動的にRLPを閉塞し、RERUNログの取得を停止します。これにより、正系ノードの利用者業務は継続可能となります。なお、RLPが閉塞した場合、データベース二重化処理が継続できないため、副系ノードへの切替えが不可能となります。その場合には、DBミラーリングシステムを緊急停止してから、利用者業務が停止可能な時間帯にDCUの再構築を行う必要があります。
操作の手順
データベースサーバ1の操作
空きRLCファイル個数減少の警告メッセージを確認します。
qdg20157w: 空きRLCが RLC_NOEMP_WARNで定義した値以下になりました RLC個数= 'RLC個数' RLP名='RLP名'
RLC容量不足のメッセージを確認します。
qdg20080u:RLCの容量不足を検出しました RLP名='RLP名'
RLP閉塞を通知するメッセージを確認します。
qdg20122e:RLPを閉塞しました RLP名='RLP名'
dxsvstopコマンドのtermオプションを実行して、DBミラーリングサービスを緊急停止します。
> dxsvstop -term
DCUの再構築を行います。
データベースサーバ2の操作
dxsvstopコマンドのtermオプションを実行して、DBミラーリングサービスを緊急停止します。
> dxsvstop -term
DCUの再構築を行います。
アプリケーションサーバの操作
DCUの再構築を行う前に、利用者業務を停止します。
ポイント
RLCの容量が枯渇する例として、副系ノードのダウンや保守作業の長期化により、長期間に渡り副系ノードでのデータベース二重化処理が停止する場合などがあります。そのため、RLCの容量見積りを正しく行ってください。
空きRLCファイル個数減少の警告メッセージは、RLP動作環境ファイルのRLC_NOEMP_WARNの指定によって出力されます。
空きRLCファイル個数減少の警告メッセージが出力された場合、RLC容量不足となる前に原因調査とリカバリを行ってください。RLC容量不足となる前にリカバリが完了した場合は対処不要です。
参照
DCUの再構築については“11.9 DCUの再構築”を参照してください。
BCログ管理ファイルに入出力障害が発生した場合のリカバリ操作の手順を示します。
リカバリ操作は、BCログ管理ファイルの障害が発生したノードのみ実施します。
操作の手順
データベースサーバ1の操作
BCログ管理ファイルのアクセスエラーが発生した場合、以下のいずれかのメッセージを出力して、BCログ管理ファイルを閉塞します。
qdg20162u:BCログ管理ファイルが閉塞されています
qdg20165u:BCログ管理ファイルの入出力障害を検出しました
qdg20166u:BCログ管理ファイルに異常があります
dxsvstopコマンドのrオプションを実行してDBミラーリングサービスをリカバリ停止します。
> dxsvstop -r
データベースサーバを停止します。
障害ボリュームを交換します。
rdbbclogコマンドのMオプションおよび、rオプションを実行して、BCログ管理ファイルを再作成します 。
> rdbbclog -M -r
rdbbcrlpコマンドのAオプションおよび、pオプション、Sオプションを実行して、すべてのロググループごとに、BCログ管理ファイルに DCUを構成する2つのRLP を再登録します 。
> rdbbcrlp -A -p 主系RLP名 -S 送信用RLMのファイル名 > rdbbcrlp -A -p 従系RLP名 -S 送信用RLMのファイル名
rdbbcdcuコマンドのVオプションおよび、bオプションを実行してDCUの運用情報を表示し、すべてのロググループごとに、DCUを構成する2つのRLPが正常に登録されたことを確認します。
> rdbbcdcu -V -b
LogGroup : system
RLCbuffNum : -
RLCbuffSize : -
RLCnum : 3
RLCsize : 10240K
RLPid RLPname Kind OnMode OnStat RLPstat InhCause ConStat DisConCause LogRemain
1 rlp001 origin capture online normal - disconnection own-stop -
2 rlp002 duplicate init standby normal - disconnection own-stop -データベースサーバを起動します。
BC管理DBをメモリ常駐します。
dxsvstartコマンドのcオプションを実行して正系ノードのDBミラーリングサービスを開始します。
> dxsvstart -c
アプリケーションサーバの操作
データベースサーバを停止する前に、利用者業務を停止します。
利用者業務を再開します。
ポイント
BCログ管理ファイルをリカバリした後に、すべてのロググループごとに、DCUを構成する2つのRLPをBCログ管理ファイルに再登録する必要があります。
本手順は、副系ノードで異常が発生した場合も同じです。その場合は、DBミラーリングサービスの停止からDBミラーリングサービス開始までの処理は、副系ノードでの手順で実施してください。
DBミラーリングサービスを緊急停止した場合、または、RLP閉塞が発生している場合は、RLPを再登録した後、両ノードでDCUの再構築が必要です。
参照
データベースサーバの起動および停止については“8.1.2 データベースサーバの起動”および“8.2.4 データベースサーバの停止”を参照してください。
監視プロセスの起動については、“Connection Manager ユーザーズガイド” を参照してください。
アプリケーション接続環境の開設プロシジャについては“RDB運用ガイド”を参照してください。
BC管理DBのメモリ常駐については“8.1.3 BC管理DBのメモリ常駐”を参照してください。
DCUの再構築については“11.9 DCUの再構築”を参照してください。
何らかの原因により、RLPが閉塞した場合のリカバリ方法を示します。
例えば、以下のような場合、データベース二重化処理が継続できなくなり、RLPが閉塞します。
副系ノードのダウンや保守作業の長期化により、長期間にわたって副系ノードでのデータベース二重化処理が停止し、RERUNログを蓄積するRLCの容量が枯渇した場合
ノード間の通信環境異常の復旧作業の長期化により、正系ノードでRERUNログを蓄積するRLCの容量が枯渇した場合
RLM、RLCにI/Oエラーが発生した場合
モニタデーモンのダウンが発生した場合
RLPが閉塞した場合は、以下のメッセージが出力されます。
複数のRLPで閉塞が発生した場合は、閉塞が発生したRLPごとに出力します。
イベントログに出力されるメッセージ
32021: RLPの閉塞を検出しました RLP名='RLP名'
RDBREPORTに出力されるメッセージ
qdg20122e:RLPを閉塞しました RLP名='RLP名’
RLPが閉塞した場合には、副系ノードへの切替えが不可能となり、利用者業務を停止した後に、DCUの再構築が必要となります。
なお、RLP閉塞となった原因については、出力されたメッセージを参照し、再構築手順内でリカバリも実施してください。
参照
DCUの再構築については“11.9 DCUの再構築”を参照してください。
DBミラーリングシステムの運用で、ネットワークの異常や相手先データベースが停止した場合に、DBミラーリングサービスを開始している場合でもディスコネクション状態になります。
この場合のリカバリ手順を説明します。
ディスコネクション状態の確認
ディスコネクション状態が発生すると以下のメッセージが出力されます。
qdg20154i:ディスコネクション状態になりました RLP名='RLP名'
ノード間の通信環境に異常がある場合（相手ノードでの異常発生により通信環境の異常として検知した場合を含む）には、以下のメッセージをイベントログに出力します。
32031: ノード間の通信環境(IPアドレスまたはホスト名)に異常が発生しました 相手ノードとの通信が切断されました
ディスコネクション状態の原因調査と対処
DBミラーリングサービスの運用中にディスコネクション状態になった場合の原因の調査方法と対処方法について説明します。
両ノード共通の操作
rdbbcdcuコマンドのVオプションを実行して主系RLPのコネクション状態を確認します。OnStatが“online”かつConStatが“disconnection”の場合、DBミラーリングサービスの運用中にディスコネクション状態となっています。
> rdbbcdcu -V
LogGroup : system
RLCbuffNum : 128
RLCbuffSize : 2K
RLCnum : 3
RLCsize : 10240K
RLPid RLPname Kind OnMode OnStat RLPstat InhCause ConStat DisConCause LogRemain
1 rlp001 origin capture online normal - disconnection network-error -rdbbcdcuコマンドの実行結果より、DisConCauseを参照してディスコネクション原因を確認します。
DisConCauseの表示に対するディスコネクションの原因および対処方法の対応を以下に示します。
DisConCauseの表示 | 原因 | 確認方法 | 対処方法 |
|---|---|---|---|
- | 相手ノードのDBミラーリングサービスが停止中 | － | 相手ノードのDBミラーリングサービスを開始する。 |
other-down | 相手ノードのSymfoware/RDB の停止中（注1） | － | 相手ノードのSymfoware/RDBを起動する。 上記の対処後、自動的に未反映のRERUNログが副系ノードに反映されます。 |
own-stop | 自ノードのSymfoware/RDBが停止中 | － | 自ノードのSymfoware/RDBを起動する。 上記対処後、自動的に未反映のRERUNログが副系ノードに反映されます。 |
network-error （ノード間の通信環境の異常） | 相手ノードのモニタデーモンが未起動 | pingコマンドで相手ノード（注2）との通信は確認でき、かつdxinfコマンドの実行がエラーとなる場合。 | 相手ノードのモニタデーモンの起動、およびDBミラーリングサービスを開始する。 上記の対処後、自動的に蓄積ログが副系ノードに反映されます。 |
ネットワーク障害 | pingコマンドで相手ノード（注2）との通信が確認できない、かつ相手ノードのCPU負荷が高くない場合。 | ネットワークの復旧を行う。 通信環境の復旧後、自動的に蓄積ログが副系ノードに反映されます。 | |
相手ノードが高負荷状態、または通信環境の過負荷 | pingコマンドで相手ノード（注2）との通信が確認できない、かつ相手ノードのCPU負荷が高い場合。 | 利用者業務を停止して、負荷が下がるまでしばらく待つ。 負荷が下がり復旧した後は、自動的に蓄積ログが副系ノードに反映されます。 | |
ノード間通信用ネットワーク定義の指定誤り | 自ノードおよび相手ノードのDBミラーリング動作環境ファイルのOTHER_NODE_ADDRESSを確認し、設定値に誤りがあった場合。 | DBミラーリング動作環境ファイルのOTHER_NODE_ADDRESSを修正して、以下を行う。 1.DBミラーリングサービスをリカバリ停止する |
注1) ディスコネクション原因が相手ノードのSymfoware/RDBのダウンの場合は、相手ノードのSymfoware/RDBダウンから約10分後にディスコネクション状態およびディスコネクション原因が表示されます。
注2) pingコマンドで確認する相手ノードには、DBミラーリング動作環境ファイルの OTHER_NODE_ADDRESS パラメタに設定したIPアドレスまたはホスト名を指定してください。
ポイント
利用者業務はコネクション状態を確認して開始してください。
利用者業務開始後にディスコネクション状態になり、そのまま利用者業務を継続すると空きのRLCファイルがなくなり、RLPが閉塞してDCUの再構築が必要になります。ディスコネクション状態が発生した場合は、早急にリカバリしてください。
ノード切替えが動作すると、ノード切替えを行うためにSymfoware/RDBが停止状態になるため、ディスコネクション状態になります。このとき、ディスコネクション状態の対処は不要です。例えば、正系ノードのデータベースがダウンなどで停止すると通常は副系ノードのデータベースに切替えます。このとき、ディスコネクション状態になります。
なお、副系ノードのデータベースが切替え不可な場合に、正系ノードのデータベースのダウンが発生すると、正系ノードのデータベースを再起動して利用者業務を継続します。このときディスコネクション状態になりますが、副系ノードへの切替え不可の原因を取り除き、正系ノードのデータベースを再起動することにより、ディスコネクション状態は自動的にリカバリされます。
ノード間の通信環境の異常が発生した場合は、通信環境が復旧した後、蓄積データが自動的に相手ノードに転送されます。
ディスコネクション状態の対処としてDBミラーリングサービスを開始する場合には、あらかじめモニタデーモンの起動およびSymfoware/RDBの起動(監視プロセスの起動)を実施しておく必要があります。また、Symfoware/RDBを起動した場合には、BC管理DBのメモリ常駐を行なってください。
ディスコネクション状態の対処としてSymfoware/RDBを起動する場合には、あらかじめモニタデーモンを起動しておく必要があります。また、Symfoware/RDBを起動(監視プロセスの起動)した場合には、BC管理DBのメモリ常駐を行なってください。
参照
モニタデーモンの起動については“8.1.1 モニタデーモンの起動”を参照してください。
モニタデーモンの停止については“8.2.5 モニタデーモンの停止”を参照してください。
DBミラーリングサービスの開始については“8.1.4 DBミラーリングサービスの開始”を参照してください。
Symfoware/RDBの起動については“8.1.2 データベースサーバの起動”を参照してください。
Symfoware/RDBの停止については“8.2.4 データベースサーバの停止”を参照してください。
ノード組込みについては“8.5 ノード組込み”を参照してください。
pingコマンドの詳細については、使用しているシステムベンダのドキュメントを参照してください。
DBミラーリング動作環境ファイルの設定については “5.2.8.1 DBミラーリング動作環境ファイルの編集”を参照してください。
Mirroring Controllerを利用している場合、DBミラーリング動作環境ファイルの設定については“D.1 DBミラーリング動作環境ファイルの編集”を参照してください。
DCUの再構築については“11.9 DCUの再構築”を参照してください。
ノード間の通信環境の異常のリカバリについては“11.7.2 ノード間の通信環境の異常”を参照してください。
監視プロセスの起動については、“Connection Manager ユーザーズガイド” を参照してください。
BC管理DBのメモリ常駐については“8.1.3 BC管理DBのメモリ常駐”を参照してください。