Platinum MAAアーキテクチャでのGGHub配置の計画

MAA GGHubは、プライマリGGHubクラスタとスタンバイGGHubクラスタの2つのGGHubクラスタで構成されます。

ソースのプライマリ・データベース、ソースのスタンバイ・データベース、ターゲットのプライマリ・データベースおよびターゲットのスタンバイ・データベースに関連して、プライマリおよびスタンバイのGGHubクラスタを配置する場所を決定する場合は、次のガイドラインに従います:

ターゲットのプライマリ・データベースの近くで、プライマリ・アクティブGGHubを見つけます。プライマリ・アクティブGGHubとターゲット・プライマリ・データベース間のネットワーク・ラウンドトリップ待機時間は、許容可能なGoldenGate Replicatパフォーマンスを確保するために、4ミリ秒以下である必要があります。
プライマリ・アクティブGGHubとソース・プライマリ・データベース間のネットワーク・ラウンドトリップ待機時間は、許容可能なGoldenGate Extractパフォーマンスを確保するために、90ミリ秒以下である必要があります。ネットワーク・ラウンドトリップ待機時間が90ミリ秒を超える場合は、GoldenGate分散パスが必要です。
双方向レプリケーションを構成する場合でも、前述のガイドラインを満たす必要があります。したがって、ソース・データベースとターゲット・データベース間のネットワーク・ラウンドトリップ待機時間が4ミリ秒を超える場合は、同じGGHubクラスタに2つのアクティブなGGHub構成を構成する必要があります。

次の表に、サイト間の待機時間とGoldenGateレプリケーションの方向性に基づく、必要なGoldenGate構成の数を示します。

GGHubクラスタ間の待機時間	単方向のGoldenGateレプリケーション	双方向のGoldenGateレプリケーション
4ミリ秒以下	1 GGHubに1つのGoldenGate構成	1 GGHubに1つのGoldenGate構成
4ミリ秒未満	1 GGHubに1つのGoldenGate構成	1 GGHubに2つのGoldenGate構成

同じデータ・センターに配置されたMAA GGHub

このシナリオでは、プライマリ・データベースとスタンバイ・データベースは、GGHubクラスタ間の待機時間が4ミリ秒以下になるように配置されるため、次の図に示すように、プライマリ(アクティブ) GGHubとスタンバイGGHubは通常、同じデータ・センター内の別々の可用性ドメイン(AD)に配置されます。

次に示すように、次のアーキテクチャ・コンポーネントがあります:

プライマリ・データベースおよび関連付けられたスタンバイ・データベースは、Oracle Active Data Guardファスト・スタート・フェイルオーバー(FSFO)によって構成されています。FSFOは、データ損失の最大許容度に応じて、ASYNCまたはSYNC REDO転送を使用するData Guard保護モードで構成できます。
アクティブ/パッシブ・クラスタ上のプライマリGGHub: 2ノード・クラスタに1つのみのGGHubソフトウェア・デプロイメントと構成があります。このクラスタには、リリース23ai以降でのOracle GoldenGateソフトウェア・デプロイメントが含まれており、Oracle Database 11.2.0.4以降のデータベース・バージョンをサポートできます。
このGGHubは、多数のプライマリ・データベースをサポートし、ソース・データベースからトランザクションをマイニングするGoldenGate Extractとターゲット・データベースに同じ変更を適用するGoldenGate ReplicatのGoldenGateプロセスをカプセル化できます。GoldenGate証跡ファイルとチェックポイント・ファイルも、GGHub ACFSファイル・システムに存在します。HAフェイルオーバー・ソリューションはGGHubに組み込まれています。このソリューションには、同じクラスタ内のパッシブ・ノードへの自動フェイルオーバーが含まれていて、ノード障害後にGoldenGateプロセスとアクティビティを再起動します。
アクティブ/パッシブ・クラスタ上のスタンバイGGHub: 対称スタンバイGGHubが構成されています。ACFSレプリケーションは、すべてのGoldenGateファイルを保持するために、プライマリとスタンバイのGGHubの間に設定されています。ACFSフェイルオーバーを含む手動によるGGHubフェイルオーバーは、プライマリGGHub全体が損なわれるまれなケースで実行することになります。

