Oracle Active Data GuardがAWS RDSのRead Replicasよりも優れたディザスタリカバリを提供する方法 (2022/11/21)

Oracle Active Data GuardがAWS RDSのRead Replicasよりも優れたディザスタリカバリを提供する方法 (2022/11/21)

https://database-heartbeat.com/2022/11/21/data-guard-aws-rds/



はじめに


最近、AWS RDS for OracleはOracle Active Data GuardをベースとしたRead Replicasを使用した強固なディザスタリカバリソリューションを提供するのか、という質問を受けたことがあります。


Oracle (Active) Data Guardは、間違いなくOracle DatabaseのためのOracleの最も包括的なデータ保護およびディザスタリカバリソリューションです。しかし、私が「RDS」を読んだり聞いたりするたびに、次に頭に浮かぶ言葉は「制限」です。そこで、AWSのドキュメントを確認し、そこに何があるのかを見てみることにしました。引用とスクリーンショットは、以下のAWSのドキュメントから引用しています。



データ損失ゼロ(RPO=0)


AWS RDS Read Replicasは非同期レプリケーションのみをサポートしており、データ損失ゼロを保証するものではありません。AWSはPROを一桁の分単位で主張していますが、これはワークロードによっては現実的かもしれません。



Data Guardは非同期レプリケーションと同期レプリケーションの両方を提供します。Data Guardの最大保護モードは、いかなる状況下でも、1つのトランザクションも含めて、データを失わないことを保証します。Active Data Guard Far Syncは、どのような距離でもデータ損失をゼロにすることができます。ネットワーク暗号化およびREDO圧縮は、FAR SYNCインスタンスにオフロードすることも可能です。



自動フェイルオーバー（低RTO）


AWS RDSのRead Replicasは、手動フェイルオーバーしかサポートしていません。



RTOを一桁分で主張しています。



ただし、Read Replicaを昇格させる前に



これらの待ち時間はすべてRTOに含まれますが、DBAが障害について通知され、システムにログインして分析を行い、Read Replicaを昇格することを決定するまでに必要な時間については言及されていません。RTOは、おそらく「一桁の分」以上となるでしょう。


Data Guardは、Fast-Start Failover（FSFO）機能によって自動フェイルオーバーを行い、人手を介さずに2分またはそれ以下の時間で回復することができます。



アプリケーションフェイルオーバー


障害が発生した場合、データベースとアプリケーションを考慮する必要があります。AWS Read Replicasでは、アプリケーションを停止して、新しいプライマリデータベースを指して再起動する必要があります。



Oracle (Transparent) Application Continuity は Active Data Guard とともに使用することで、透過的なアプリケーションフェイルオーバーを実現し、新しいプライマリデータベース上でインフライトトランザクションを再生することも可能です。


Oracle Global Data Services（GDS）はさらに、リージョンベースのワークロードルーティング、ロードバランシング、ロールベースのグローバルサービス、Active Data Guard用のレプリケーション遅延ベースのワークロードルーティングなどを提供します。



フェイルオーバー後のスタンドバイの再作成


災害発生後は、自動フェイルオーバー機能がないため、前に説明したように、手動でRead Replicasの1つを新しいプライマリとして昇格させる必要があります。そのうえで



「フェイルオーバー」後は、新しいプライマリデータベースと1つまたは複数のスタンバイデータベースを持つわけではありません。新しいスタンドアロンデータベースを持つだけです。以前のスタンバイはすべて削除し、新しいスタンバイを作成する必要があります。この間、本番データベースは、その後の障害に備えて保護されないので、手作業はさておき。


Oracle Data Guard は、構成内の追加の健全なスタンバイデータベースを再構築することなくフェイルオーバー機能を提供し、本番データの継続的な保護を実現します。障害が発生した旧プライマリデータベースを復旧させるだけでよいのです。FastStartFailoverAutoReinstateブローカー構成プロパティをTRUEに設定することで、Fast-Startフェイルオーバーが発生した後に自動的にこれを行うことも可能です。


Data Guardはディザスターリカバリーだけではありません


ここまではディザスターリカバリーについて考えてみました。しかし、（Active）Data Guardはそれ以上のものを提供します。


  •     集中的なワークロードのスケールアウト
  •     より簡単な開発サイクル
  •     オンラインアップグレードとマイグレーション
  •     バックアップとメンテナンスのオフロード


マルチテナントアーキテクチャ


