1. 高可用性概要およびベスト・プラクティス
  2. MAA PlatinumおよびOracle GoldenGateのベスト・プラクティス
  3. クラウド: MAA Platinum用Oracle GoldenGate Hubの構成
  4. Platinum MAAアーキテクチャでのGGHub配置の計画

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

停止時間をゼロ(RTO=0またはほぼゼロ)にし、データ損失をゼロまたはほぼゼロ(RPO=0またはほぼゼロ)にする極限の可用性を実現するには、通常、次に示すPlatinum MAAアーキテクチャが必要です。

  1. Oracle GoldenGateアーキテクチャには、障害(データベース、クラスタまたはサイト障害)の発生時にアプリケーションをただちにフェイルオーバーできるように、またはデータベースやアプリケーションのアップグレード時にスイッチオーバーできるようにするために、ソース・データベースとターゲット・データベースがあります。このアーキテクチャにより、障害シナリオやデータベースおよびアプリケーションのアップグレードの保守に対して、潜在的なRTOをゼロまたはほぼゼロにできます。

  2. 各ソースおよびターゲット・データベースは、Exadataクラウド・システムにデプロイされるため、ローカルの障害は許容されるかほぼ瞬時にリカバリされます。

  3. 各ソースおよびターゲット・データベースは、Data Guardファスト・スタート・フェイルオーバーを備えたスタンバイ・データベースとともに構成されているため、データベースに障害が発生すると数秒から数分で新しいプライマリ・データベースがアクティブ化されます。最大可用性保護モードのSYNC転送を利用すると、データ損失ゼロのData Guardフェイルオーバーが実現されます。

  4. ソースおよびターゲット・データベースの間にMAA GGhubを使用するGoldenGateレプリケーションを使用して構成されます。

  5. Data Guardのスイッチオーバーまたはフェイルオーバーによってプライマリ・データベースになるスタンバイが、自動的にターゲットのGoldenGateデータベースと再同期するように構成されます。データ損失ゼロのData Guardスイッチオーバーまたはフェイルオーバーが発生した場合は、GoldenGateの再同期により、分散データベース環境全体のデータ損失がゼロになります。

  6. GoldenGateの自動競合検出および解決を使用して構成されます。これは、Data Guardのフェイルオーバー操作の発生後に必要です。

MAAプライマリGGHubとスタンバイGGHubを配置する場所

  1. GGHubペア(プライマリおよびスタンバイGGHub)は、プライマリ・データベースおよびスタンバイ・データベースそれぞれと同じOCIリージョンに存在する必要があります。たとえば:

    1. プライマリ・データベースがAD1、リージョンAにあり、スタンバイ・データベースがAD2、リージョンAにある場合、GGHubペアはリージョンAに存在します。

    2. プライマリ・データベースがリージョンAにあり、スタンバイ・データベースがリージョンBにある場合、GGHubペアはリージョンAとリージョンBに分かれます。プライマリ(またはアクティブ)GGHubは、ターゲットのプライマリ・データベースと同じOCIリージョンに共同配置されている必要があります。

  2. パフォーマンスへの影響:

    1. プライマリ(またはアクティブ)GGHubは、ラウンド・トリップ待機時間が必ず4ミリ秒以下になるように、ターゲット・データベースと同じデータ・センターに存在する必要があります。(Replicatのパフォーマンス)

    2. プライマリ(またはアクティブ)GGHubは、GoldenGateのパフォーマンス低下が発生することのない、ソース・データベースから90ミリ秒未満に収める必要があります。(Extractのパフォーマンス)

  3. GoldenGate分散パス:

    1. ソースGGHubとターゲットGGHubが別々のリージョンにあり、OCIリージョン間の待機時間が90ミリ秒を超える場合は、GoldenGate分散パスが必要になります。

    2. Oracle Cloudでは、Oracle GoldenGateのソース・データベースとターゲット・データベースが同じリージョンに、または同じ国にある別々のリージョンに存在する場合は、待機時間が常に90ミリ秒未満になるため、GoldenGate分散パスを設定する必要はありません。

同じOCIリージョン内に配置されたMAA GGHub

このシナリオでは、プライマリとスタンバイのデータベースは同じOCIリージョンに配置されるため、プライマリ(アクティブ)GGHubとスタンバイGGHubも同じリージョンに配置されます。