図26-1 同じデータ・センター内のプライマリおよびスタンバイGGHub

「図26-1 同じデータ・センター内のプライマリおよびスタンバイGGHub」の説明

上の図は、次のステップによって、プライマリ・データベース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で複数のソース・データベースとターゲット・データベースをサポートできます。

表26-1 同じデータ・センター内のGGHubの停止シナリオ、修復、および冗長性のリストア

停止シナリオ	アプリケーションの可用性と修復	冗長性と初期状態の復元
プライマリ・データベースA (またはデータベースB)の障害	影響: アプリケーション停止時間は、ほぼゼロです。GoldenGateレプリケーションは、新しいプライマリ・データベースの起動時に再開されます。 1つのプライマリ・データベースが引き続き使用できます。すべてのアクティビティは、アプリケーションの停止時間がゼロになるように、使用可能な既存のプライマリ・データベースにルーティングされます。Global Data Servicesのグローバル・サービス・フェイルオーバーのソリューションを参照してください。たとえば、アプリケーション・サービスのAからFはデータベースAにルーティングされ、アプリケーション・サービスのGからJはデータベースBにルーティングされているとします。データベースAに障害が発生すると、すべてのアプリケーション・サービスは一時的にデータベースBに移動します。スタンバイは、Data Guard FSFOによって自動的に新しいプライマリになります。Oracle GoldenGateレプリケーションが再開され、プライマリ・データベースが再同期されます。データ損失は、Data Guard保護レベルによって制限されます。最大可用性または最大保護が構成されている場合は、データ損失がゼロになります。すべてのコミットされたトランザクションは、一方または両方のデータベースにあります。ワークロードは、プライマリ・データベースAとデータベースBが使用可能であり、同期状態にあるときには「リバランス」できます。たとえば、データベースAが稼働中で同期状態にある場合、サービスAからFはデータベースAに戻すことができます。	元のプライマリ・データベースは、冗長性をリストアするために新しいスタンバイ・データベースとして回復されます。オプションで、Data Guardスイッチオーバーを実行して元の構成に戻すと、1つ以上のプライマリ・データベースが個別のAD内に存在するようにします。
プライマリまたはスタンバイGGHubの単一ノード障害	影響: アプリケーションに影響はありません。GoldenGateレプリケーションは、数分後に自動的に再開されます。処置は必要ありません。GGHubに組み込まれたHAフェイルオーバー・ソリューションには、GoldenGateプロセスとアクティビティの自動フェイルオーバーと再起動が含まれます。レプリケーション・アクティビティは、GoldenGateプロセスが再度アクティブになるまでブロックされます。GoldenGateレプリケーションのブラックアウトは数分間続くことがあります。	ノードが再起動すると、アクティブ/パッシブ構成が再確立されます。
プライマリGGHubクラスタがクラッシュしてリカバリできない	影響: アプリケーションに影響はありません。GoldenGateレプリケーションは、既存のGGHubの再起動後、または手動によるGGHubフェイルオーバー操作の実行後に再開されます。 GGHubクラスタの再起動が可能な場合は、それが最も単純なソリューションです。プライマリGGHubがリカバリ不可能な場合は、スタンバイGGHubへの手動によるGGHubフェイルオーバー(ACFSフェイルオーバーを含む)を実行します。これには通常、数分かかります。 GoldenGateレプリケーションは、新しいプライマリGGhubが使用可能になるまで停止するため、ステップ1またはステップ2は迅速に実行する必要があります。	前のGGHubが最終的に再起動されると、ACFSレプリケーションは別の方向に自動的に再開されます。GGHubクラスタが損なわれた場合やリカバリ不能になった場合は、新しいスタンバイGGHubを再構築する必要があります。
スタンバイGGHubクラスタがクラッシュしてリカバリできない	影響: アプリケーションまたはレプリケーションに影響はありません。 GGHubクラスタが再起動可能な場合は、それが最も単純なソリューションであり、ACFSレプリケーションを再開できます。スタンバイGGHubがリカバリ不可能な場合は、新しいスタンバイGGHubを再構築することになります。	N/A
可用性ドメイン(AD1またはAD2)の障害	影響: アプリケーション停止時間は、ほぼゼロです。GoldenGateレプリケーションは、新しいプライマリ・データベースの起動時に再開されます。 1つのプライマリ・データベースが引き続き使用できます。すべてのアクティビティは、アプリケーションの停止時間がゼロになるように、使用可能な既存のプライマリ・データベースにルーティングされます。グローバル・サービス・フェイルオーバーのソリューションを参照してください。たとえば、アプリケーション・サービスのAからFはデータベースAにルーティングされ、アプリケーション・サービスのGからJはデータベースBにルーティングされているとします。データベースAに障害が発生すると、すべてのサービスは一時的にデータベースBに移動します。プライマリGGHubがまだ機能している場合、GoldenGateレプリケーションは続行されます。ADの障害が原因でプライマリGGHubが失われた場合は、手動によるGGhubフェイルオーバーが必要です。GoldenGateレプリケーションが再開され、プライマリ・データベースが再同期されます。データ損失は、Data Guard保護レベルによって制限されます。最大可用性または最大保護が構成されている場合は、データ損失がゼロになります。すべてのコミットされたトランザクションは、一方または両方のデータベースにあります。ワークロードは、プライマリ・データベースAとデータベースBが使用可能であり同期状態にあるときにはリバランスできます。データベースAが稼働中で同期状態にある場合、サービスAからFはデータベースAに戻すことができます。	ADの復帰時に、スタンバイの回復などの構成を再確立します。前のGGHubが最終的に再起動されると、ACFSレプリケーションは別の方向に自動的に再開されます。可能な場合は、Data Guardスイッチオーバー(フェイルバック)を実行して、各ADに1つのプライマリ・データベースが存在する元の状態に戻します。

