【Dbvisit Standby】第2弾：RACノード障害時の動きについて(RAC to Single)

2020年11月17日 Dbvisit Standby

1 はじめに
2 構成図
3 検証開始
4 最後に

はじめに

みなさん、こんにちは。
Dbvisit Standby製品チームです。

今日は前回の、第1弾：Dbvisit Standby構成例のご紹介(RAC to Single)に引き続き、

RACノード障害時の動きについて

についてご紹介させて頂きたいと思います。
よろしくお願いします！

構成図

検証時の製品情報

PRIMARY SITE
OS	Red Hat Enterprise Linux 7.6
DB	Oracle Database 11gR2 Standard Edition 2node RAC
ストレージ・タイプ	Oracle ASM
共有ストレージ	Oracle ACFS
Dbvisit Standby	version 9.0

STANDBY SITE
OS	Red Hat Enterprise Linux 7.6
DB	Oracle Database 11gR2 Standard Edition
ストレージ・タイプ	ファイルシステム
Dbvisit Standby	version 9.0

構成例について確認されたい方は、第1弾：Dbvisit Standby構成例のご紹介(RAC to Single)を、
ご参照ください。

Dbvisit Standbyの各コンポーネントについては、
【入門編】Dbvisit Standby 製品紹介＋アーキテクチャについてを参照ください。

本記事では、Dbvisit Standbyへの理解を深めることを目的としており
皆様の環境での動作を保証するものではありません。

検証開始

それではさっそく検証していきます。
今回の検証の確認ポイントは、以下の3つになります。

● RAC ノード障害時、Dbvisit Standbyが別ノードで起動されること。
● 切り替え後、ログ適用が自動で行われること。
● RAC ノード障害復旧時、障害発生前の状態に戻ること。

node1でクラスタリソースの状態を確認します。

$ crsctl stat res -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS       
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
dbvagent
      1        ONLINE  ONLINE       node1                                 
dbvnet
      1        ONLINE  ONLINE       node1

※表示の都合上、Dbvisit Standby関連のリソースのみ抜粋しております。

node1をシャットダウンします。

# shutdown -h now

node2でクラスタリソースの状態を確認します。

$ crsctl stat res -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS       
Cluster Resources
--------------------------------------------------------------------------------
dbvagent
      1        ONLINE  ONLINE       node2                                 
dbvnet
      1        ONLINE  ONLINE       node2

※表示の都合上、Dbvisit Standby関連のリソースのみ抜粋しております。

dbvnet、dbvagentがnode2で起動していることが確認できます。
これで確認ポイントの1つ目である、
「 RAC ノード障害時、Dbvisit Standbyが別ノードで起動されること」が確認できました！

ログ適用の確認の為、ログスイッチを行います。

SQL> select instance_name, status from gv$instance;

INSTANCE_NAME  STATUS
-------------- -------
ORCL2          OPEN

SQL> alter system switch logfile;

システムが変更されました。

SQL> alter system switch logfile;

システムが変更されました。

SQL> alter system switch logfile;

システムが変更されました。

SQL> exit

Dbvisit StandbyのCentral Consoleからログギャップレポートを確認します。

Dbvisit Standbyのデーモンが、ログ適用を実施するのを待ちます。

Tips：Dbvisit Standbyでは、様々なパラメータを設定し、ログ転送・適用の間隔を
スケジューリング可能となっております。

例：DMN_DBVISIT_INTERVAL・DMN_MONITOR_INTERVAL等

その他のパラメータや詳細等は、Dbvisit Standby User Guideを参照ください。

Dbvisit StandbyのCentral Consoleからログギャップレポートを確認します。

ログギャップがなくなり、ログが適用されたことが確認できます。

こちらで確認ポイントの2つ目である、「切り替え後ログ適用が自動で行われること」が、
確認できました！

切り替え後、自動でログ適用が行われる所まで、確認できたので

続いて、 RAC ノード障害復旧時にDbvisit Standbyが元のノードで戻るのかを
試していきたいと思います。まず、先程シャットダウンしたノードを起動させます。

ノード起動後、クラスタウェアリソースの状態を確認します。

$ crsctl stat res -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS       
-------------------------------------------------------------------------------- 
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
dbvagent
      1        ONLINE  ONLINE       node1                                 
dbvnet
      1        ONLINE  ONLINE       node1

※表示の都合上、Dbvisit Standby関連のリソースのみ抜粋しております。

こちらでdbvnet・dbvagentがnode１に戻っていることが確認できます。

ログ適用確認の為、ログスイッチを行います。

SQL> select instance_name, status from v gv$instance;

INSTANCE_NAME  STATUS
-------------- -------
ORCL1          OPEN
ORCL2          OPEN

SQL> alter system switch logfile;

システムが変更されました。

SQL> alter system switch logfile;

システムが変更されました。

SQL> alter system switch logfile;

システムが変更されました。

SQL> exit