A blog about Oracle Technology Network Japan
- April 21, 2020
第19回 DBの可用性を高めよう - Data Guard編 (DBCS/ExaCS) | もしもみなみんがDBをクラウドで動かしてみたら
もしもみなみんがDBをクラウドで動かしてみたら 連載Indexページ
※本記事は2020/04/20時点のものになります
みなさん、こんにちは。
先日、Database Cloud Service(DBCS)とExadata Cloud Service(ExaCS)で、リージョン間での自動Data Guard機能がリリースされました！日本国内であれば、東京-大阪リージョン間での冗長構成が簡単に組めるということですね。今回のテーマは、その自動Data Guard機能について解説していきます。
目次- Oracle Data Guard/Active Data Guard について
- Oracle Cloudでの構成パターン
- スタンバイ・データベースを作ってみよう-前提条件
- DBCSのスタンバイDBシステムの作成方法
- ExaCSのスタンバイ・データベースの作成方法
- Data Guardの構成について
- Data Guardの切り替えについて
- Data Guard構成に含まれるDBの削除
- まとめ
- よくある質問
1. Oracle Data Guard/Active Data Guard について
Oracle Data Guardとは、変更履歴(REDO)を利用して自動でリアルタイム・データベース複製を持つことが出来る機能です。この機能を利用することによって、データベース障害やリージョン障害などのRTO/RPOを短くすることができ、広範囲な計画停止(メンテナンス)においても切り替えることによって停止時間を極小化することが可能です。バックアップを取得していても、有事の際の復旧において、大量データのリストアが必要になる場合ではRTOを満たせないケースもあります。こういったケースに備えて、バックアップだけでなく、すぐに切り替えられるスタンバイを持つことは重要です。災害対策(DR)としてのデータ保護はもちろんのこと、移行やアップグレードの停止時間短縮といった利用用途もあります。また、参照専用として利用可能なActive Data Guardにしたり、一時的に読み書き可能なスナップショット・スタンバイとして利用したりと、普段から利用できるスタンバイ・データベースを持つことができます。参照処理をオフロードしたり、この仕組みを応用してデータ破損が検知された場合にクライアントにエラーを返すことなく自動修復をしてくれる自動メディア・ブロックリカバリ機能も使えるため、Data Guardであればスタンバイのリソースも有効活用してROIを高めつつ、きちんと切り替えられるスタンバイを持つということが可能です。
2. Oracle Cloudでの構成パターン
Oracle Cloud上でData Guardを利用する際の基本的な構成については、大きく分けて３つのパターンがあります。
- 同一リージョン内でのData Guard : 主に、データベース障害やDBシステム障害やメンテナンスなどを考慮したローカル・スタンバイ
- 別リージョン間でのData Guard : 主に、リージョン障害やメンテナンス時の切り替え先としてローカル・スタンバイ環境をを持たない場合のリモート・スタンバイ
- ハイブリッドData Guard : オンプレミスとクラウド間で構成する、ハイブリッド型のオフサイト・スタンバイ
クラウドの画面上から、(1) 同一リージョン内と(2) 別リージョン間でのData Guard構成が、簡単に構築・管理が可能です。(3)のハイブリッドの場合は、手動で構成が必要となりますが手順を解説したホワイト・ペーパーがあるのでご参照ください。
- DBCS : Hybrid Data Guard to Oracle Cloud Infrastructure 英語 / 日本語
- ExaCS : Hybrid Data Guard to Exadata Cloud Services 英語
3. スタンバイ・データベースを作ってみよう
まずは、構築するにあたり前提条件を確認してみましょう。
前提条件
1) Data Guard/Active Data Guardを使うのに必要なエディション
- DBCSでは、Data GuardはEnterprise Edition以上、Active Data GuardはExtream Performanceが必要
- Exadata Cloud Serivce(ExaCS)はExtream Perfomaneのため、どちらもデフォルトで利用可能
2) Oracle Cloudのインフラ側の前提条件
- 管理ユーザーのIAMサービス・ポリシーでの権限が付与済
- プライマリDBシステムとスタンバイDBシステム間での通信設定(最低限TCPのポート1521を有効化。別リージョン間であればVCN間のピアリング設定が必要)
3) DBCSとExaCSのDBシステム側の前提条件
- 同一コンパートメント内
- 同一DBバージョン・パッチ間 (*)
- 同一エディション同士
- 同一サービス間
- 作成・管理できるスタンバイは１つのフィジカル・スタンバイ
3のDBシステム側の前提条件を満たせない構成の場合、手動でData Guardを構築することは可能です(1と2は必須)。例えば、２つ以上のスタンバイを持ちたい場合や、DBCSとExaCS間などです。なお、(*)が付いている条件はOracle Data Guardとしての前提条件になります。
DBCSとExaCSで作成手順が少し異なるので、それぞれの大まかな流れを最初に説明します。
・DBCSの場合
- プライマリ用のDBシステムを作成
- プライマリのDBシステムの管理画面から、Data Guardアソシエーションを有効化して、スタンバイDBシステムとスタンバイ・データベースを作成
・ExaCSの場合
- プライマリ用のDBシステムと、スタンバイ用のDBシステムを作成
- プライマリのDBシステムの管理画面から、Data Guardアソシエーションを有効化して、スタンバイ・データベースを作成
それでは、それぞれのサービスごとに作成していきましょう。上記の手順１のDBシステムは作成済として、２の部分を解説します。
DBCSのスタンバイDBシステムの作成方法
1.プライマリDBシステム上のプライマリ・データベースの『データベース詳細』ページから、『Data Guardアソシエーション』を選択
2.『Data Guardの有効化』をクリック
3.スタンバイDBシステムとデータベースの情報を入力
ピアDBシステムの作成(スタンバイDBシステム)
- 表示名 : スタンバイDBシステムの表示名
- リージョン : スタンバイDBシステムを作成するリージョン
- 可用性ドメイン : スタンバイDBシステムを作成する可用性ドメイン
- シェイプの選択 : スタンバイDBシステムのシェイプ
- ネットワーク情報の指定
スタンバイ・データベースの構成
- データベース・パスワード : プライマリDBのパスワードと同じものを入力
4.作成された構成を確認
今回は、同一リージョン内(アシュバーン)で作成してみました。下の画面イメージは、東京リージョンのプライマリDBシステム側でData Guardアソシエーションを確認した画面です。
ExaCSのスタンバイ・データベースの作成方法
1.プライマリDBシステム上のプライマリ・データベースの『データベース詳細』ページから、『Data Guardアソシエーション』を選択
2.『Data Guardの有効化』をクリック
3.スタンバイ・データベースの情報を入力
ピアDBシステムの選択(スタンバイDBシステム)
- リージョン : スタンバイDBシステムのあるリージョン
- 可用性ドメイン : スタンバイDBシステムのある可用性ドメイン
- シェイプ : スタンバイDBシステムのシェイプ
- ピアDBシステム : スタンバイDBシステム名を選択
スタンバイ・データベースの構成
- データベース・パスワード : プライマリDBのパスワードと同じものを入力
4.作成された構成を確認
DBCSでは同一リージョン間で構成したので、ExaCSは別リージョン間(東京-大阪間)で作成してみました。下の画面イメージは、東京リージョンのプライマリDBシステム側でData Guardアソシエーションを確認した画面です。ピア・データベースとして、大阪リージョンにあるDBシステムにスタンバイ・データベースが作成されていることを示しています。
4.Data Guardの構成について
自動Data Guard機能で構築されると、下記の状態で構成されます(2020/04時点)
- スタンバイへのREDO適用が開始されている状態
- 保護モード: 最大パフォーマンスモード
- 同期モード : 非同期
- REDO圧縮 : 無効
- REDO適用の自動パラレル化 (12.2以降) : 有効
- Oracle Data Guard Broker : 有効
- 自動切り替え(ファスト・スタート・フェイルオーバー) : 無効
DBCSのOS上のコマンドツールはdbcli、ExaCSのOS上のコマンドツールはdbaascliが用意されており、rootユーザーでData Guard関連の管理や操作も可能です。
・DBCSのコマンドツール dbcliでの、Data Guard構成確認 マニュアル
# /opt/oracle/dcs/bin/dbcli list-dgconfigs # /opt/oracle/dcs/bin/dbcli describe-dataguardstatus -i <ID>
# /opt/oracle/dcs/bin/dbcli list-dgconfigs ID Name Database Name Role Protection Mode Apply Lag Transport Lag Apply Rate Status ---------------------------------------- -------------------------------- -------------------- ---------- ------------------ --------------- --------------- --------------- ---------- f468c07c-ccb6-4f0f-b740-a242659c93d9 DGP_iad17t_DGP_iad23s DGP Primary MaxPerformance 0 seconds 0 seconds 13.00 KByte/s Configured # /opt/oracle/dcs/bin/dbcli describe-dataguardstatus -i f468c07c-ccb6-4f0f-b740-a242659c93d9 Dataguard Status details ---------------------------------------------------------------- ID: f468c07c-ccb6-4f0f-b740-a242659c93d9 Name: DGP_iad17t_DGP_iad23s Database Name: DGP Role: Primary Protection Mode: MaxPerformance Apply Lag: 0 seconds Transport Lag: 0 seconds Apply Rate: 11.00 KByte/s Status: Configured
・ExaCSのコマンドツール dbaascliでの、Data Guard構成確認
# dbaascli dataguard status --dbname <DB名>
# dbaascli dataguard status --dbname emdgp DBAAS CLI version 19.4.4.0.0 Executing command dataguard status SUCCESS : Dataguard is up and running DETAILS: Connected to "emdgp_nrt1mv" Connected as SYSDG. Configuration - fsc Protection Mode: MaxPerformance Members: emdgp_nrt1mv - Primary database emdgp_kix1qh - Physical standby database Properties: FastStartFailoverThreshold = '30' OperationTimeout = '30' TraceLevel = 'USER' FastStartFailoverLagLimit = '30' CommunicationTimeout = '180' ObserverReconnect = '0' FastStartFailoverAutoReinstate = 'TRUE' FastStartFailoverPmyShutdown = 'TRUE' BystandersFollowRoleChange = 'ALL' ObserverOverride = 'FALSE' ExternalDestination1 = '' ExternalDestination2 = '' PrimaryLostWriteAction = 'CONTINUE' ConfigurationWideServiceName = 'emdgp_CFG' Fast-Start Failover: Disabled Configuration Status: SUCCESS
・ocicli でのData Guard構成の確認
$ oci db data-guard-association list --database-id <DBのOCID>
$ oci db data-guard-association list --database-id ocid1.database.oc1.ap-tokyo-1.abxhiljr34y6k27mzesnia7qr3xxhmyevgwqguxbuz3djahugmmn4ej4oejq
{
"data": [
{
"apply-lag": "0 seconds computed 2 seconds ago",
"apply-rate": "2.46 MByte/s",
"database-id": "ocid1.database.oc1.ap-tokyo-1.abxhiljr34y6k27mzesnia7qr3xxhmyevgwqguxbuz3djahugmmn4ej4oejq",
"id": "ocid1.dgassociation.oc1.ap-tokyo-1.abxhiljrybsfqmz3amypzbxp6r4f6pib4q546n25fxw6gwqtoqcqykuvu77q",
"lifecycle-details": null,
"lifecycle-state": "AVAILABLE",
"peer-data-guard-association-id": "ocid1.dgassociation.oc1.ap-osaka-1.abvwsljru3pnn2kjfyi3gi5cu3eckkuz2trrx2tn6bnbzqo6ewtcwc5cvyoq",
"peer-database-id": "ocid1.database.oc1.ap-osaka-1.abvwsljraquduk67djge3zusvipkidjnbyorzpe3bawknsogihoh5q3sxqhq",
"peer-db-home-id": "ocid1.dbhome.oc1.ap-osaka-1.abvwsljrrxyfdcqvgel4n576snhcky3p3asqt7jvkle2rtmd22nfsfcw6fpq",
"peer-db-system-id": "ocid1.dbsystem.oc1.ap-osaka-1.abvwsljrgockrpzpvx3e236egr3xqqkkeqg4c5bffuwux77wmlixjx66cgyq",
"peer-role": "PRIMARY",
"protection-mode": "MAXIMUM_PERFORMANCE",
"role": "STANDBY",
"time-created": "2020-04-03T11:47:29.417000+00:00",
"transport-type": "ASYNC"
}
]
}
DBCSとExaCSの自動Data Guardの環境は、管理の簡易化からOracle Data Guard BrokerとOracle Flashback Databaseの機能が有効になっています。Data Guard Brokerは、Data Guardの管理フレームワークです。これを有効にすることで、常時Data Guard構成や状態がチェックされ、通常プライマリとスタンバイそれぞれで実行する必要がある処理を、DGMGRLというData Guard Brokerのコマンドツールで簡単に管理・運用が出来るようになります。コンソールやdbcliやdbaascliなどのクラウドツールでのData Guardの管理操作では、裏ではData Guard Brokerが動いています。そのため、Data Guard Brokerを無効にしてしまうと、クラウドツールが動作しなくなる可能性があるので無効化しないようにしましょう。
Flashback Databaseは、フェイルオーバー実施後に旧プライマリ・データベースを簡単にスタンバイとして回復させるために有効になっています。詳細は、次の章でお話ししますが、こちらも無効化してしまうと「回復」機能が使えなくなるので有効化のままがおすすめです。上記のようなコマンドラインで詳細情報も確認可能ですが、最低限必要なデータベース・ロールと適用ラグは、コンソールからも確認できます。
5.Data Guardの切り替えについて
コンソールやCLIから、簡単にData Guardの切り替え(スイッチオーバー、フェイルオーバー)や旧プライマリの回復(フェイルオーバー実施後に旧プライマリ・データベースを簡単にスタンバイとして復旧)が可能です。前述したクラウドツールのCLIでももちろん実行可能です。
スイッチオーバー
スイッチオーバーは主に計画停止用途のもので、スタンバイにREDOを転送・適用をしきった状態で、プライマリとスタンバイを切り替えます。そのため、切り替え後には旧プライマリは新スタンバイとしてData Guard構成を保った状態となります。スイッチオーバーは、プライマリDBシステムのData GuardアソシエーションのスタンバイDBが表示されている箇所から実行します。
フェイルオーバー
フェイルオーバーは主に計画外停止用途のもので、プライマリ側が利用できない状態の際にスタンバイ側に切り替える際に用いられます。旧プライマリは壊れている状態で切り替えられ、非同期転送をしている場合には未転送分データがない可能性もあり、基本的には切り替え後にスタンバイがない構成となります。そのため、フェイルオーバー後にもData Guardでの可用性構成を組むために、スタンバイを作成して再度Data Guardを構成することが必要となります。フェイルオーバーは、スタンバイDBシステムのData GuardアソシエーションのプライマリDBが表示されている箇所から実行します。
回復
フェイルオーバー後に活用されるのがFlashback Database機能です。旧プライマリを障害発生直前(スタンバイが切り替わる前の時点)までデータを戻し(フラッシュバック)、スタンバイにロールを変換してData Guard構成に組み込まれ、フラッシュバックしたことで生じる差分も自動で同期されるため、一からスタンバイを構築する必要はありません。そのため、DBCSやExaCSのData Guard機能では、コンソール上の『回復』というボタンをクリックするだけで簡単にData Guardが再構成されます。回復は、プライマリDBシステムのData GuardアソシエーションのスタンバイDB(旧プライマリ)が表示されている箇所から実行します。
6.Data Guard構成に含まれるDBの削除
Data Guardアソシエーションに含まれるデータベースもしくはDBシステムを削除する場合、最初にスタンバイ・データベース(DBシステム)を削除しましょう。スタンバイ・データベースが紐づけられている状態の時に、プライマリ・データベースを削除しようとするとエラーが表示され、削除できません。もし、プライマリ・データベースの環境のみを削除したい場合には、一度ロールを切り替えて削除対象の環境をスタンバイ・ロールにしてから削除という形をとって頂ければと思います。
7. まとめ
業務継続性の担保のために、計画停止/計画外停止を考慮した可用性構成をとることは大切です。ただ、可用性構成をとることが目的ではなく、必要な時にすぐに切り替えられ、きちんと使えるスタンバイを持つことが重要です。そのために、単にデータファイルをコピーしているわけではないデータを意識した同期方法、日頃から利用することで切り替え時にスタンバイも利用できないという事態を防ぎ、いざ切り替える際には簡単に切り替え・再構成できる環境であることが重要で、そういった観点で実装・機能拡張を続けているのがOracle Data Guardです。クラウド上であれば、ご紹介したように簡単に構築・管理ができるので、データベースはData Guardでの冗長構成を検討してみてください。
よくある質問
Q1) プライマリとスタンバイを異なるシェイプ同士で利用可能ですか
A1) はい、可能です。以前は同一シェイプである必要がありましたが、現在は異なるシェイプ間も対応しています
Q2) スタンバイの時だけ小さいシェイプにして、切り替えてプライマリにした時に大きいシェイプにすることは可能ですか
A2) DBCSの場合、可能です。切り替え後に、スケール・アップ(シェイプの変更)をすることによって大きいシェイプに変更可能です。ExaCSの場合は、シェイプの変更ができません。そのため、異なるシェイプ間での構成は組むことはできますが、切り替え後に旧プライマリとは異なることを考慮する必要があります
関連リンク
・Oracle Cloud Infrastructure ドキュメント DBCS Oracle Data Guardの使用
・Oracle Cloud Infrastructure ドキュメント Exadata DBシステムでのOracle Data Guardの使用