別々のデータ・センターに配置されたMAA GGHub

このシナリオでは、プライマリ・データベースとスタンバイ・データベースは別々のデータ・センターにあります(4ミリ秒より長い待機時間)。そのため、プライマリ(アクティブ) GGHubはプライマリ・データベースと同じデータ・センターにあり、スタンバイGGHubはスタンバイ・データベースと同じデータ・センターにあります。

次の図で示すように、次のアーキテクチャ・コンポーネントがあります。

プライマリ・データベースおよび関連付けられたスタンバイ・データベースは、Oracle Active Data Guardファスト・スタート・フェイルオーバー(FSFO)によって構成されています。FSFOは、データ損失の最大許容度に応じて、ASYNCまたはSYNC REDO転送を使用するData Guard保護モードで構成できます。
アクティブ/パッシブ・クラスタ上のプライマリGGHub: この構成には、2つのOracle GoldenGateソフトウェア構成を備えた2ノード・クラスタがあります。プライマリGGHubはターゲット・データベースから4ミリ秒以下である必要があり、サイト間のネットワーク待機時間は5ミリ秒を超える必要があるため、GGHubクラスタごとに2つのGGHub構成が作成されます。基本的に、プライマリGGHub構成は、必ずターゲット・データベースと同じデータ・センター内にあります。

GGHubは、Oracle Database 11g以降のリリースをサポートできる、Oracle GoldenGate 26ai以降のソフトウェア・デプロイメントで構成されています。これらのGGHubは、多数のプライマリ・データベースをサポートし、ソース・データベースからトランザクションをマイニングするExtractとターゲット・データベースに該当する変更を適用するReplicatのGoldenGateプロセスをカプセル化できます。GoldenGate証跡ファイルとチェックポイント・ファイルも、ACFSファイル・システムに存在します。GGHubクラスタに組み込まれているHAフェイルオーバー・ソリューションには、ノード障害発生後のGoldenGateプロセスおよびアクティビティの自動フェイルオーバーと再起動が含まれています。

