X

A blog about Oracle Technology Network Japan

  • March 26, 2018

もしもみなみんがDBをクラウドで動かしてみたら 第6回 [OCI Classic] 可用性構成を作ってみよう - Data Guard 編 - 2018.3.27公開

Eriko Minamino
Solution Engineer

もしもみなみんがDBをクラウドで動かしてみたら indexページ ▶▶

※本記事は2018/7時点のものになります


本記事はOracle Cloudの第一世代、Oracle Cloud Infrastrcuture - Classicの記事です。最新のOracle Cloud Infrastrucure (OCI)の記事は↓こちら↓

第19回 DBの可用性を高めよう - Data Guard編 (DBCS/ExaCS)  

数回に分けて、Oracle Cloud Infrastructure Classic(OCI Classic)上のOracle Database Cloud Service(DBCS)の可用性機能についてご紹介しています。

前回は、サーバー障害時の可用性や拡張性という観点で、Oracle Real Application Clusters(RAC)に触れましたが、より想定される障害規模の大きいDB障害やDB障害やメンテナンス等での可用性観点で、Oracle Data Guard(Data Guard)について解説していきます。


■1. Oracle CloudでのData Guardについて

Data Guardは、変更履歴(REDO)を利用して自動でリアルタイム・データベース複製を持つことが出来る機能です。この機能を利用することによって、計画外のデータベース障害やリージョン障害などのRTO/RPOを短くすることができます。

バックアップを取得していても、有事の際の復旧において、大量データのリストアが必要になる場合ではRTOを満たせないケースもあります。こういったケースに備えて、バックアップだけでなく、すぐに切り替えられるスタンバイを持つケースは少なくないと思います。災害対策(DR)としてのデータ保護はもちろんのこと、移行やアップグレードの停止時間短縮といった利用用途もありますね。また、参照専用として利用可能なActive Data Guardにしたり、一時的に読み書き可能なスナップショット・スタンバイとして利用したりと、普段から利用できるスタンバイ・データベースを持つことができます。参照処理をオフロードしたり、この仕組みを応用してデータ破損が検知された場合にクライアントにエラーを返すことなく自動修復をしてくれる自動メディア・ブロックリカバリ機能も使えるため、Data Guardであればスタンバイのリソースも有効活用してROIを高められます。

クラウドでData Guardを利用する際の基本的な構成については、下記3パターンがあります。

  • 1. 同一リージョン内の別Availability Domain(AD)間 :データベース障害等を考慮したローカル・スタンバイ
  • 2. 別リージョン間 : リージョン障害等を考慮したリモート・スタンバイ
  • 3. オンプレミスとCloud間 : オンプレミスのDRをクラウド上に保持するHybrid構成

これらの3パターン、いずれもDBCSなら簡単に構築が可能です。今回は、1と2のクラウド内での構成を中心に話を進めていきます。

Data Guardの詳細については、『Oracle Databaseのレプリケーション~ DBシステム全体の可用性/性能要件を実現 ~』をぜひご覧ください。

img-1

 

■2. DBCSのData Guard環境構築

さっそく、DBCSでData Guardを構築してみましょう。

まず『ソフトウェア・エディション』についてですが、DBCS上で利用する場合には、

  • Data GuardはEnterprise Edition(EE)以上
  • Active Data GuardはEnterprise Edition(EE) - Extreme Performance
で利用可能です。

 

Data Guardを自動構成するには、『Database Type』の部分で
シングル・インスタンス同士のData Guard構成は『Single Instance with Data Guard Standby』、
RAC同士のData Guard構成は『Database Clustering with RAC and Data Guard Standby』、
オンプレミスなど既存の環境とであれば『Data Guard Standby for Hybrid DR』を選択しましょう。

img-1

Standby Databaseのセクションの『Standby Database Configuration』で、『高可用性』を選択すると同一リージョン内の別Availability Domain(AD)間、『障害回復』を選択すると別リージョン間での構成が組まれることになります。

img-1

あとは、シングル・インスタンスのサービス作成と同様に入力を進めるだけで、『コンピュート・シェイプ』で選択したシェイプ同士のData Guard構成が自動で作成されます。

 

OCI-Classic DBCS Data Guard環境の構築でのポイント

  • エディションは、EEもしくはEE-Extreme Performance
  • クラウド内でのData Guard構成では、サービス作成時のDatabase Typeで『Single Instance with Data Guard Standby』もしくは『Database Clustering with RAC and Data Guard Standby』を選択
 

■3. DBCSのData Guard環境の構成

作成されたData Guard環境の構成を見てみましょう。

同じシェイプ同士のData Guardとして、2つのノードが作成されており、それぞれのデータベース・ロールが表示されます。

img-1

もちろん、有事の際に切り替える場合には、プライマリと同等のリソースが必要とされることから、プライマリとスタンバイを同等構成にすることも多いと思います。ただ、実際のところスタンバイの環境というのは、通常時にはプライマリ・データベースほどリソース(CPUなど)を必要としないことが多いのではないでしょうか。有事に備えたリソースを常に確保するというのは、コストもかかりますよね。

作成時には同じシェイプで作成されるData Guard構成ですが、そういったことを考慮して、実はそれぞれのノードでシェイプを変更することが可能です。

img-1

そのため、スタンバイ側を通常時は最低限必要なリソースで利用し、プライマリと切り替えて利用する際にスケール・アップ、再度スタンバイに戻す際にスケール・ダウンをさせることで、全体のコストを抑えられます。
RACとの組み合わせの場合には、前回の内容の通りRAC構成内のシェイプは同一ですが、プライマリとスタンバイ間では異なるシェイプで構成できます。

