Platinum MAAアーキテクチャでのGGHub配置の計画
停止時間をゼロ(RTO=0またはほぼゼロ)にし、データ損失をゼロまたはほぼゼロ(RPO=0またはほぼゼロ)にする極限の可用性を実現するには、通常、次に示すPlatinum MAAアーキテクチャが必要です。
- Oracle GoldenGateアーキテクチャには、障害(データベース、クラスタまたはサイト障害)の発生時にアプリケーションをただちにフェイルオーバーできるようにして、データベースまたはアプリケーションのアップグレード時にスイッチオーバーできるようにするためのソース・データベースとターゲット・データベースがあります。このアーキテクチャにより、障害シナリオやデータベースおよびアプリケーションのアップグレードの保守に対して、潜在的なRTOをゼロまたはほぼゼロにできます。
- 各ソースおよびターゲット・データベースは、Exadataクラウド・システムにデプロイされるため、ローカルの障害は許容されるかほぼ瞬時にリカバリされます。
- 各ソースおよびターゲット・データベースは、Data Guardファスト・スタート・フェイルオーバーを備えたスタンバイ・データベースとともに構成されているため、データベースに障害が発生すると数秒から数分で新しいプライマリ・データベースがアクティブ化されます。最大可用性保護モードのSYNC転送を利用すると、データ損失ゼロのData Guardフェイルオーバーが実現されます。
- ソースおよびターゲット・データベースの間にMAA GGhubを使用するGoldenGateレプリケーションを使用して構成されます。
- Data Guardのスイッチオーバーまたはフェイルオーバーによってプライマリ・データベースになるスタンバイが、自動的にターゲットのGoldenGateデータベースと再同期するように構成されます。データ損失ゼロのData Guardスイッチオーバーまたはフェイルオーバーが発生した場合は、GoldenGateの再同期により、分散データベース環境全体のデータ損失がゼロになります。
- GoldenGateの自動競合検出および解決を使用して構成されます。これは、Data Guardのフェイルオーバー操作の発生後に必要です。
MAAプライマリGGHubとスタンバイGGHubを配置する場所
- GGHubペア(プライマリとスタンバイのGGhub)は、各プライマリおよびスタンバイ・データベースと同じOCIリージョンに存在する必要があります。たとえば、
- プライマリ・データベースがAD1、リージョンAにあり、スタンバイ・データベースがAD2、リージョンAにある場合、GGHubペアはリージョンAに存在します。
- プライマリ・データベースがリージョンAにあり、スタンバイ・データベースがリージョンBにある場合、GGHubペアはリージョンAとリージョンBの間で分割します。プライマリまたはアクティブなGGhubは、ターゲットのプライマリ・データベースと同じOCIリージョンにコロケートされている必要があります。
- パフォーマンスへの影響:
- プライマリまたはアクティブなGGhubは、ターゲット・データベースと同じOCIリージョンに存在している必要があります。
- プライマリまたはアクティブなGGhubは、GoldenGateのパフォーマンス(Extractのパフォーマンス)低下が発生することのない、ソース・データベースから90ミリ秒未満に収める必要があります。同じ国内のいずれの可用性ドメインまたはOCIリージョンについても、Oracleクラウドはその要件を常に満たします。
- GoldenGate分散パス
- ソースおよびターゲットのGGhubが異なるリージョンにあり、OCIリージョン間のレイテンシが90ミリ秒を超える場合は、GoldenGate分散パスが必要になります。
- Oracle Cloudでは、Oracle GoldenGateのソースとターゲットのデータベースが同じリージョン、または同じ国内の異なるリージョンに存在する場合は、レイテンシが常に90ミリ秒未満になるため、GoldenGate分散パスを設定する必要はありません。
同じOCIリージョン内に配置されたMAA GGHub
このシナリオでは、プライマリとスタンバイのデータベースは同じOCIリージョンに配置されるため、プライマリ(アクティブ)GGHubとスタンバイGGHubも同じリージョンに配置されます。
図1に示すように、次のアーキテクチャ・コンポーネントがあります。
- プライマリ・データベースおよび関連付けられたスタンバイ・データベースは、Oracle Active Data Guardファスト・スタート・フェイルオーバー(FSFO)によって構成されています。FSFOは、データ損失の最大許容度に応じて、ASYNCまたはSYNC REDO転送を使用するData Guard保護モードで構成できます。
- プライマリGGHubアクティブ/パッシブ・クラスタ: 2ノード・クラスタに1つのみのGGHubソフトウェア・デプロイメントと構成があります。このクラスタには、11.2.0.4以降のデータベース・バージョンのサポートが可能な、21cのOracle GoldenGateソフトウェア・デプロイメントが含まれています。このGGHubは、多数のプライマリ・データベースをサポートし、ソース・データベースからトランザクションをマイニングするGoldenGate Extractとターゲット・データベースに同じ変更を適用するGoldenGate ReplicatのGoldenGateプロセスをカプセル化できます。GoldenGate証跡とチェックポイント・ファイルは、GGhub ACFSファイル・システム内にも存在します。HAフェイルオーバー・ソリューションはGGhubに組み込まれています。このソリューションには、同じクラスタ内のパッシブ・ノードへの自動フェイルオーバーが含まれていて、ノード障害後にGoldenGateプロセスとアクティビティを再起動します。
- スタンバイGGHubアクティブ/パッシブ・クラスタ: 対称スタンバイGGhubが構成されています。ACFSレプリケーションは、すべてのGoldenGateファイルを保持するために、プライマリとスタンバイのGGHubの間に設定されています。ACFSフェイルオーバーを含む手動によるGGhubフェイルオーバーは、プライマリGGhub全体が損なわれるまれなケースで実行することになります。
図19-1 同じOCIリージョン内のプライマリおよびスタンバイGGHub
![gghub-one-region gghub-one-region](img/gghub-one-region.png)
上の図は、次のステップによって、プライマリ・データベースAからプライマリ・データベースBにデータをレプリケートして、プライマリBからプライマリAに戻している様子を示しています。
- プライマリ・データベースA: プライマリAのLogminerサーバーは、プライマリGGHub ExtractプロセスにREDO変更を送信します。
- プライマリGGHub: Extractプロセスによって、変更が証跡ファイルに書き込まれます。
- プライマリGGHubからプライマリ・データベースB: プライマリGGHubのReplicatプロセスは、該当する変更をターゲット・データベース(プライマリB)に適用します。
- プライマリ・データベースB: プライマリBのLogminerサーバーは、プライマリGGHub ExtractプロセスにREDOを送信します。
- プライマリGGHub: プライマリGGHubのExtractプロセスによって、変更が証跡ファイルに書き込まれます。
- プライマリGGHubからプライマリ・データベースA: プライマリGGHubのReplicatプロセスは、該当する変更をターゲット・データベース(プライマリA)に適用します。
ソースとターゲットのデータベースが異なるOracle Databaseリリースであっても、1つのGGHubで複数のソース・データベースとターゲット・データベースをサポートできます。
表19-1 同じOCIリージョン内のGGHubの停止シナリオ、修復および冗長性のリストア
停止シナリオ | アプリケーションの可用性と修復 | 冗長性と初期状態の復元 |
---|---|---|
プライマリ・データベースA (またはデータベースB)の障害 |
影響: アプリケーション停止時間は、ほぼゼロです。GoldenGateレプリケーションは、新しいプライマリ・データベースの起動時に再開されます。
|
|
プライマリまたはスタンバイGGHubの単一ノード障害 |
影響: アプリケーションに影響はありません。GoldenGateレプリケーションは、数分後に自動的に再開されます。 処置は必要ありません。GGHubに組み込まれたHAフェイルオーバー・ソリューションには、GoldenGateプロセスとアクティビティの自動フェイルオーバーと再起動が含まれます。レプリケーション・アクティビティは、GoldenGateプロセスが再度アクティブになるまでブロックされます。GoldenGateレプリケーションのブラックアウトは数分間続くことがあります。 |
ノードが再起動すると、アクティブ/パッシブ構成が再確立されます。 |
プライマリGGHubクラスタがクラッシュしてリカバリできない |
影響: アプリケーションに影響はありません。GoldenGateレプリケーションは、既存のGGHubの再起動後、または手動によるGGHubフェイルオーバー操作の実行後に再開されます。
|
前のGGHubが最終的に再起動されると、ACFSレプリケーションは別の方向に自動的に再開されます。GGHubクラスタが損なわれた場合やリカバリ不能になった場合は、新しいスタンバイGGHubを再構築する必要があります。 |
スタンバイGGHubクラスタがクラッシュしてリカバリできない |
影響: アプリケーションまたはレプリケーションに影響はありません。
|
N/A |
データ・センターまたは可用性ドメイン(AD1またはAD2)の全体的な障害 |
影響: アプリケーション停止時間は、ほぼゼロです。GoldenGateレプリケーションは、新しいプライマリ・データベースの起動時に再開されます。
|
|
異なるOCIリージョン内に配置されたMAA GGHub
このシナリオでは、プライマリとスタンバイのデータベースが異なるOCIリージョン内に配置されるため、プライマリ(アクティブ)GGHubはプライマリ・データベースと同じリージョンに配置され、スタンバイGGHubはスタンバイ・データベースと同じリージョンに配置されます。
図2に示すように、次のアーキテクチャ・コンポーネントがあります。
-
プライマリ・データベースおよび関連付けられたスタンバイ・データベースは、Oracle Active Data Guardファスト・スタート・フェイルオーバー(FSFO)によって構成されています。FSFOは、データ損失の最大許容度に応じて、ASYNCまたはSYNC REDO転送を使用するData Guard保護モードで構成できます。
-
プライマリGGHubアクティブ/パッシブ・クラスタ: この構成には、2つのOracle GoldenGateソフトウェア構成を備えた2ノード・クラスタがあります。プライマリGGHubはターゲット・データベースから4ミリ秒以下にする必要がありますが、2つのリージョン(PHXとASH)のネットワーク・レイテンシは5ミリ秒を超えるため、GGHubクラスタごとに2つのGGhub構成が作成されています。基本的に、プライマリGGHub構成は常にターゲット・データベースと同じリージョン内にあります。GGHubは、11g以降のOracle Databaseリリースのサポートが可能なOracle GoldenGate 21cソフトウェア・デプロイメントで構成されています。このGGHubは、多数のプライマリ・データベースをサポートし、ソース・データベースからトランザクションをマイニングするExtractとターゲット・データベースに該当する変更を適用するReplicatのGoldenGateプロセスをカプセル化できます。GoldenGate証跡とチェックポイント・ファイルは、ACFSファイル・システム内にも存在します。GGhubクラスタに組み込まれたHAフェイルオーバー・ソリューションには、ノード障害後のGoldenGateプロセスとアクティビティの自動フェイルオーバーと再起動が含まれています。
それぞれのGGhub構成に、GoldenGateサービス・マネージャとデプロイメント、ACFSレプリケーションによるACFSファイル・システムおよび個別のアプリケーションVIPが含まれています。
- スタンバイGGHubアクティブ/パッシブ・クラスタ: 対称スタンバイGGhubが構成されています。ACFSレプリケーションは、すべてのGoldenGateファイルを保持するために、プライマリとスタンバイのGGHubの間に設定されています。ACFSフェイルオーバーを含む手動によるGGhubフェイルオーバーは、プライマリGGhub全体が損なわれた場合に実行することになります。
図19-2 異なるOCIリージョン内のプライマリおよびスタンバイGGHub
![異なるOCIリージョン内のプライマリおよびスタンバイGGHub 異なるOCIリージョン内のプライマリおよびスタンバイGGHub](img/gghub-two-regions.png)
上の図は、次のステップによって、プライマリ・データベースAからプライマリ・データベースBにデータをレプリケートして、プライマリBからプライマリAに戻している様子を示しています。
- プライマリ・データベースA: プライマリAのLogminerサーバーは、データベースAのプライマリGGHubにあるASHリージョンのGGHub ExtractプロセスにREDO変更を送信します。
- プライマリGGHub: Extractプロセスによって、証跡ファイルに変更が書き込まれます。
- プライマリGGHubからプライマリ・データベースB: ASHリージョンのGoldenGate Replicatプロセスは、該当する変更をターゲット・データベース(プライマリB)に適用します。
- プライマリ・データベースB: プライマリBのLogminerサーバーは、データベースBのプライマリGGHubにあるPHXリージョンのGGHub ExtractプロセスにREDOを送信します。
- プライマリGGHub: Extractプロセスによって、証跡ファイルに変更が書き込まれます。
- プライマリGGHubからプライマリ・データベースA: PHXリージョンのGoldenGate Replicatプロセスは、該当する変更をターゲット・データベース(プライマリA)に適用します。
表19-2 異なるOCIリージョン内のGGHubの停止シナリオ、修復および冗長性のリストア
停止シナリオ | アプリケーションの可用性と修復 | 冗長性と初期状態の復元 |
---|---|---|
プライマリ・データベースA (またはデータベースB)の障害 |
影響: アプリケーション停止時間は、ほぼゼロです。GoldenGateレプリケーションは、新しいプライマリ・データベースの起動時に再開されます。
|
|
プライマリまたはスタンバイGGHubの単一ノード障害 |
影響: アプリケーションに影響はありません。GoldenGateレプリケーションは、数分後に自動的に再開されます。 処置は必要ありません。GGHubに組み込まれたHAフェイルオーバー・ソリューションには、GoldenGateプロセスとアクティビティの自動フェイルオーバーおよび再起動が含まれます。レプリケーション・アクティビティは、GoldenGateプロセスが再度アクティブになるまでブロックされます。GoldenGateレプリケーションのブラックアウトは数分間続くことがあります。 |
ノードが再起動すると、アクティブ/パッシブ構成が再確立されます。 |
プライマリGGHubクラスタがクラッシュしてリカバリできない |
影響: アプリケーションに影響はありません。GoldenGateレプリケーションは、既存のプライマリGGHubの再起動後または手動によるGGHubフェイルオーバーの完了後に再開されます。
|
|
スタンバイGGHubクラスタがクラッシュしてリカバリできない |
影響: アプリケーションまたはレプリケーションに影響はありません。
|
N/A |
リージョン全体の障害 |
影響: アプリケーションの停止時間は、ほぼゼロです。GoldenGateレプリケーションは、新しいプライマリ・データベースが起動すると再開されます。
|
|