ノート: それぞれのGGHub構成に、GoldenGateサービス・マネージャおよびデプロイメント、ACFSレプリケーションによるACFSファイル・システム、ならびに別個のアプリケーションVIPが含まれています。
アクティブ/パッシブ・クラスタ上のスタンバイGGHub: 対称スタンバイGGHubが各サイトに構成されています。ACFSレプリケーションは、すべてのGoldenGateファイルを保持するために、プライマリとスタンバイのGGHubの間に設定されています。ACFSフェイルオーバーを含む手動によるGGhubフェイルオーバーは、プライマリGGhub全体が損なわれた場合に実行することになります。

図26-2 別々のデータ・センターにあるプライマリGGHubとスタンバイGGHub

「図26-2 別々のデータ・センターにあるプライマリGGHubとスタンバイGGHub」の説明

プライマリ・データベースA: プライマリAのLogminerサーバーは、データベースAのプライマリGGHubにあるサイト2のGGHub ExtractプロセスにREDO変更を送信します。
プライマリGGHub: Extractプロセスによって、証跡ファイルに変更が書き込まれます。
プライマリGGHubからプライマリ・データベースB: サイト2のGoldenGate Replicatプロセスは、該当する変更をターゲット・データベース(プライマリ・データベースB)に適用します。
プライマリ・データベースB: プライマリBのLogminerサーバーは、データベースBのプライマリGGHubにあるサイト1のGGHub ExtractプロセスにREDOを送信します。
プライマリGGHub: Extractプロセスによって、証跡ファイルに変更が書き込まれます。
プライマリGGHubからプライマリ・データベースA: サイト1のGoldenGate Replicatプロセスは、該当する変更をターゲット・データベース(プライマリ・データベースA)に適用します。

表26-2 別々のデータ・センター内のGGHubの停止シナリオ、修復および冗長性のリストア