データベースの機能に関しては、DBCSのData Guardの環境は、管理の簡易化からOracle Data Guard BrokerとFlashback Databaseが有効になっています。

Data Guard Brokerは、Data Guardの管理フレームワークで、有効にすることで常時Data Guard構成や状態がチェックされ、通常プライマリとスタンバイそれぞれで実行する処理が、DGMGRLというData Guard Brokerのコマンドツールで簡単に管理・運用が出来るようになります。

DGMGRL> SHOW CONFIGURATION VERBOSE;
Configuration - fsc
  Protection Mode: MaxPerformance
  Members:
  ORCL_01 - Primary database
    ORCL_02 - Physical standby database
  Properties:
    FastStartFailoverThreshold      = '30'
    OperationTimeout                = '120'
    TraceLevel                      = 'USER'
    FastStartFailoverLagLimit       = '30'
    CommunicationTimeout            = '180'
    ObserverReconnect               = '0'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'
    ObserverOverride                = 'FALSE'
    ExternalDestination1            = ''
    ExternalDestination2            = ''
    PrimaryLostWriteAction          = 'CONTINUE'
Fast-Start Failover: DISABLED
Configuration Status:

DBCS管理のためのdbaascliユーティリテでdataguardサブコマンドがありますが、これは裏でDGMGRLを利用しています。

DBAAS> dataguard status
DBAAS CLI version 1.0.0
Executing command dataguard status

SUCCESS : Dataguard is up and running

DETAILS:
Configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  ORCL_01 - Primary database
    ORCL_02 - Physical standby database

  Properties:
    FastStartFailoverThreshold      = '30'
    OperationTimeout                = '120'
    TraceLevel                      = 'USER'
    FastStartFailoverLagLimit       = '30'
    CommunicationTimeout            = '180'
    ObserverReconnect               = '0'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'
    ObserverOverride                = 'FALSE'
    ExternalDestination1            = ''
    ExternalDestination2            = ''
    PrimaryLostWriteAction          = 'CONTINUE'

Fast-Start Failover: DISABLED

Flashback Databaseは、フェイルオーバー実施後に旧プライマリ・データベースを簡単にスタンバイとして復旧させるために有効になっています。詳細は、次の章でお話しします。

上記のようなコマンドラインで詳細情報も確認可能ですが、最低限必要なデータベース・ロール、REDO転送/適用ラグ・スタンバイ上のActive Sessions数は、サービス・コンソールから確認できます。

 

OCI-Classic DBCS Data Guard構成のポイント

  • 同一シェイプで構成されるが、プライマリとスタンバイそれぞれでシェイプ変更可能なので、費用削減効果が高い
  • 管理の簡易化から、Oracle Data Guard BrokerとFlashback Databaseが有効

 

■4. 切り替えについて

Data Guard環境では、簡単に切り替え(スイッチオーバー、フェイルオーバー)や旧プライマリの回復(フェイルオーバー実施後に旧プライマリ・データベースを簡単にスタンバイとして復旧)が可能です。

img-1

スイッチオーバーは、計画停止用途のもので、スタンバイにREDOを転送・適用をしきった状態で、プライマリとスタンバイを切り替えます。そのため、切り替え後には旧プライマリは新スタンバイとして、Data Guard構成を保った状態となります。

一方、フェイルオーバーは、計画外停止用途のもので、プライマリ側が利用できない状態の際にスタンバイ側に切り替える際に用いられます。旧プライマリは壊れている状態で切り替えられ、非同期転送をしている場合には未転送分データがない可能性もあり、基本的には切り替え後にスタンバイがない構成となります。そのため、フェイルオーバー後にもData Guardでの可用性構成を組むために、スタンバイを作成して再度Data Guardを構成することが必要となります。

そこで、フェイルオーバー後に活用されるのが、Flashback Database。旧プライマリを障害発生直前(スタンバイが切り替わる前の時点)までデータをフラッシュバックし、スタンバイにロールを変換してData Guard構成に組み込むことができるため、一からスタンバイを構築する必要はありません。

DBCSのData Guardでは、サービス・コンソール上の『回復』というボタンをクリックするだけで、Flashback Databaseを利用してData Guardが再構成されます。

 

OCI-Classic DBCS Data Guardでの切り替えについて

  • スイッチオーバー、フェイルオーバー、旧プライマリの復旧もワンクリック

 

■5.まとめ

業務継続性の担保のために、計画停止/計画外停止を考慮した可用性構成をとることは大切です。ただ、可用性構成をとることが目的ではなく、必要な時にすぐに切り替えられ、きちんと使えるスタンバイを持つことが重要です。

そのために、単にデータファイルをコピーしているわけではないデータを意識した同期方法、日頃から利用することで切り替え時にスタンバイも利用できないという事態を防ぎ、いざ切り替える際には簡単に切り替え・再構成できる環境であることが、DRとしては理想だと思います。

DBCSでのData Guard構成は、ご紹介したようにいくつかパターンがありますので、システムごとに目的にあう構成を使い分けてみてください。

改めてData Guardの良さを学ばれたい方は、ぜひ下記のOracle Database Technology Nightセミナー資料をご覧ください。

Oracle Database Technology Night~集え!オラクルの力(チカラ)~


 

ページトップへ戻る▲ 

 

もしもみなみんがDBをクラウドで動かしてみたら indexページ ▶▶

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.