RDS for Oracle replicasサイトの考慮事項には、非推奨の非CDBアーキテクチャのみサポートすると記載されています。



これは、PDBレベルでの統合が行われず、コストと複数のRDSインスタンス用のレプリカの維持が増加することを意味します。



ローリングアップグレードとスタンバイ優先のパッチ適用


AWS RDSの計画的なメンテナンスは、ダウンタイムを意味することを心に留めておいてください リリースアップデート(RU)の適用やメジャーリリースへのアップグレードに関わらず、プライマリデータベースは利用できない。



Oracle Data Guard Standby-First Patch Applyは、その名の通り、まずスタンバイデータベースにパッチを当て、テストのためにスナップショットスタンバイに変換し、物理スタンバイに戻すことができます。そして、準備が整ったところで、元プライマリにパッチを適用します（ダウンタイムはほぼゼロ）。


ダウンタイムがほぼゼロになるのは、Data Guardのローリングアップグレード機能によるメジャーバージョンアップグレードにも適用できます。Active Data Guardは、DBMS_ROLLING PL/SQLパッケージを使用して、このプロセスを簡素化します。



物理スタンバイへのバックアップのオフロード


AWS RDSのリードレプリカはバックアップをサポートしていないため、バックアップは常にプライマリにある必要があり、負荷が増え、高い帯域幅を必要とします。



Oracle Data Guard では、物理スタンバイ上の RMAN バックアップをオフロードすることで、プライマリのリソースを本番ワークロードに解放することができます。Active Data Guard は、物理スタンバイでの Fast Incremental Backups を提供し、スタンバイデータベースシステムでの消費リソースをさらに削減します。



RDSカスタム for Oracle用オラクルレプリカ


AWSは、OSやデータベースへのアクセスやカスタマイズを可能にするRDSのカスタマイズソリューションも提供しています。メンテナンス、バックアップ、スケーリング、高可用性は共有責任です。CDBの作成をサポートする一方で、リージョンをまたぐスタンバイをサポートしないなど、ディザスターリカバリーに関する制限も加わっています。



まとめ


ディザスタリカバリを議論する場合、データ損失をゼロにすることと、RPOとRTOを減らすための自動フェイルオーバーという2つの主要な事柄がある。AWS RDSのリードレプリカは、そのどちらも提供しません。


Data guard（RDS経由ではなく、お客様管理）は、Far Sync（ADGライセンスが必要）により、どんな距離でもデータ損失ゼロを保証し、Fast-Start Failover（FSFO）により、RPO＝0、RTO＝2分程度（適切に調整すればさらに短縮）の自動フェールオーバーを人の介在なく提供します。さらに、Application ContinuityとGlobal Data Servicesは、エンドユーザーに対して透過的なアプリケーションフェイルオーバーを保証します。


高可用性を導入する際には、計画的なメンテナンスも忘れてはいけません。AWS RDSのRead Replicasは、パッチやアップグレードの際にダウンタイムが追加されます。Oracle Data GuardのローリングアップグレードとStandby-Firstパッチ適用により、データベースのダウンタイムをほぼゼロにすることができます。




参考文献

コメント

コメントを投稿

このブログの人気の投稿

Oracle RACによるメンテナンスのためのドレインとアプリケーション・コンティニュイティの仕組み (2023/11/01)

イメージ
Oracle RACによるメンテナンスのためのドレインとアプリケーション・コンティニュイティの仕組み (2023/11/01) https://database-heartbeat.com/2023/11/01/draining-ac-rac/ はじめに Oracle RACは、Oracle Databaseのスケーラビリティと高可用性を提供します。1つのサーバー(RACノード)に障害が発生した場合、またはメンテナンスのためにオフラインになった場合でも、追加のノードを介してデータベースにアクセスできます。ただし、メンテナンスの開始時に、データの読取りまたは変更に関係なく、一部の作業を実行しているクライアント・セッションはどうなりますか。この作業は中断され、ドレインを実装してアプリケーション・コンティニュイティまたは透過的アプリケーション・コンティニュイティを有効にしないかぎり、エンドユーザーまたはアプリケーションによって再度実行する必要があります。 環境 2ノードのOracle RACを例に挙げて、高速アプリケーション通知(FAN)、ドレインおよびアプリケーション・コンティニュイティによってメンテナンス・イベントがエンドユーザーに透過的になる方法を理解しましょう。アプリケーションは、30個のセッションを保持するように構成された接続プールを使用しています。 通常の操作 通常の操作中は、両方のRACノードが起動し、アプリケーションを実行しています。ロード・バランシング戦略によっては、セッションの数が両方のノード間で異なるか、均等に分散される場合があります。次の図をよりよく視覚化するために、ノード2のノード1および20のセッションに10のセッションがあるとします。 セッションは、アイドル状態(接続されているが何もしていない)またはアクティブ状態(リクエストの途中)にできます。リクエストは、データの読取り(SELECT)または操作(INSERT、DELETE、UPDATE)が可能です。 ドレインによるサービスの停止 ある時点で、システムのメンテナンスが必要になります。2ノードRACがあるため、メンテナンスはローリング方式で、1つのノードを順番に(ほとんどの場合)実行できます。メンテナンスは、たとえば、オペレーティング・システム、Grid Infrastructureまたはデ
続きを読む