次のアーキテクチャ・コンポーネントは、次の図に示すように、複数のGGHubからなります。

  1. プライマリ・データベースおよび関連付けられたスタンバイ・データベースは、Oracle Active Data Guardファスト・スタート・フェイルオーバー(FSFO)によって構成されています。FSFOは、データ損失の最大許容度に応じて、ASYNCまたはSYNC REDO転送を使用するどのData Guard保護モードでも構成できます。

  2. プライマリGGHubアクティブ/パッシブ・クラスタ: 2ノード・クラスタに1つのみのGGHubソフトウェア・デプロイメントと構成があります。このクラスタには、Oracle Database 11g (11.2.0.4)以降のリリースをサポートできる、21c Oracle GoldenGateソフトウェア・デプロイメントが含まれています。

    このGGHubでは、多数のプライマリ・データベースをサポートでき、GoldenGateプロセスがカプセル化されます。GoldenGate Extractによってソース・データベースからトランザクションがマイニングされ、GoldenGate Replicatによって同じ変更内容がターゲット・データベースに適用されます。GoldenGate証跡ファイルとチェックポイント・ファイルも、GGhub ACFSファイル・システムに存在します。

    HAフェイルオーバー・ソリューションはGGhubに組み込まれています。このソリューションには、同じクラスタ内のパッシブ・ノードへの自動フェイルオーバーが含まれていて、ノード障害後にGoldenGateプロセスとアクティビティを再起動します。

  3. スタンバイGGHubアクティブ/パッシブ・クラスタ: 対称スタンバイGGhubが構成されています。ACFSレプリケーションは、すべてのGoldenGateファイルを保持するために、プライマリとスタンバイのGGHubの間に設定されています。

    手動によるGGhubフェイルオーバー(ACFSフェイルオーバーを含む)は、プライマリGGhub全体が失われるというまれなケースで実行することになります。

図19-1 同じOCIリージョン内のプライマリおよびスタンバイGGHub


gghub-one-region

上の図は、次の手順でプライマリ・データベースAからプライマリ・データベースBにデータをレプリケートして、プライマリBからプライマリAに戻している様子を示しています。

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

ソースとターゲットのデータベースが異なるOracle Databaseリリースであっても、1つのGGHubで複数のソース・データベースとターゲット・データベースをサポートできます。

表19-1 同じOCIリージョン内のGGHubの停止シナリオ、修復および冗長性のリストア

停止シナリオ アプリケーションの可用性と修復 冗長性と初期状態の復元
プライマリ・データベースA (またはデータベースB)の障害

影響: アプリケーション停止時間は、ほぼゼロです。GoldenGateレプリケーションは、新しいプライマリ・データベースの起動時に再開されます。

  1. 1つのプライマリ・データベースが引き続き使用できます。すべてのアクティビティは、アプリケーションの停止時間がゼロになるように、使用可能な既存のプライマリ・データベースにルーティングされます。Global Data Servicesのグローバル・サービス・フェイルオーバーのソリューションを参照してください。たとえば、アプリケーション・サービスのAからFはデータベースAにルーティングされ、アプリケーション・サービスのGからJはデータベースBにルーティングされているとします。データベースAに障害が発生すると、すべてのアプリケーション・サービスは一時的にデータベースBに移動します。
  2. スタンバイは、Data Guard FSFOによって自動的に新しいプライマリになります。Oracle GoldenGateレプリケーションが再開され、プライマリ・データベースが再同期されます。データ損失は、Data Guard保護レベルによって制限されます。最大可用性または最大保護が構成されている場合は、データ損失がゼロになります。すべてのコミットされたトランザクションは、一方または両方のデータベースにあります。ワークロードは、プライマリ・データベースAとデータベースBが使用可能であり、同期状態にあるときには「リバランス」できます。たとえば、データベースAが稼働中で同期状態にある場合、サービスAからFはデータベースAに戻すことができます。
  1. 元のプライマリ・データベースは、冗長性をリストアするために新しいスタンバイ・データベースとして回復されます。
  2. オプションで、Data Guardスイッチオーバーを実行して元の構成に戻すと、1つ以上のプライマリ・データベースが個別のAD内に存在するようにします。
プライマリまたはスタンバイGGHubの単一ノード障害

影響: アプリケーションに影響はありません。GoldenGateレプリケーションは、数分後に自動的に再開されます。

処置は必要ありません。GGHubに組み込まれたHAフェイルオーバー・ソリューションには、GoldenGateプロセスとアクティビティの自動フェイルオーバーと再起動が含まれます。レプリケーション・アクティビティは、GoldenGateプロセスが再度アクティブになるまでブロックされます。GoldenGateレプリケーションのブラックアウトは数分間続くことがあります。

