OCI Full Stack DR、OCI Database with PostgreSQLのネイティブ・サポートを追加 (2026/10/21)

OCI Full Stack DR、OCI Database with PostgreSQLのネイティブ・サポートを追加 (2026/10/21)

https://blogs.oracle.com/maa/oci-full-stack-dr-native-postgresql-support

投稿者:Suraj Ramesh | Lead Principal Product Manager

ミッションクリティカルなアプリケーションの災害復旧には、データベースの可用性を回復するだけでは不十分です。ダウンタイムを最小限に抑え、事業継続性を確保するためには、アプリケーションサービス、接続性、および復旧における依存関係も調整する必要があります。

OCI Full Stack Disaster Recovery (DR) において、OCI Database with PostgreSQLのネイティブサポートが実現したことをお知らせいたします。OCI Database with PostgreSQL は、Oracle が提供するフルマネージド型の PostgreSQL 互換データベースサービスであり、マネージドバックアップ、パッチ適用、高可用性を提供します。PostgreSQL DB システムを DR 保護グループのメンバーとして追加できるようになったことで、Full Stack DR リカバリプランを通じて、アプリケーションリソースと連携したデータベースの切り替えとフェイルオーバーが可能になります。

この統合により、OCI Full Stack DR のデータベース対応範囲が拡大し、PostgreSQL をバックエンドとするアプリケーションの災害復旧が簡素化されます。また、お客様からのフィードバックに基づき、Compute – Moving Instance向けに、VNIC マッピングでのプライベート IP 予約サポートと、災害復旧訓練用の個別の宛先ネットワーク構成という 2 つのオプションのネットワーク機能強化も導入します。

これらの機能強化は、OCI商用リージョン全体で利用可能になりました。Oracle Alloy、OCI Dedicated Regions、英国政府クラウド、EUソブリンクラウド、米国政府クラウド、および米国国防クラウドへの対応は、今後数週間以内に展開される予定です。

1. OCI Database with PostgreSQLのネイティブ メンバー サポート

PostgreSQLを基盤とするアプリケーションの復旧には、データベースの昇格以上の作業が必要です。アプリケーションリソースを起動し、復旧したデータベースシステムに再接続する必要もあります。

この新しいメンバータイプにより、フルスタックDRプランにPostgreSQLの切り替えおよびフェイルオーバー操作が組み込まれます。データベースチームとアプリケーションチームは、同じプランを使用してこれらのタスクを調整できます。

OCI Database with PostgreSQLのウォームスタンバイアーキテクチャ、および両リージョンにおけるフルスタックDR保護グループとリカバリプラン。

なぜこれが重要なのか:

現在、フルスタックDRとは別にPostgreSQLの復旧を管理している場合、ネイティブ統合により、これらのデータベース操作をアプリケーションリソースと同じDRプランに組み込むことができます。これにより、個別の復旧手順を調整する必要性が減り、以下のようなメリットが得られます。

  • 統合リカバリ管理:フルスタックDRプランに、コンピューティングやその他のアプリケーションリカバリ手順に加えて、PostgreSQLデータベース操作を含める。
  • 組み込みの事前チェック:実行前に災害復旧計画を検証し、報告された問題に対処します。
  • 再現可能な操作:システム障害発生時に個別の手順を調整するのではなく、事前に検証済みの復旧手順を毎回使用する。
  • アプリケーションレベルの連携:データベース操作と、接続設定やDNSの更新など、アプリケーション固有のアクションのためのユーザー定義ステップを組み合わせます。

OCI Full Stack DR と OCI データベース (PostgreSQL) の統合

この統合では、OCI Database with PostgreSQL のウォームスタンバイ機能を利用します。DB システムを Full Stack DR 保護グループに追加する前に、プライマリ リージョンにプライマリ DB システムを構成し、DR リージョンにそのウォームスタンバイを構成して、レプリケーションが確立され、正常に動作していることを確認してください。

OCIフルスタックDR保護グループのメンバーとしてPostgreSQLデータベースシステムを追加する。

前提条件:

  • ウォームスタンバイの設定: OCI Database with PostgreSQLのウォームスタンバイ機能を使用して、プライマリDBシステムとその関連するウォームスタンバイを設定します。
  • 準備状況の確認:両方のDBシステムがアクティブであり、レプリケーションが正常に行われていることを確認します。
  • アクセスと接続の準備: OCI Full Stack DRとOCI Database with PostgreSQLの両方について、必要なIAMポリシーを設定します。これには、Full Stack DR操作に必要なリソースプリンシパル権限も含まれます。適切なネットワークセキュリティルールを使用して、アプリケーションリソースがDBシステムのプライベートエンドポイントにアクセスできることを確認してください。