Oracle APEXのInteractive Gridで、Oracle Formsと比較して、重複行の検証を制御/通過させる方法 (2022/07/21)

イメージ
Oracle APEXのInteractive Gridで、Oracle Formsと比較して、重複行の検証を制御/通過させる方法 (2022/07/21) https://medium.com/oracledevs/how-to-control-or-pass-validation-for-duplicate-rows-in-interactive-grid-of-oracle-apex-as-compare-18f453f750bf 投稿者： Jignesh oracle Formsでは、データブロックの重複行を制御するのは非常に簡単ですが、IGの検証を制御するにはどうすればよいでしょうか。 必要な出力 ステップ1：インタラクティブグリッドのある白紙ページを作成します（私は1つの領域「IG」を作成し、インタラクティブグリッドとしてタイプを選択しました） ステップ 2: リージョンに Static ID を定義する (私の場合、リージョンは IG で、Static ID も IG です) ステップ3：複製を制御したいカラムのStatic IDを定義します ステップ4：関数とグローバル変数に移動します コード： var validity, message, ui = this.data; (function($) { function update(model) { var projKey = model.getFieldKey(“PROJECT_ID”), recObj = [], recArray = []; model.forEach(function(record, index, id) { var projid = parseInt(record[projKey], 10), // record[salKey] should be a little faster than using model.getValue in a loop meta = model.getRecordMetadata(id); if (!isNaN(projid) && !meta.deleted && !meta.agg) { recObj = {ID: id, project_id: projid}; recArray.push(recObj)
続きを読む

Oracle Cloudのデータベースをオブジェクト・ストレージにバックアップする3つの方法 (2021/12/13)

イメージ
Oracle Cloudのデータベースをオブジェクト・ストレージにバックアップする3つの方法 (2021/12/13) https://database-heartbeat.com/2021/12/13/three-ways-backup-cloud/ はじめに Oracle Cloudでは、ボタンをクリックするだけで自動バックアップを有効にするオプションが用意されています。バックアップの要件が異なる場合でも、手動でバックアップ設定を行い、コマンドライン・ツールやRMANを直接使用してバックアップを作成する柔軟性があります。これは、VM DB Systems、Exadata Cloud Service、およびExadata Cloud at Customerに適用されます。 このブログ記事では、Oracle Cloud Object Storageをバックアップ先として使用する場合の、さまざまなバックアップ・オプションの主な違いと、それに伴うコストについて紹介します。Object Storageは、内蔵されたトリプル・ミラーリングと99.999999%(イレブンナイン)の耐久性を提供します。 ハイブリッド・クラウドとマルチ・クラウド Oracle Cloud Object StorageへのOracle Databaseのバックアップは、Oracle Cloud上のOracle Databaseに限らず、ハイブリッドクラウド上のオンプレミスのOracle Databaseや、マルチクラウド環境のOracle以外のクラウド上で稼働しているOracle Databaseに対しても、RMANを介して実装することができます。 プライベートおよび専用のネットワーク接続は、FastConnect、Azure Interconnect、またはサードパーティのネットワーク接続プロバイダを介して提供できます。マルチクラウド環境では、クラウドプロバイダー、リージョン、転送するデータ量に応じて、追加のアウトバウンドトラフィックコストが発生する可能性があります。オラクルをはじめとする多くのクラウドプロバイダーは、すでに Bandwidth Alliance に参加しており、ネットワークエグレス料金を削減または排除しています。 環境について     Oracle Cloud VM DB Sy
続きを読む