ノードが再起動すると、アクティブ/パッシブ構成が再確立されます。
プライマリGGHubクラスタがクラッシュしてリカバリできない

影響: アプリケーションに影響はありません。GoldenGateレプリケーションは、既存のGGHubの再起動後、または手動によるGGHubフェイルオーバー操作の実行後に再開されます。

  1. GGHubクラスタの再起動が可能な場合は、それが最も単純なソリューションです。
  2. プライマリGGHubがリカバリ不可の場合は、スタンバイGGHubへの手動によるGGHubフェイルオーバー(ACFSフェイルオーバーを含む)を実行します。これには通常、数分かかります。
  3. GoldenGateレプリケーションは、新しいプライマリGGhubを使用できるようになるまで停止されます。そのため、ステップ1またはステップ2の実行には多少時間がかかります。
 前のGGHubが最終的に再起動されると、ACFSレプリケーションは別の方向に自動的に再開されます。GGHubクラスタが損なわれた場合やリカバリ不能になった場合は、新しいスタンバイGGHubを再構築する必要があります。
スタンバイGGHubクラスタがクラッシュしてリカバリできない

影響: アプリケーションまたはレプリケーションに影響はありません。

  1. GGHubクラスタが再起動可能な場合は、それが最も単純なソリューションであり、ACFSレプリケーションを再開できます。
  2. スタンバイGGHubがリカバリ不可能な場合は、新しいスタンバイGGHubを再構築することになります。
 N/A
データ・センターまたは可用性ドメイン(AD1またはAD2)の全体的な障害

影響: アプリケーション停止時間は、ほぼゼロです。GoldenGateレプリケーションは、新しいプライマリ・データベースの起動時に再開されます。

  1. 1つのプライマリ・データベースが引き続き使用できます。すべてのアクティビティは、アプリケーションの停止時間がゼロになるように、使用可能な既存のプライマリ・データベースにルーティングされます。Global Data Servicesのグローバル・サービス・フェイルオーバーのソリューションを参照してください。たとえば、アプリケーション・サービスのAからFはデータベースAにルーティングされ、アプリケーション・サービスのGからJはデータベースBにルーティングされているとします。データベースAに障害が発生すると、すべてのサービスは一時的にデータベースBに移動します。
  2. プライマリGGHubがまだ機能している場合、GoldenGateレプリケーションは続行されます。可用性ドメイン(AD)の障害が原因でプライマリGGHubが損なわれた場合は、手動によるGGhubフェイルオーバーが必要です。GoldenGateレプリケーションが再開され、プライマリ・データベースが再同期されます。データ損失は、Data Guard保護レベルによって制限されます。最大可用性または最大保護が構成されている場合は、データ損失がゼロになります。すべてのコミットされたトランザクションは、一方または両方のデータベースにあります。ワークロードは、プライマリ・データベースAとデータベースBが使用可能であり同期状態にあるときにはリバランスできます。データベースAが稼働中で同期状態にある場合、サービスAからFはデータベースAに戻すことができます。
  1. データ・センター/ADの復帰時に、構成を再確立します(スタンバイの回復など)。前のGGHubが最終的に再起動されると、ACFSレプリケーションは別の方向に自動的に再開されます。
  2. 可能な場合は、Data Guardスイッチオーバー(バック)を実行して、ADごとに1つのプライマリ・データベースが存在する元の状態に戻します。

異なるOCIリージョン内に配置されたMAA GGHub

このシナリオでは、プライマリ・データベースとスタンバイ・データベースが別々のOCIリージョンに配置されているため、プライマリ(アクティブ)GGHubはプライマリ・データベースと同じリージョンに配置され、スタンバイGGHubはスタンバイ・データベースと同じリージョンに配置されます。

