![](https://xn--w8j8bac3czf5bl7e.com/wp-content/uploads/blog/4fe0dacb78f38fee704a1a96dd4dc202-750x479.png)
目次
- 1 はじめに
- 2 構成図
- 3 検証開始
- 3.1 node1でクラスタリソースの状態を確認します。
- 3.2 node1をシャットダウンします。
- 3.3 node2でクラスタリソースの状態を確認します。
- 3.4 ログ適用の確認の為、ログスイッチを行います。
- 3.5 Dbvisit StandbyのCentral Consoleからログギャップレポートを確認します。
- 3.6 Dbvisit Standbyのデーモンが、ログ適用を実施するのを待ちます。
- 3.7 Dbvisit StandbyのCentral Consoleからログギャップレポートを確認します。
- 3.8 切り替え後、自動でログ適用が行われる所まで、確認できたので
- 3.9 ノード起動後、クラスタウェアリソースの状態を確認します。
- 3.10 ログ適用確認の為、ログスイッチを行います。
- 3.11 Dbvisit StandbyのCentral Consoleからログギャップレポートを確認します。
- 3.12 Dbvisit Standbyのデーモンがログ適用を実施するのを待ちます。
- 3.13 Dbvisit StandbyのCentral Consoleからログギャップレポートを確認します。
- 3.14 今回のまとめ
- 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がnode1に戻っていることが確認できます。
ログ適用確認の為、ログスイッチを行います。
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
Dbvisit StandbyのCentral Consoleからログギャップレポートを確認します。
Dbvisit Standbyのデーモンがログ適用を実施するのを待ちます。
Dbvisit Standbyのデーモンがログ適用を実施するのを待ちます。
Dbvisit StandbyのCentral Consoleからログギャップレポートを確認します。
ログギャップがなくなり、ログが適用されたことが確認できます。
こちらで確認ポイントの3つ目である、「ノード障害復旧時、障害発生前の状態に戻ること」が
確認できました!
今回のまとめ
● RAC ノード障害時、Dbvisit Standbyが別ノードで起動されること。
● 切り替え後、ログ適用が自動で行われること。
● RAC ノード障害復旧時、障害発生前の状態に戻ること。
上記ポイントが全て実施され、ノード障害発生時でもDbvisit Standbyが正常稼働することが
確認できました!
今回の RAC ノード障害時の動きについてのご紹介は以上となります。
次回は、スタンバイDBの作成(RAC to Single)についてご紹介してみたいと思います。
最後に
Dbvisit Standbyの機能や利用方法・導入・費用については、より詳しい説明をご希望の方は、
どんな些細なことでもお気軽にお問合せ下さい🤵
社内に保守体制もあり、Dbvisit Standbyに精通した専門の技術者がお答えします。
『この環境・構成でも問題なく利用できるか』など是非お気軽にお問合せ下さい。
ここまでご覧頂き、ありがとうございました😆
投稿者プロフィール
![技術チーム](https://xn--w8j8bac3czf5bl7e.com/wp-content/uploads/blog/41007909421_6ae3fe3ef0_z-150x150.jpg)
Oracle Cloud2024年9月3日OCIとADアカウント連携してみました
インフラ2024年6月21日Zabbixエージェントをインストール・対象サーバを監視してみました!
Infrastructure(IaaS)2024年6月4日OCI ブート・ボリュームのバックアップ・リストア
Oracle Cloud2024年5月31日OCIのMySQLでリードレプリカを構成してみました!