Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DBCS/ExaCSにおけるData Guard解説

DBCS/ExaCSにおけるData Guard解説

DBCS/ExaCSにおけるData Guard解説です。

3115a782126be714b5f94d24073c957d?s=128

oracle4engineer

September 28, 2020
Tweet

Transcript

  1. 日本オラクル株式会社 データベースソリューション部 2020/5/28 DBCS/ExaCSにおけるData Guard解説

  2. 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一 の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルや コード、機能を提供することをコミットメント(確約)するものではないため、購買決定を行う際の判 断材料になさらないで下さい。 オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により 決定されます。 OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商 標です。

    文中の社名、商品名等は各社の商標または登録商標である場合があります。 Safe harbor statement
  3. Copyright © 2020, Oracle and/or its affiliates 6 概要

  4. Copyright © 2020, Oracle and/or its affiliates 8 アクティブ-アクティブ ・レプリカ

    Oracle GoldenGate レプリカ・データベース Oracle Active Data Guard データベースのクラスタリング Oracle Real Application Clusters Oracle Cloud上でのOracle Databaseのデータベース冗長構成の方式 利用可能なエディション • ExaCS : 利用可能 • DBCS : VM Extreme Performance 利用可能なエディション • ExaCS : 利用可能 • DBCS • Data Guard : Enterprise Edition以上 • Active Data Guard : Extreme Performance 利用可能なエディション • ExaCS : 利用可能 • DBCS : 全て 上記に加えて、Oracle GoldenGateラ イセンスが別途必要
  5. Copyright © 2020, Oracle and/or its affiliates 9 Real Application

    Clusters/Active Data Guard/GoldenGate Oracle Databaseのデータベース冗長構成の方式の比較 Real Application Clusters Data Guard GoldenGate 概要 Oracle Databaseのクラスタリング機 能 Oracle Databaseのレプリケーション 機能 データベースのレプリケーション製 品 データベースの 構成 1つのデータベース 複数の同じデータベース (フィジカル・スタンバイ) 異なるデータベースで、指定した範 囲のデータ同期 クラウドでの 利用 Oracle Cloud のPaaSのみで サポート。同一AD内のみ。 クラウド上での使用可否の制限なし クラウド上での使用可否の制限なし データ整合性 全インスタンスで同じデータにアク セスできるような仕組み 同期ラグがあるため反映するまでは 差分が発生する 同期ラグがあるため反映するまでは 差分が発生する。また、両DB更新可 能のため、差分は発生する可能性あ り 障害時の 切り替え 自動。数秒~数分(障害ケースや Exadataかどうかで異なる) 手動(自動切り替え機能あり)。 数十秒~数分(障害ケースや適用ラグ など状況で異なる) データベースの明示的な切り替えは ない。アプリ側で切り替えが必要 障害時のデータロ ストの可能性 なし 同期転送:なし(単一障害) 非同期転送:あり得る 非同期転送のためあり得る データ保護 ASMでの冗長構成による処理継続と データ破損の即時自動修復 ADGの自動ブロックメディアリカバ リによる自動修復(十数秒) -
  6. Oracle Database自身が持つレプリケーション機能でデータ保護・可用性の提供 + 適切なROIを実現 Oracle Active Data Guard / Data

    Guard プライマリDB スタンバイDB 同期・非同期 破損ブロックの 自動修復(※) レポーティング(※) バックアップ(※) ※Active Data Guardオプションが必要 データ保護 迅速な切り替え リソースの有効活用 スイッチオーバー フェイルオーバー REDO転送によって同期をとること で、データーベースを障害および データ破損から保護 計画/計画外停止時に迅速に切り替 えることでダウンタイムを縮小し、 業務を継続 レポーティング、テストやバック アップ用途でスタンバイ・データ ベースを活用可能 Copyright © 2020, Oracle and/or its affiliates 10
  7. レプリカDBをData Guardで構成することのメリット • 自動データ同期によるデータ保護 • ブロック破損コピーの防止 • 自動ブロック破損修復 • 有事の迅速な切り替え

    • 切り替え後に壊れた旧プライマリ を簡単に復旧可能 • 参照系処理のオフロード • (19c-)更新処理も可能に • 普段から利用することによるレ プリカ側のデータ正常性の確認 • スナップショット・スタンバイ に一時的に切り替え検証利用 • 計画停止時のサービス継続 • 有事の切り替えに備えた正常性 確認 • 定期的な切り替えを推奨 Primary Standby 同期 迅速な切り替え Primary Standby 同期 Primary →Standby Standby → Primary 計画停止のお知らせ 週末 22:00-08:00 データ保護(DR) リードレプリカ/検証 メンテナンス切り替え Copyright © 2020, Oracle and/or its affiliates 11
  8. シングル構成で DBバックアップ取得 DBサーバー冗長構成 複製DBでのDR構成 複製DBの複数(ローカル+リモート)構成 要件に応じて計画停止/計画外停止を考慮した構成を検討 OCI ExadataでのMAA構成 Primary Region

    #1 Standby Region #2 GOLD (DR) Data Guard DB Backup (Object Storage) DB Backup (Object Storage) PLATINUM (HA) Primary Standby Region #1 Region #2 DB Backup (Object Storage) DB Backup (Object Storage) Primary Standby DB Backup (Object Storage) DB Backup (Object Storage) Data Guard/ Golden Gate DG/GG Data Guard/ Golden Gate RAC SILVER DB Backup (Object Storage) Region #1 Primary Standby Data Guard Region #1 SILVER (HA) ケース1 定期メンテナンス許容可能 + RTO/RPOがバックアッ プ・リストアで満たせる ExaCS x1 + Object Storage ケース2 定期メンテナンス時など停 止時間をゼロに近づけたい ケース3 大規模障害を想定した 災対環境保持 ケース4 RPO/RTOを ゼロに近づけたい ExaCS x2(同一リージョン) + Object Storage ExaCS x2(別リージョン) + Object Storage ExaCS x3以上 + Object Storage Copyright © 2020, Oracle and/or its affiliates 12
  9. Data Guard のユース・ケース DR環境・HA構成 クエリ・オフロード テスト環境 メンテナンスや移行 バックアップ処理のオフロード スナップ/クローンのソース ▶

    可用性レベルを向上した自動データ保護 ▶ 分析などの参照系のオフロード ▶ プライマリのバックアップ負荷削減 ▶ プライマリの複製時の負荷削減 ▶ 一時的に書き込み可能モードに変換してテスト ▶ メンテナンス、パッチ適用、移行などでダウンタイムを抑える Copyright © 2020, Oracle and/or its affiliates 13
  10. Copyright © 2020, Oracle and/or its affiliates 14 Database Cloud

    Service/Exadata Cloud Service 自動Data Guard機能 - 概要
  11. OCI内のData Guard構成が簡単に作成可能 • 同一/別リージョン間での、別のExadataサービス・イ ンスタンス(DBシステム)へのDBレプリケーション - 同一コンパートメント内、同一DBバージョン間 - (DBCSの場合) 同一エディション間

    - フィジカル・スタンバイを1つ管理可能 • 管理のためにData Guard Brokerが有効 • スタンバイ側は自動バックアップ機能は無効 • 上記の構成外の場合、手動でData Guardを構築も可能 - 別コンパートメント間、異なるサービス間、複数スタン バイ(2~30)、 フィジカル・スタンバイ以外など - DBCS : Hybrid Data Guard to DBCS BM / VM - ExaCS/ExaCC : Hybrid Data Guard to Exadata Cloud Services 自動Data Guard構築機能 AD AD Region Standby DB System Primary DB System 同一AD 別リージョン Copyright © 2020, Oracle and/or its affiliates 15 Region AD Standby DB System 別AD Standby DB System ※自動構成で作成できるスタンバイは1つ OCI Documentation Exadata DB System > Using Oracle Data Guard with Exadata DB Systems Bare Metal and Virtual Machine DB Systems > Using Oracle Data Guard OTN 連載もしもみなみんがDBをクラウドでうごかしたら第19回 DBの可用性を高めよう - Data Guard編 (DBCS/ExaCS)
  12. Copyright © 2020, Oracle and/or its affiliates 16 DBCS/ExaCSでData Gaurd構成を提案する場合に確認すること

    Data Guardが利用可能な構成か Data Guardの前提条件 • プライマリとスタンバイで一致させる必要があるもの • Oracle Databaseのパッチレベル • データベース構造 (例:CDB構成かNon-CDB構成か) • オプション機能のライセンス GoldenGateは異機種間レプリケーションが可能な製品 • ただし、フィジカル・レプリケーションではなく、 レプリカ先もActive(更新可能)であり非同期のため データ保護を目的として使う場合にデータ差分を 防ぐ仕組みは必要 別のソリューション検討(GoldenGateなど) 自動Data Guard機能が利用可能な構成か 自動Data Guard機能の前提条件 • Oracle Cloud Infrastruture内 • 同一コンパートメント内、同一DBバージョン間 • フィジカル・スタンバイを1つ管理 手動Data Guardを検討 • OnP、他OCIサービス、他社クラウド間など • 手動Data Guard構成の場合、Data Guardの管理も 手動で従来の方式を利用 • データベースの管理は、スタンバイのデータベース 作成をツール(dbaasapi)から一度行うことで可能 White Paper: Hybrid Data Guard to Exadata Cloud Services YES NO NO
  13. プライマリとスタンバイで一致させる必要があるもの • Oracle Databaseのパッチレベル • データベース構造 (例:CDB構成 か Non-CDB構成か) •

    オプション機能のライセンス プライマリとスタンバイで一致させる必要はないもの • DB以外のS/W・H/Wバージョン (例:GI 19cとGI18c) • インスタンス数(例: RACとシングル、4ノードRACと2ノードRAC) • 仮想環境かベアメタル環境 など Doc ID 2183849.1: Oracle Data Guard Configuration Component Version Interoperability Doc ID 413484.1: Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration Data Guard フィジカル・スタンバイの前提 Copyright © 2020, Oracle and/or its affiliates 17
  14. Copyright © 2020, Oracle and/or its affiliates 18 • 自動Data

    Guard構成のスタンバイでは、クラウド・ツールの自動バックアップは有効にできるが自動 バックアップ自体はとられない • ドキュメント DBCS / ExaCS • プライマリ・ロールに切り替えられた際に自動で動く • 手動バックアップ(RMANなど従来方式)は可能 • 自動Data Guard構成のプライマリでは、クラウド・ツールでのリストアは利用不可 • ドキュメント DBCS • 本番稼働時は、プライマリ復旧が必要な状況では、リストアよりもスタンバイへの切り替え(F/O) がRTOとしても推奨。切り替えたうえで、旧プライマリを回復(Flashback Database)かスタンバイ 再作成をツール上から可能 • 上記以外でプライマリを復旧したい場合、手動でRMANやFlashback Databaseも可能 • それでもクラウド・ツールを使いたい場合は、Data Guard構成を削除することで可能 自動Data Guard 注意点
  15. Copyright © 2020, Oracle and/or its affiliates 19 • プライマリとスタンバイのDBシステムで、CIDRが被らないように事前作成時に注意

    • ドキュメント DBCS / ExaCS • 特に、ExaCSやDBCS-BMはDBシステムを作ったあとにその上でData Guard構成を作れるため、初 期にData Guardを組む予定じゃなかったシステム間で、あとから構築しようとしたときに重複す る可能性あり(DBシステムにアタッチされるサブネットは、あとから変更不可) • リージョン間接続はリモート・ピアリングのみ • ドキュメント DBCS / ExaCS • FastConnect利用など、リモート・ピアリングを利用しない場合は下記いずれかで構築 1. 構築時のみリモート・ピアリング利用で、構築後にネットワーク経路を手動変更 - 顧客責任での変更になるのでお客様側で検証をして利用してもらう 2. 手動構築で、Data Guard管理はクラウドツールを利用しない 自動Data Guard 注意点
  16. Copyright © 2020, Oracle and/or its affiliates 26 Database Cloud

    Service/Exadata Cloud Service 自動Data Guard機能 – 作成
  17. Copyright © 2020, Oracle and/or its affiliates 27 ExaCSとDBCS-BMの場合(ComputeとDBが1対N) DBCS-VMの場合(ComputeとDBが1対1)

    自動Data Guard環境作成イメージ Database System Database System ①プライマリDBの DBシステムとDB作成 Database System Database System ② プライマリDBから Data Guardの有効化をして スタンバイDBのDBシステムと スタンバイDB作成 ①プライマリDBの DBシステムを作成 ③スタンバイDBの DBシステム作成 (②プライマリDB を作成) ④プライマリDBから Data Guardの有効化をして スタンバイDB作成
  18. Copyright © 2020, Oracle and/or its affiliates 28 • エディション

    • DBCS : Data GuardはEnterprise Edition以上、Active Data GuardはExtreme Performance(プライマ リ・スタンバイでそろえる) • ExaCS : デフォルトでData GuardもActive Data Guardも使用可能 • 管理ユーザーのIAMサービス・ポリシーでの権限が付与済 • プライマリDBシステムとスタンバイDBシステム間での通信設定 • セキュリティ・リスト(Ingress/Egress)のルール設定。最低限TCPトラフィックでポート1521を有効化 • 異なるリージョン間の場合、DBシステムが属するVCN間でのピアリング設定が必要(次ページ参照) • 環境 • DBCS-VM : プライマリのDBシステムが作成済 • ExaCSとDBCS-BM : プライマリのDBシステムとDB、スタンバイのDBシステムが作成済 自動Data Guard構成事前準備 OCI Documentation Exadata DB System > Using Oracle Data Guard with Exadata DB Systems Bare Metal and Virtual Machine DB Systems > Using Oracle Data Guard
  19. 29 Confidential – © 2020 Oracle Internal リモート・ピアリングの設定 1. 各リージョンでDRGを作成

    2. 各リージョンでDRGをVCNにアタッチする 3. 各DRGにリモート・ピアリング接続を作成 4. どちらかのリモート・ピアリング接続から接続の確 立を行う。送信側は受信側リモート・ピアリング接 続のOCIDを入力 5. 数分待つと接続が確立される 6. 各VCNのルート表に適切なルート・ルールを設定 手順詳細はドキュメント参照のこと 「Remote VCN Peering (Across Regions)」 https://docs.cloud.oracle.com/en- us/iaas/Content/Network/Tasks/remoteVCNpeering.htm リージョン間Data Guard 事前動作準備 リモート・ピアリング設定
  20. Copyright © 2020, Oracle and/or its affiliates 30 Data Guardの有効化(スタンバイDB作成)

    1. プライマリDBにするDBの詳細ページの『Data Guardアソシエーション』から『Data Guardの有 効化』をクリック 2. ピアDB(スタンバイDB)の情報を入力 • 表示名 • リージョン • 可用性ドメイン • シェイプ • ネットワーク情報(VCN/サブネット/ホスト名等) • データベース・パスワード(プライマリDBと同一) 3. 『Data Guardの有効化』をクリックすると作成 Database Cloud Service – Virtual Machine Data Guardのスタンバイ・データーベースの作成方法
  21. Copyright © 2020, Oracle and/or its affiliates 31 Data Guardの有効化(スタンバイDB作成)

    1. プライマリDBにするDBの詳細ページの『Data Guardアソシエーション』から『Data Guardの有 効化』をクリック 2. ピアDB(スタンバイDB)の情報を入力 • リージョン • 可用性ドメイン • シェイプ • ピアDBシステム(作成済みExadata DBシステム名) • データベース・パスワード(プライマリDBと同一) 3. 『Data Guardの有効化』をクリックすると作成 Exadata Cloud Service Data Guardのスタンバイ・データーベースの作成方法
  22. Copyright © 2020, Oracle and/or its affiliates 32 Database Cloud

    Service/Exadata Cloud Service 自動Data Guard機能 – 運用・管理
  23. Copyright © 2020, Oracle and/or its affiliates 33 フェイルオーバー •

    障害発生時など主に計画外停止で行うロール変換 • プライマリ・データベースが停止した状態 • 最大保護モード以外はデータ損失可能性あり • 旧プライマリは、スタンバイ・データベース として再作成が必要 スイッチオーバー • メンテナンスなど計画定期に行うロール変換 • 各データベースが正常にオープン(またはマ ウント)され、データが完全に同期をとれて いる場合に実施可能 • 切り替え後もData Guardとして継続運用や ロールを戻す(スイッチバック)ことが可能 Data Guardの切り替えの種類 Primary Standby → Primary Primary →Standby Standby → Primary
  24. Copyright © 2020, Oracle and/or its affiliates 34 フェイルオーバー •

    スタンバイ側のコンソールから実施 スイッチオーバー • プライマリ側のコンソールから実施 Data Guardの切り替え
  25. Copyright © 2020, Oracle and/or its affiliates 35 • フェイルオーバー後、旧プライマリはData

    Guard構成から外れるため、スタンバイがない 状態 • フェイルオーバーは、主に旧プライマリが利 用できない状態(壊れた状態)の際にスタンバ イに切り替えがされるため、旧プライマリは Data Guard構成からはずれる • 「回復」機能でコンソール上から簡単に、旧プ ライマリをスタンバイとしてデータベースを回 復させてData Guard構成を再編成可能 • Flashback Databaseの機能を利用した仕組み で、 Data Guard Brokerによってワンコマン ドで実行される 旧プライマリの回復 Primary Standby → Primary ①プライマリで障害発生、フェイルオーバー ②旧プライマリをFlashback Databaseで障害発生前の 時点に復旧 Primary ③復旧後、スタンバイとしてData Guard構成へ追加。 過去時点に戻った分のデータ差分は自動で同期 Primary Standby 同期 ②と③をコンソール/CLIから簡単に実行できる
  26. Copyright © 2020, Oracle and/or its affiliates 36 回復 •

    スタンバイ側から実施 旧プライマリの回復
  27. Oracle Confidential – Internal/Restricted/Highly Restricted 37 • クラウド管理のコンソールやCLI/API/SDKなど で簡単に運用・管理が可能 •

    クラウド・ツールでより詳細な運用・管理 は、従来のData Guard関連の機能やサービス も利用可能 • DGMGRL ユーティリティ - Data Guard Broker のコマンドラインユー ティリティ • Oracle Enterprise Manager Cloud Control - Oracle製品の管理ツール - MarketplaceからIaaS上のインストール済イ メージも利用可能 • SQL*Plus Data Guard関連の運用・管理 運用 • スイッチ・オーバー • フェイル・オーバー • 回復 など 監視 • 同期モードの確認 • Data Guard関連構成/設定値の確認 • REDO 転送ラグ • REDO 適用ラグ • REDO適用性能の確認 など Database System Database System Primary Database Standby Database
  28. Copyright © 2020, Oracle and/or its affiliates 38 Data Guard環境の運用・監視一覧

    カテゴリ 内容 クラウド・ツール クラウド以外でも利用可能 コンソール/ REST/ocicli/ SDK OS上のCLI (DBCS: dbcli ExaCS:dbaascli) DG Broker DGMGRL SQL*Plus Enterprise Manager Cloud Control 運用 ロール切り替え (スイッチオーバー/フェイルオーバー) ✔ ✔ ✔ ✔ ✔ 回復 ✔ ✔ ✔ ✔ ✔ スナップショット・スタンバイへの変換 - - ✔ ✔ ✔ Data Guard関連構成/設定変更 - - ✔ ✔ ✔ ファスト・スタート・フェイルオーバー - - ✔ - ✔ 監視 同期モードの確認 ✔ ✔ ✔ ✔ ✔ Data Guard関連構成/設定値の確認 - ✔ ✔ ✔ ✔ REDO 転送ラグ - ✔ ✔ ✔ ✔ REDO 適用ラグ ✔ ✔ ✔ ✔ ✔ REDO 適用プロセス状態・情報 - - ✔ ✔ ✔ REDO 適用性能の確認 ✔ ✔ ✔ ✔ ✔
  29. Copyright © 2020, Oracle and/or its affiliates 39 • 最初にスタンバイ・データベースを終了(削除)しましょう

    • スタンバイ・データベースが紐づけられている(Data Guardアソシエーションがある)状 態の時に、プライマリ・データベースは削除不可 • プライマリ・データベースだけ削除したい場合は、ロールを切り替えましょう • プライマリ・データベースの環境の復旧が難しい場合など • スイッチ・オーバーもしくはフェイル・オーバーで切り替えて、削除対象をスタンバイ に変更 Data Guard構成内のデータベースを削除する場合
  30. Copyright © 2020, Oracle and/or its affiliates 40 自動Data Guard機能で作成されたデフォルト構成の詳細

    デフォルト設定値 変更可否 同期モード 非同期 〇 保護モード 最大パフォーマンスモード 〇 REDO圧縮 無効 〇 Data Guard Broker 有効 ×(無効化すると、DG構成はコ ンソールなどのクラウド・ ツールの管理外になります) 自動切り替え(ファスト・スタート・ フェイルオーバー) 無効 〇 REDO適用の自動パラレル化(12.2以降) 有効 〇
  31.  データ保護 • プライマリで更新されたらスタンバイ への転送未完了でも確定  パフォーマンス影響 • プライマリへの更新処理はスタンバイ への転送を待機しない

     データ保護 • プライマリでのデータ更新はスタンバ イへの転送完了後に確定  パフォーマンス影響 • スタンバイへの転送時間に依存してプ ライマリの更新処理が待機 転送方式による違い Data Guardによるデータ保護の仕組み 同期転送 (SYNC) 非同期転送 (ASYNC) 3.応答 2.転送 4.確定 1.処理 1.処理 2.確定 2.転送 Copyright © 2020, Oracle and/or its affiliates 41 自動DGのデフォルト
  32. 同期/準同期転送モードがあるのは(Active)Data Guardのみ REDOログ転送モード 同期 高速同期(Fast Sync) 非同期 COMMIT時の動作 RFSプロセスがREDO情報を スタンバイREDOログファ

    イルに記録したACKを返す のを待機 (COMMITがスタンバイで 永続化されないとCOMMIT が完了しない) RFSプロセスがREDO情報を メモリに記録したACKを返 すのを待機 (COMMITがスタンバイで 受信されないとCOMMITが 完了しない) RFSプロセスが受信したこ とを待機しない DURABILITYの保証 データ・ロストしない プライマリとスタンバイが 同時に障害を起こさないと いう想定でデータ・ロスト しない プライマリ障害の内容に よってはデータ・ロストが 起こり得る ネットワーク遅延の 性能影響 COMMITに影響 COMMITに影響 影響しない 主用途 同一データセンター内での レプリケーション 同一データセンター内での レプリケーション ディザスタ・リカバリー・ サイト(東京-大阪など) Copyright © 2020, Oracle and/or its affiliates 42 パフォーマンス重視 データ保護重視
  33. 保護モードによる違い Data Guardによるデータ保護の仕組み • 最大可用性 • 最大保護 • 最大可用性 スタンバイに適用された事

    が確認され、制御を戻す 変更履歴が転送されたら適 用前でも制御を戻す 確実なデータ転送の補償のため に、スタンバイから応答が受信 できないとプライマリも停止 New 12.1 Copyright © 2020, Oracle and/or its affiliates 43 New 12.2 複数スタンバイがある場合、 少なくとも1つのスタンバイから 応答があれば継続 高速同期(Fast Sync)モード パフォーマンス重視 データ保護重視 • 最大パフォーマンス トランザクション commit; ユーザトランザクションがcommit さ れると制御はアプリケーションに戻さ れる レプリケーションは非同期に実施 自動DGのデフォルト
  34. Copyright © 2020, Oracle and/or its affiliates 44 Database Cloud

    Service/Exadata Cloud Service 自動Data Guard機能 – 構成パターン発展編
  35. 主な構成パターン 最小構成 マルチ・スタンバイ カスケード リモート・スタンバイ 大規模障害を見据えた災対環境 ローカル・スタンバイ 瞬時の切り替えや同期転送が可能な 近距離のスタンバイ マルチ・スタンバイ

    ローカル・リモートともにスタン バイを持ち、状況に応じて切り替 え。スタンバイごとに、同期・非 同期を設定可 FarSync(遠隔同期)スタンバイ 遠隔地スタンバイとの同期転送の中継 カスケード・スタンバイ テスト用途などスタンバイとは別に レプリカを持ちたい場合 Copyright © 2020, Oracle and/or its affiliates 45 同期 非同期
  36. Far Sync(遠隔同期)インスタンス構成 Copyright © 2020, Oracle and/or its affiliates 46

    • 遠隔地の場合、システム性能とデータ保護のバラ ンスから非同期モードが選択されるため、リカバ リ不能な停止によって生じる様々なレベルのデー タ損失が発生 • Far Sync(遠隔同期)インスタンスを利用すること で、遠隔地スタンバイで実現が難しかった「デー タロスの可能性を低くする構成」を実現 • ツールは対応していないので、自動Data Guard機能の構成に手動で設定変更 • Far Sync(遠隔同期)インスタンス(12.1以降) • Active Data Guardの機能 • REDO転送の中継地 • Far SyncインスタンスにはDBライセンス不要 • Far Syncインスタンスの冗長化も可能 「リージョン間だけどRPOを高めたい(データロスの可能性を減らしたい) 」 Database System Database System Virtual Machine Availability Domain Availability Domain Region Region 同期 非同期
  37. 災害対策(DR)環境として遠隔地/長距離間でのData Guard構成でデータ損失ゼロを実現するには… • スタンバイ側に転送されたことを保証する同期モード(SYNC)を利用したいが、本番環境のパ フォーマンス影響(コミット処理)が課題となり非同期モード(ASYNC)を利用 • 複数スタンバイ(ローカルを追加)はコストや複雑な管理手順が課題 → 多くのシステムでは、データベースのパフォーマンスに影響を与えるよりはデータ保護レベルを妥 協せざるを得ず、結果、リカバリ不能な停止によって生じる様々なレベルのデータ損失が発生

    従来の課題 遠隔地/長距離間でのData Guard構成の課題 プライマリ スタンバイ 非同期 同期 スタンバイへの転送 プライマリへ の書き込み 更新処理の待機時間 距離(ネットワーク性能)や スタンバイ側のI/O性能に 依存して増大 Copyright © 2020, Oracle and/or its affiliates 47
  38. • 同期転送のオーバーヘッド軽減 : 同期転送時のネットワーク・レイテンシを最小限に抑え、本番環境 (プライマリ)へのパフォーマンス影響(コミット処理) を最小化 • ゼロ・データロスの実現 : プライマリ停止時にもREDOデータは転送済のため遠隔地への転送を継続

    • 最小限のファイル構成 : 制御ファイルとREDOログファイルのみ • シームレスなロール変換 : Far Syncインスタンスを意識せずロール変換の実行が可能 遠隔地スタンバイで実現が難しかった「ゼロ・データロスのスタンバイ構成」を実現 Far Sync(遠隔同期)インスタンス プライマリDB スタンバイDB 同期 Far Sync インスタンス 非同期 Active Data Guard 12.1~ Copyright © 2020, Oracle and/or its affiliates 48
  39. • Far Sync (遠隔同期)サーバーの前提 • 制御ファイルとログ・ファイルのみを保持するインス タンスのため、Oracle Databaseのライセンスは不要 • SGA用の小さなメモリとCPU

    (プライマリやスタンバイ 同等は不要) • Active Data Guard ライセンスの機能 • プライマリとスタンバイで必要 • Active Data Guard 構成関連 • REDO転送先にできるスタンバイの数 : 最大29 • 保護モード : 最大可用性モード 特徴と前提 Far Sync (遠隔同期)インスタンス データ ファイル 一時 ファイル 制御ファイル オンライン REDOログ スタンバイ REDOログ PFILE/SPFIL E Oracle Netファイ ル Oracle Database Software データベースのサイズの大半を占める データファイルが不要 Copyright © 2020, Oracle and/or its affiliates 49
  40. ファスト・スタート・フェイルオーバー構成 Copyright © 2020, Oracle and/or its affiliates 50 •

    デフォルトのData Guard構成の場合、障害時の 切り替えは手動で明示的に行う。RTOを考えた 時に、迅速に切り替えられるかが大事となるた め、自動で切り替えたいというケースもある • Data Guardのファスト・スタート・フェイル オーバー機能を利用することで、自動フェイ ル・オーバーが可能 - ツールは対応していないので、自動Data Guard機 能の構成に手動で設定変更 • ファスト・スタート・フェイルオーバー • Oracle Data Guard Brokerの機能 • オブサーバという監視プロセスが自動切り替 えの判断を行う • オブサーバサーバーにはDBライセンス不要 • オブサーバの冗長化も可能(12.2以降) 「自動切り替えしたい」 Database System Database System Virtual Machine Availability Domain Availability Domain Region Region Virtual Machine Observer Observer Primary Database Standby Database
  41. Copyright © 2020, Oracle and/or its affiliates 51 • Data

    Guard Broker 構成が有効になっている環境で、 障害時に監視プロセス(オブザーバー)による自動切り 替え機能 • Data Guard Broker 構成 + オブザーバー - DG Broker≠ファスト・スタート・フェイルオーバー • アプリケーションからのコールによる実行も可能 • フェイルオーバー時の高速アプリケーション通知 (FAN)により、クライアントに連携可能 • 旧プライマリの復旧も自動で行う - フェイルオーバー後に旧プライマリを自動で復旧(フ ラッシュ・バック)し、スタンバイとしてData Guard 構成に組み込む - フラッシュバック・データベースの有効必須 障害時に自動的にData Guard の切り替えを実行し、可用性を高め業務を継続 Data Guard ファスト・スタート・フェイルオーバー Data Guard Broker 構成 プライマリ スタンバイ オブザーバー 新プライマリ 障害検知 自動切り替え
  42. Copyright © 2020, Oracle and/or its affiliates 52 • オブザーバーを複数持つことにより、ファスト・スター

    ト・フェイルオーバーを常に有効に • これまでも EMCC を使用することにより、HA構成での 別サーバー上へ切り替えることは可能 • 最大3つまで起動可能 • 1つがマスター、残りがバックアップ • マスター停止/通信不可時に、バックアップが昇格 • 各オブザーバーごとにログ出力 • 同一サーバー上で複数起動は不可 オブザーバの可用性向上 ファスト・スタート・フェイルオーバーでのオブサーバの冗長構成(12.2以降) Data Guard Broker 構成 オブザーバ バックアップ オブザーバ バックアップ オブザーバ プライマリ スタンバイ
  43. Copyright © 2020, Oracle and/or its affiliates 54

  44. Our mission is to help people see data in new

    ways, discover insights, unlock endless possibilities.