次のアーキテクチャ・コンポーネントは、次の図に示すように、複数のGGHubからなります。

  1. プライマリ・データベースおよび関連付けられたスタンバイ・データベースは、Oracle Active Data Guardファスト・スタート・フェイルオーバー(FSFO)によって構成されています。FSFOは、データ損失の最大許容度に応じて、ASYNCまたはSYNC REDO転送を使用するどのData Guard保護モードでも構成できます。

  2. プライマリGGHubアクティブ/パッシブ・クラスタ: この構成には、2つのOracle GoldenGateソフトウェア構成を備えた2ノード・クラスタがあります。プライマリGGHubはターゲット・データベースから4ミリ秒以下にする必要がありますが、2つのリージョン(PHXとASH)のネットワーク待機時間は5ミリ秒を超えるため、GGHubクラスタごとに2つのGGHub構成が作成されています。基本的に、プライマリGGHub構成は常にターゲット・データベースと同じリージョンにあります。

    GGHubは、Oracle Database 11g以降のリリースをサポートできる、Oracle GoldenGate 21cソフトウェア・デプロイメントで構成されています。このGGHubでは、多数のプライマリ・データベースをサポートでき、GoldenGateプロセスがカプセル化されます。Extractによってソース・データベースからトランザクションがマイニングされ、Replicatによってそれらの変更内容がターゲット・データベースに適用されます。GoldenGate証跡ファイルとチェックポイント・ファイルも、ACFSファイル・システムに存在します。

    GGHubクラスタに組み込まれているHAフェイルオーバー・ソリューションには、ノード障害発生後のGoldenGateプロセスおよびアクティビティの自動フェイルオーバーと再起動が含まれています。

    それぞれのGGHub構成に、GoldenGateサービス・マネージャおよびデプロイメント、ACFSレプリケーションを使用するACFSファイル・システム、および別個のアプリケーションVIPが含まれています。

  3. スタンバイGGHubアクティブ/パッシブ・クラスタ: 対称スタンバイGGHubが構成されています。ACFSレプリケーションは、すべてのGoldenGateファイルを保持するために、プライマリとスタンバイのGGHubの間に設定されています。

    手動によるGGHubフェイルオーバー(ACFSフェイルオーバーを含む)は、プライマリGGHub全体が失われた場合に実行することになります。

図19-2 異なるOCIリージョン内のプライマリおよびスタンバイGGHub


異なるOCIリージョン内のプライマリおよびスタンバイGGHub

上の図は、次の手順でプライマリ・データベースAからプライマリ・データベースBにデータをレプリケートして、プライマリBからプライマリAに戻している様子を示しています。

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

表19-2 異なるOCIリージョン内のGGHubの停止シナリオ、修復および冗長性のリストア

停止シナリオ アプリケーションの可用性と修復 冗長性と初期状態の復元
プライマリ・データベースA (またはデータベースB)の障害

影響: アプリケーション停止時間は、ほぼゼロです。GoldenGateレプリケーションは、新しいプライマリ・データベースの起動時に再開されます。

  1. 1つのプライマリ・データベースが引き続き使用できます。すべてのアクティビティは、アプリケーションの停止時間がゼロになるように、使用可能な既存のプライマリ・データベースにルーティングされます。Global Data Servicesのグローバル・サービス・フェイルオーバーのソリューションを参照してください。たとえば、アプリケーション・サービスのAからFはデータベースAにルーティングされ、アプリケーション・サービスのGからJはデータベースBにルーティングされているとします。データベースAに障害が発生すると、すべてのサービスは一時的にデータベースBに移動します。

  2. スタンバイは、Data Guard FSFOによって自動的に新しいプライマリになります。GoldenGateレプリケーションが再開され、プライマリ・データベースが再同期されます。データ損失は、Data Guard保護レベルによって制限されます。最大可用性または最大保護が構成されている場合は、データ損失がゼロになります。すべてのコミットされたトランザクションは、一方または両方のデータベースにあります。ワークロードは、プライマリ・データベースAとデータベースBが使用可能であり同期状態にあるときにはリバランスできます。たとえば、データベースAが稼働中で同期状態にある場合、サービスAからFはデータベースAに戻すことができます。
  3. Replicatのパフォーマンスは、プライマリGGHubがターゲット・データベースと同じリージョンに存在していないと低下するようになります。ACFSレプリケーション・スイッチオーバーによるGGHubスイッチオーバーをスケジュールして、ターゲット・データベースに対する最適なReplicatパフォーマンスを再開します。その結果、同じGGHubクラスタ上に2つのアクティブなGGHub構成が存在する場合があります。

  1. 元のプライマリ・データベースは、冗長性をリストアするために新しいスタンバイ・データベースとして回復されます。

  2. オプションで、Data Guardスイッチオーバーを実行し、元の構成に戻すことで1つ以上のプライマリ・データベースが個別のAD内に存在するようにします。ACFSレプリケーション・スイッチオーバーによるGGHubスイッチオーバーをスケジュールして、ターゲット・データベースに対する最適なReplicatパフォーマンスを再開します。
プライマリまたはスタンバイGGHubの単一ノード障害