停止シナリオ	アプリケーションの可用性と修復	冗長性と初期状態の復元
プライマリ・データベースA (またはデータベースB)の障害	影響: アプリケーション停止時間は、ほぼゼロです。GoldenGateレプリケーションは、新しいプライマリ・データベースの起動時に再開されます。 1つのプライマリ・データベースが引き続き使用できます。すべてのアクティビティは、アプリケーションの停止時間がゼロになるように、使用可能な既存のプライマリ・データベースにルーティングされます。Global Data Servicesのグローバル・サービス・フェイルオーバーのソリューションを参照してください。たとえば、アプリケーション・サービスのAからFはデータベースAにルーティングされ、アプリケーション・サービスのGからJはデータベースBにルーティングされているとします。データベースAに障害が発生すると、すべてのサービスは一時的にデータベースBに移動します。スタンバイは、Data Guard FSFOによって自動的に新しいプライマリになります。GoldenGateレプリケーションが再開され、プライマリ・データベースが再同期されます。データ損失は、Data Guard保護レベルによって制限されます。最大可用性または最大保護が構成されている場合は、データ損失がゼロになります。すべてのコミットされたトランザクションは、一方または両方のデータベースにあります。ワークロードは、プライマリ・データベースAとデータベースBが使用可能であり同期状態にあるときにはリバランスできます。たとえば、データベースAが稼働中で同期状態にある場合、サービスAからFはデータベースAに戻すことができます。 Replicatのパフォーマンスは、プライマリGGHubがターゲット・データベースと同じサイトに存在していないと低下するようになります。ACFSレプリケーション・スイッチオーバーによるGGHubスイッチオーバーをスケジュールして、ターゲット・データベースに対する最適なReplicatパフォーマンスを再開します。その結果、同じGGHubクラスタ上に2つのアクティブなGGHub構成が存在する場合があります。	元のプライマリ・データベースは、冗長性をリストアするために新しいスタンバイ・データベースとして回復されます。オプションで、Data Guardスイッチオーバーを実行し、元の構成に戻すことで1つ以上のプライマリ・データベースが個別のAD内に存在するようにします。ACFSレプリケーション・スイッチオーバーによるGGHubスイッチオーバーをスケジュールして、ターゲット・データベースに対する最適なReplicatパフォーマンスを再開します。
プライマリまたはスタンバイGGHubの単一ノード障害	影響: アプリケーションに影響はありません。GoldenGateレプリケーションは、数分後に自動的に再開されます。処置は必要ありません。GGHubに組み込まれたHAフェイルオーバー・ソリューションには、GoldenGateプロセスとアクティビティの自動フェイルオーバーおよび再起動が含まれます。レプリケーション・アクティビティは、GoldenGateプロセスが再度アクティブになるまでブロックされます。GoldenGateレプリケーションのブラックアウトは数分間続くことがあります。	ノードが再起動すると、アクティブ/パッシブ構成が再確立されます。
プライマリGGHubクラスタがクラッシュしてリカバリできない	影響: アプリケーションに影響はありません。GoldenGateレプリケーションは、既存のプライマリGGHubの再起動後または手動によるGGHubフェイルオーバーの完了後に再開されます。 GGHubクラスタの再起動が可能な場合は、それが最も単純なソリューションです。プライマリGGHubがリカバリ不可能な場合は、スタンバイGGHubへの手動によるGGHubフェイルオーバー(ACFSフェイルオーバーを含む)を実行します。これには通常、数分かかります。レプリケーションは、新しいプライマリGGhubが起動されるまで停止するため、ステップ1またはステップ2は迅速に実行する必要があります。オーケストレーションが存在する場合、これは自動化する必要があります。	前のGGHubが最終的に再起動されると、ACFSレプリケーションは別の方向に自動的に再開されます。GGHubクラスタが損なわれた場合やリカバリ不能になった場合は、新しいスタンバイGGHubを再構築する必要があります。 Replicatのパフォーマンスは、プライマリGGHubがターゲット・データベースと同じデータ・センターにないと低下します。ACFSレプリケーション・スイッチオーバーによるGGHubスイッチオーバーをスケジュールして、ターゲット・データベースに対する最適なReplicatパフォーマンスを再開します。
スタンバイGGHubクラスタがクラッシュしてリカバリできない	影響: アプリケーションまたはレプリケーションに影響はありません。 GGHubクラスタが再起動可能な場合は、それが最も単純なソリューションであり、それによりACFSレプリケーションが再開されます。スタンバイGGHubがリカバリ不可能な場合は、新しいスタンバイGGHubを再構築することになります。	N/A
完全サイト障害	影響: アプリケーションの停止時間は、ほぼゼロです。GoldenGateレプリケーションは、新しいプライマリ・データベースが起動すると再開されます。 1つのプライマリ・データベースが引き続き使用できます。すべてのアクティビティは、アプリケーションの停止時間がゼロになるように、使用可能な既存のプライマリ・データベースにルーティングされます。Global Data Servicesのグローバル・サービス・フェイルオーバーのソリューションを参照してください。たとえば、アプリケーション・サービスのAからFはデータベースAにルーティングされていて、アプリケーション・サービスのGからJはデータベースBにルーティングされているとします。データベースAに障害が発生すると、すべてのサービスは一時的にデータベースBに移動するようになります。プライマリGGHubがまだ機能している場合は、GoldenGateレプリケーションが続行されます。サイトの障害が原因でプライマリGGHubが失われた場合は、手動によるGGhubフェイルオーバーが必要です。GoldenGateレプリケーションが再開され、プライマリ・データベースが再同期されます。データ損失は、Data Guard保護レベルによって制限されます。最大の可用性または保護が構成されている場合は、データ損失がゼロになります。すべてのコミットされたトランザクションは、一方または両方のデータベースにあります。ワークロードは、プライマリ・データベースAとデータベースBが使用可能であり同期状態にあるときにはリバランスできます。データベースAが稼働中で同期状態にある場合、サービスAからFはデータベースAに戻すことができます。	サイトの復帰時に、スタンバイの回復などの構成を再確立します。前のGGHubが最終的に再起動されると、ACFSレプリケーションは別の方向に自動的に再開されます。可能な場合は、Data Guardスイッチオーバー(フェイルバック)を実行して、各サイトに1つのプライマリ・データベースが存在する元の状態に戻します。 Replicatのパフォーマンスは、プライマリGGHubがターゲット・データベースと同じサイトに存在していないと低下するようになります。ACFSレプリケーション・スイッチオーバーによるGGHubスイッチオーバーをスケジュールして、ターゲット・データベースに対する最適なReplicatパフォーマンスを再開します。