サービス構成と要件については、OCI Database with PostgreSQLに関するドキュメントを参照してください。

メンバーの追加から災害復旧計画の実行まで

ウォームスタンバイレプリケーションが正常に動作したら、プライマリリージョンとスタンバイリージョンにDR保護グループを作成して関連付けます。この例では、プライマリにロンドン(LON)、スタンバイにフランクフルト(FRA)を使用していますが、他のOCIリージョンを使用することもできます。

リソース第1リージョン — ロンドン第2リージョン — フランクフルト
OCI Database with PostgreSQLapplonappfra
DBシステムの役割Primaryウォームスタンバイ
DR保護グループPSQL-LONPSQL-FRA
DR保護グループの役割PrimaryStandby

1. プライマリDBシステムをプライマリDR保護グループに追加します。

ロンドンリージョンでは、プライマリ DB システムapplon をプライマリ DR 保護グループPSQL-LONに追加します。

プライマリ PostgreSQL DB システム メンバー構成
PostgreSQL DBシステムを搭載したプライマリOCIデータベースが、プライマリDR保護グループに追加されました。

2. ウォームスタンバイDBシステムをスタンバイDR保護グループに追加します。

フランクフルトリージョンでは、ウォームスタンバイDBシステムappfraをスタンバイDR保護グループPSQL-FRAに追加します。両方のグループでPostgreSQLメンバー構成を確認します。

ウォームスタンバイPostgreSQL DBシステムメンバー構成
PostgreSQL DBシステムを搭載したウォームスタンバイOCIデータベースが、スタンバイDR保護グループに追加されました。

3. リージョン2で災害復旧計画を作成する。

フランクフルトリージョンでPSQL-FRA DR保護グループを開き、スイッチオーバーおよびフェイルオーバープランを作成します。Full Stack DRは、サポートされているPostgreSQL操作用の組み込みプラングループとステップを生成します。

フランクフルト保護グループにおけるDR計画
スタンバイDR保護グループにおけるスイッチオーバーおよびフェイルオーバー計画。
災害復旧計画PostgreSQLに組み込まれている手順データベース操作
Switchover生成されたプライマリDBシステムとウォームスタンバイDBシステムの間で役割を切り替える。
フェイルオーバー生成されたウォームスタンバイを、独立した書き込み可能なデータベースシステムに昇格させる。
スタートドリル生成されませんPostgreSQLのDRドリル操作はサポートされていません。
ストップドリル生成されませんPostgreSQLのDRドリル操作はサポートされていません。

注: OCI Database with PostgreSQL メンバーでは、組み込みのドリル開始およびドリル停止操作はサポートされていません。

4. 復旧計画を見直し、カスタマイズする。

生成されたデータベース復旧手順を、計画内の他のアプリケーションリソースの復旧手順と併せて確認してください。データベース接続設定やDNSの更新、アプリケーションサービスの起動など、アプリケーション固有のアクションに対応するユーザー定義手順を追加してください。これらの手順は、アプリケーションの復旧における依存関係に基づいて配置してください。

PostgreSQLの切り替え計画手順(組み込み)
切り替えプランに組み込まれたPostgreSQLの復旧手順。

5. 事前チェックを実行する。

スタンバイDR保護グループでDRプランの事前チェックを実行します。結果を確認し、報告された問題を解決し、必要に応じて事前チェックを再実行してから実行に進みます。

6. スイッチオーバー計画を実行する。

PSQL-FRAでスイッチオーバー計画を実行し、復旧手順を監視します。完了後、フランクフルトのappfraがプライマリ、ロンドンのapplonがウォームスタンバイになっていることを確認します。計画にアプリケーションリソースが含まれている場合は、アプリケーションが新しいプライマリデータベースに接続し、期待どおりに動作することを確認します。

DR保護グループの役割も逆転し、PSQL-FRAがプライマリになり、PSQL-LONがスタンバイになります。

フランクフルトでの切り替え事前チェックと計画実行
フランクフルトにおける事前チェックおよび切り替え計画の実行。

7. 新しいスタンバイリージョンで災害復旧計画を作成する。

ロンドンリージョンでは、 PSQL-LONでロンドンへの復旧のためのスイッチオーバーおよびフェイルオーバー計画を作成します。既に計画が存在する場合は、アプリケーション固有の手順を含め、計画を更新して検証します。

計画は両方の災害復旧保護グループに存在できますが、現在スタンバイの役割を担っているグループの計画のみがアクティブになり、実行可能になります。

役割逆転後のDRのロンドンでの計画
役割逆転後の第1地域における災害復旧計画。