影響: アプリケーションに影響はありません。GoldenGateレプリケーションは、数分後に自動的に再開されます。

処置は必要ありません。GGHubに組み込まれたHAフェイルオーバー・ソリューションには、GoldenGateプロセスとアクティビティの自動フェイルオーバーおよび再起動が含まれます。レプリケーション・アクティビティは、GoldenGateプロセスが再度アクティブになるまでブロックされます。GoldenGateレプリケーションのブラックアウトは数分間続くことがあります。

ノードが再起動すると、アクティブ/パッシブ構成が再確立されます。
プライマリGGHubクラスタがクラッシュしてリカバリできない

影響: アプリケーションに影響はありません。GoldenGateレプリケーションは、既存のプライマリGGHubの再起動後または手動によるGGHubフェイルオーバーの完了後に再開されます。

  1. GGHubクラスタの再起動が可能な場合は、それが最も単純なソリューションです。
  2. プライマリGGHubがリカバリ不可の場合は、スタンバイGGHubへの手動によるGGHubフェイルオーバー(ACFSフェイルオーバーを含む)を実行します。これには通常、数分かかります。
  3. レプリケーションは、新しいプライマリGGhubが起動されるまで停止されます。そのため、ステップ1またはステップ2の実行には多少時間がかかります。オーケストレーションが存在する場合、これは自動化する必要があります。
  1. 前のGGHubが最終的に再起動されると、ACFSレプリケーションは別の方向に自動的に再開されます。GGHubクラスタが損なわれた場合やリカバリ不能になった場合は、新しいスタンバイGGHubを再構築する必要があります。

  2. Replicatのパフォーマンスは、プライマリGGHubがターゲット・データベースと同じリージョンに存在していないと低下します。ACFSレプリケーション・スイッチオーバーによるGGHubスイッチオーバーをスケジュールして、ターゲット・データベースに対する最適なReplicatパフォーマンスを再開します。
スタンバイGGHubクラスタがクラッシュしてリカバリできない

影響: アプリケーションまたはレプリケーションに影響はありません。

  1. GGHubクラスタが再起動可能な場合は、それが最も単純なソリューションであり、それによりACFSレプリケーションが再開されます。
  2. スタンバイGGHubがリカバリ不可能な場合は、新しいスタンバイGGHubを再構築することになります。
 N/A
リージョン全体の障害

影響: アプリケーションの停止時間は、ほぼゼロです。GoldenGateレプリケーションは、新しいプライマリ・データベースの起動時に再開されます。

  1. 1つのプライマリ・データベースが引き続き使用できます。すべてのアクティビティは、アプリケーションの停止時間がゼロになるように、使用可能な既存のプライマリ・データベースにルーティングされます。Global Data Servicesのグローバル・サービス・フェイルオーバーのソリューションを参照してください。たとえば、アプリケーション・サービスのAからFはデータベースAにルーティングされていて、アプリケーション・サービスのGからJはデータベースBにルーティングされているとします。データベースAに障害が発生すると、すべてのサービスは一時的にデータベースBに移動するようになります。
  2. プライマリGGHubがまだ機能している場合は、GoldenGateレプリケーションが続行されます。リージョンの障害が原因でプライマリGGHubが失われた場合は、手動によるGGHubフェイルオーバーが必要です。GoldenGateレプリケーションが再開され、プライマリ・データベースが再同期されます。データ損失は、Data Guard保護レベルによって制限されます。最大の可用性または保護が構成されている場合は、データ損失がゼロになります。すべてのコミットされたトランザクションは、一方または両方のデータベースにあります。ワークロードは、プライマリ・データベースAとデータベースBが使用可能であり同期状態にあるときにはリバランスできます。データベースAが稼働中で同期状態にある場合、サービスAからFはデータベースAに戻すことができます。
  1. OCIリージョンの復帰時に、スタンバイの回復などの構成を再確立します。前のGGHubが最終的に再起動されると、ACFSレプリケーションは別の方向に自動的に再開されます。

  2. 可能な場合は、Data Guardスイッチオーバー(フェイルバック)を実行して、各リージョンに1つのプライマリ・データベースが存在する元の状態に戻します。

  3. Replicatのパフォーマンスは、プライマリGGHubがターゲット・データベースと同じリージョンに存在していないと低下します。ACFSレプリケーション・スイッチオーバーによるGGHubスイッチオーバーをスケジュールして、ターゲット・データベースに対する最適なReplicatパフォーマンスを再開します。