予期せぬ障害が発生した場合は、スタンバイDR保護グループでフェイルオーバー計画を実行し、ウォームスタンバイデータベースをスタンドアロンの書き込み可能なDBシステムに昇格させ、構成済みのアプリケーション復旧アクションを実行します。フェイルオーバー後、レプリケーションを再確立し、後続の復旧操作のために環境を準備するには、PostgreSQLに組み込まれているフェイルオーバー操作とは別に、追加の構成が必要です。


OCI Database with PostgreSQLの統合、およびフルスタックDRの詳細については、こちらのビデオデモをご覧ください。さらに詳しい情報については、OCI Database with PostgreSQLのドキュメントを参照してください。

2. コンピュート – インスタンスの移動機能強化

Full Stack DRでは、 Compute – Moving Instance向けに2つのオプション機能強化が導入されました。それは、予約済みのプライベートIP統合と、DR訓練用の個別の宛先ネットワークです。

2.1 コンピューティングリソースの移動用に予約されたプライベートIPアドレス

この機能強化により、フルスタックDRとOCIの予約済みプライベートIPアドレス機能が統合されます。OCIを使用すると、使用するコンピュートインスタンスとは独立して、サブネット内のプライベートIPアドレスを予約できます。このアドレスはインスタンスが終了した後も予約されたままなので、再利用できます。

Full Stack DRを使用すると、コンピューティングリソースを移動するための宛先VNICマッピングに予約済みのプライベートIPアドレスを設定できるため、復旧後のインスタンスのプライベートIPアドレスを事前に計画できます。

VNIC マッピングを設定する前に、DR リージョン内の宛先 VCN およびサブネットに予約済みのプライベートIPアドレスを作成します。Compute – Moving Instanceメンバーを DR 保護グループに追加する際には、[VNIC マッピングの追加] をクリックし、DR リージョン内の宛先サブネットを選択して、復旧後のインスタンスが DR 操作中に使用する、事前に作成した予約済みのプライベート IP アドレスを指定します。

宛先VNICマッピングで予約済みプライベートIPを設定する

なぜこれが重要なのか:

別のシステムが特定のプライベートIPアドレスからの接続のみを許可している場合、復旧中にアドレスが変更されると、アクセスルールの更新が必要になることがあります。宛先アドレスを予約しておくことで、その設定を事前に準備できます。

アドレス予約は宛先サブネットに適用され、IPリソースをリージョン間で移動させるものではありません。

2.2 移動型コンピューティング災害復旧訓練のための柔軟な宛先ネットワーク

災害復旧訓練中にコンピューティングリソースを移動するための別の宛先ネットワークをオプションで構成できるため、チームは訓練時の接続計画と実際の復旧時の接続計画を別々に立てることができます。

DR保護グループにCompute – Moving Instanceメンバーを追加する際は、 [詳細オプション] → [DRドリルプロパティ]を展開します。[ドリル固有のVNICマッピングを提供する]を選択し、 [VNICマッピングの追加]をクリックして、DRドリルの宛先ネットワークを構成します。

Compute – Moving Instance メンバーを追加しながら、ドリル固有の VNIC マッピングを設定します。

なぜこれが重要なのか:

災害復旧訓練中、アプリケーションインスタンスは、実際の決済、通知、その他の業務サービスではなく、テストエンドポイントへのアクセスを必要とする場合があります。適切なルーティング、セキュリティルール、およびアプリケーション設定と組み合わせた、訓練専用の宛先ネットワークを使用することで、チームはこれらの接続をより詳細に制御できます。

まとめ

OCI Database with PostgreSQLのネイティブサポートにより、データベースの復旧がアプリケーションリソースと同じ災害復旧(DR)計画に組み込まれるため、フルスタックDRとは別に復旧手順を調整する必要性が軽減されます。Compute – Moving Instanceの場合、予約済みのプライベートIP統合により、チームは予測可能な宛先アドレスを準備でき、個別のドリルネットワークにより、テストニーズに合わせてドリル接続をカスタマイズできます。

これらの機能を組み合わせることで、顧客はデータベースとアプリケーションの復旧オーケストレーションを簡素化し、移行先のネットワーク構成の予測可能性を高め、コンピューティング環境の移行に伴う災害復旧訓練を実施する際の柔軟性を向上させることができます。

もっと詳しく知る

OCI Full Stack Disaster Recovery (DR)を始めるには、以下のリソースを参照して、構成ガイド、サポートされているメンバータイプ、復旧プランのオーケストレーション、および実践的な体験を確認してください。ドキュメントには、新しい PostgreSQL 統合と Moving Compute ネットワークの機能強化についても記載されています。

LinkedInやXで気軽に私とつながってください

コメント

このブログの人気の投稿

ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13)

Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20)

Oracle Enterprise Manager 24aiの概要 (2024/12/18)