Planning GGHub Placement in the Platinum MAA Architecture

Extreme availability that delivers zero downtime (RTO=0 or near zero) and zero or near zero data loss (RPO=0 or near zero) typically requires the following Platinum MAA architecture.

You have the source and target database in an Oracle GoldenGate architecture to allow your application to fail over immediately in the case of disaster (database, cluster, or site failure) or switch over in the case of a database or application upgrade. This architecture enables the potential RTO of zero or near zero for disaster scenarios and database and application upgrade maintenance.
Each source and target database is deployed in Exadata cloud systems so any local failures are tolerated or recovered almost instantly.
Each source and target database is configured with a standby database with Data Guard Fast-Start Failover so any failure of the database results in activating a new primary database in seconds to minutes. If SYNC transport is leveraged with Max Availability protection mode, zero data loss Data Guard failover is achieved.
Configured with GoldenGate replication using MAA GGhub between the source and target databases.
Configured so that any standby becoming a primary database due to Data Guard switchover or failover will automatically resynchronize with its target GoldenGate database. If zero data loss Data Guard switchover or failover occurs, GoldenGate resychronization ensures zero data loss across the distributed database environment.
Configured with GoldenGate Automatic Conflict Detection and Resolution, which is required after any Data Guard failover operation occurs.

Where to Place the MAA Primary GGHub and Standby GGHub

The GGHub Pair (Primary and Standby GGHub) must reside in the same OCI regions as each primary and standby database. For example:
1. If the primary database is in AD1, Region A, and the standby database is in AD2, Region A, then the GGHub pair will reside in Region A.
2. If the primary database is in Region A and the standby database is in Region B, then the GGHub pair will split between Region A and B. The primary, or active, GGHub must be co-located in the same OCI region as the target primary database.
Performance implications:
1. Primary or active GGHub must reside in the same data center as the target database to ensure round trip latency of 4ms or less. (Replicat performance)
2. Primary or active GGHub should be < 90 ms from the source database without incurring GoldenGate performance degradation. (Extract performance)
GoldenGate distribution path:
1. A GoldenGate distribution path is required if the source and target GGHubs are in different regions and latency between the OCI regions is > 90 ms.
2. In Oracle Cloud, when your Oracle GoldenGate source and target databases reside in the same region, or in different regions in the same country, you never need to set up a GoldenGate distribution path because the latency is always < 90 ms.

MAA GGHubs Placed in the Same OCI Region

In this scenario, the primary and standby database are located in the same OCI region, and so the primary (active) GGHub and the standby GGHub are also located in the same region.

The following architectural components comprise the GGHubs, as shown in the image below:

Primary database and associated standby database are configured with Oracle Active Data Guard Fast Start Failover (FSFO). FSFO can be configured with any Data Guard protection mode, with ASYNC or SYNC redo transport, depending on your maximum data loss tolerance.
Primary GGHub Active/Passive Cluster: Only one GGHub software deployment and configuration on the 2-node cluster. This cluster contains the 21c Oracle GoldenGate software deployment that can support Oracle Database 11g (11.2.0.4) and later releases.

This GGHub can support many primary databases and encapsulates the GoldenGate processes. GoldenGate Extract mines transactions from the source database and GoldenGate Replicat applies the same changes to target database. GoldenGate trail and checkpoint files also reside in the GGhub ACFS file system.

The HA failover solution is built in to the GGhub, which includes automatic failover to the passive node in the same cluster, and restarts GoldenGate processes and activity after a node failure.
Standby GGHub Active/Passive Cluster: A Symmetric standby GGhub is configured. ACFS replication is set up between the primary and standby GGHubs to preserve all GoldenGate files.

Manual GGhub failover, which includes ACFS failover, can be performed in the rare case that you lose the entire primary GGhub.

Figure 20-1 Primary and Standby GGHubs in the Same OCI Region

The figure above depicts data replicated from Primary Database A to Primary Database B and Primary B back to Primary A with the following steps:

Primary Database A: Primary A’s Logminer server sends redo changes to a Primary GGHub Extract process.
Primary GGHub: An Extract process writes changes to trail files.
Primary GGHub to Primary Database B: A Primary GGHub Replicat process applies those changes to the target database (Primary B).
Primary Database B: Primary B’s Logminer server sends redo to a Primary GGHub Extract process.
Primary GGHub: A Primary GGHub Extract process writes changes to trail files.
Primary GGHub to Primary Database A: A Primary GGHub Replicat process applies those changes to the target database (Primary A).

Note that one GGHub can support multiple source and target databases, even when the source and target databases are different Oracle Database releases.

Table 20-1 Outage Scenarios, Repair, and Restoring Redundancy for GGHubs in the Same OCI Region

Outage Scenario	Application Availability and Repair	Restoring Redundancy and Pristine State
Primary Database A (or Database B) failure	Impact: Near-zero application downtime. GoldenGate replication resumes when a new primary database starts. One primary database is still available. All activity is routed to the existing available primary database to achieve zero application downtime. Refer to Global Data Service Global Services Failover solution. For example, application services A-F are routed to Database A and application services G-J are routed to Database B. If Database A fails, all application services temporarily go to Database B. The standby becomes the new primary automatically with Data Guard FSFO. Oracle GoldenGate replication resumes and the primary databases resynchronize. Data loss is bounded by the Data Guard protection level. If Maximum Availability or Maximum Protection is configured, zero data loss is achieved. All committed transactions are in one or both databases. Workload can be “rebalanced” when Primary Database A and Database B are available and in sync. For example, when Database A is up and running and in sync, services A-F can go back to Database A.	The old primary database is reinstated as the new standby database to restore redundancy. Optionally performing a Data Guard switchover to switch back to the original configuration ensures that at least one primary database resides in an independent AD.
Primary or standby GGHub single node failure	Impact: No application impact. GoldenGate replication resumes automatically after a couple of minutes. No action is required. The HA failover solution built in to the GGHub includes automatic failover and restart of GoldenGate processes and activity. Replication activity is blocked until GoldenGate processes are active again. GoldenGate replication blackout could last a couple of minutes.	Once the node restarts, active/passive configuration is re-established.
Primary GGHub cluster crashes and is not recoverable	Impact: No application impact. GoldenGate replication resumes after restarting the existing GGHub or performing a manual GGHub failover operation. If the GGHub cluster can be restarted, then that’s the simplest solution. If the primary GGHub is not recoverable, then perform a manual GGHub failover to the standby GGHub, which includes ACFS failover. This typically takes several minutes. GoldenGate replication stops until the new primary GGhub is available, so performing step 1 or step 2 should take little time.	If the previous GGHub eventually restarts, ACFS replication resumes in the other direction automatically. If the GGHub cluster is lost or unrecoverable, you need to rebuild a new standby GGHub.
Standby GGHub cluster crashes and not recoverable	Impact: No application or replication impact. If the GGHub cluster can be restarted, then that is the simplest solution, and ACFS replication can resume. If the standby GGHub is not recoverable, you can rebuild a new standby GGHub.	N/A
Complete Data Center or Availability Domain (AD1 or AD2) failure	Impact: Near-zero application downtime. GoldenGate replication resumes when the new primary database starts. One primary database is still available. All activity is routed to the existing available primary database to achieve zero application downtime. Refer to Global Data Service Global Services Failover solution. For example, application services A-F are routed to Database A and application services G-J are routed to Database B. If Database A fails, all services temporarily go to Database B. If the primary GGHub is still functional, GoldenGate replication continues. If the primary GGHub is lost due to availability domain (AD) failure, then a manual GGhub failover is required. GoldenGate replication resumes and the primary databases resynchronize. Data loss is bounded by the Data Guard protection level. If Maximum Availability or Maximum Protection is configured, zero data loss is achieved. All committed transactions are in one or both databases. Workload can be rebalanced when Primary Database A and Database B are available and in sync. When Database A is up and running and in sync, services A-F can go back to Database A.	When the data center/AD returns, re-establish the configuration, such as reinstate standby. If the previous GGHub eventually restarts, ACFS replication resumes in the other direction automatically. When possible, perform a Data Guard switchover (back) to get back to the original state where one primary database exists in each AD.

MAA GGHubs Placed in Different OCI Regions

In this scenario, the primary and standby database are located in different OCI regions, so the primary (active) GGHub is located in the same region as the primary database, and the standby GGHub is located in the same region as the standby database.

The following architectural components comprise the GGHubs, as shown in the image below:

The primary database and associated standby database are configured with Oracle Active Data Guard Fast Start Failover (FSFO). FSFO can be configured with any Data Guard protection mode, with ASYNC or SYNC redo transport, depending on your maximum data loss tolerance.
Primary GGHub Active/Passive Cluster: In this configuration, there’s a 2-node cluster with two Oracle GoldenGate software configurations. Because the primary GGHub needs to be <= 4 ms from the target database, and the two regions (PHX and ASH) network latency > 5 ms, two GGHub configurations are created for each GGHub cluster. Essentially, a primary GGHub configuration will always be in the same region as the target database.

GGHub is configured with the Oracle GoldenGate 21c software deployment that can support Oracle Database 11g and later releases. This GGHub can support many primary databases and encapsulates the GoldenGate processes. Extract mines transactions from the source database, and Replicat applies those changes to the target database. GoldenGate trail and checkpoint files also reside in the ACFS file system.

An HA failover solution is built in to the GGHub cluster, which includes automatic failover and restart of GoldenGate processes and activity after a node failure.

Each GGHub configuration contains a GoldenGate service manager and deployment, ACFS file system with ACFS replication, and separate application VIP.
Standby GGHub Active/Passive Cluster: A symmetric standby GGHub is configured. ACFS replication is set up between the primary and standby GGHubs to preserve all GoldenGate files.

Manual GGHub failover, which includes ACFS failover, can be performed if you lose the entire primary GGHub.

Figure 20-2 Primary and Standby GGHubs in Different OCI Regions

The figure above depicts replicating data from Primary Database A to Primary Database B, and Primary B back to Primary A with the following steps:

Primary Database A: Primary A’s Logminer server sends redo changes to an ASH region GGHub Extract process, which is on the Primary GGHub for Database A.
Primary GGHub: The Extract process writes changes to trail files.
Primary GGHub to Primary Database B: An ASH region GoldenGate Replicat process applies those changes to the target database (Primary B).
Primary Database B: Primary B’s Logminer server sends redo to a PHX region GGHub Extract process, which is on the Primary GGHub for Database B.
Primary GGHub: The Extract process writes changes to trail files.
Primary GGHub to Primary Database A: A PHX region GoldenGate Replicat process applies those changes to the target database (Primary A).

Table 20-2 Outage Scenarios, Repair, and Restoring Redundancy for GGHubs in Different OCI Regions

Outage Scenario	Application Availability and Repair	Restoring Redundancy and Pristine State
Primary Database A (or Database B) failure	Impact: Near-zero application downtime. GoldenGate replication resumes when the new primary database starts. One primary database is still available. All activity is routed to the existing available primary database to achieve zero application downtime. Refer to the Global Data Services Global Services Failover solution. For example, application services A-F are routed to Database A, and application services G-J are routed to Database B. If Database A fails, all services temporarily go to Database B. The standby becomes the new primary automatically with Data Guard FSFO. GoldenGate replication resumes and the primary databases resynchronize. Data loss is bounded by the Data Guard protection level. If Maximum Availability or Maximum Protection is configured, zero data loss is achieved. All committed transactions are in one or both databases. Workload can be rebalanced when primary Database A and Database B are available and in sync. For example, when Database A is up and running and in sync, services A-F can go back to Database A. Replicat performance will be degraded if the primary GGHub is not in the same region as the target database. Schedule a GGHub switchover with ACFS replication switchover to resume optimal Replicat performance to the target database. You may then experience two active GGHub configurations on the same GGHub cluster.	The old primary database is reinstated as the new standby database to restore redundancy. Optionally performing a Data Guard switchover, to switch back to the original configuration, ensures that at least one primary database resides in an independent AD. Schedule a GGHub switchover with ACFS replication switchover to resume optimal Replicat performance to the target database.
Primary or standby GGHub single node failure	Impact: No application impact. GoldenGate replication resumes automatically after a couple of minutes. No action is required. An HA failover solution is built in to the GGHub that includes automatic failover and restart of GoldenGate processes and activity. Replication activity is blocked until GoldenGate processes are active again. GoldenGate Replication blackout could last a couple of minutes.	Once the node restarts, active/passive configuration is re-established.
Primary GGHub cluster crashes and is not recoverable	Impact: No application impact. GoldenGate replication resumes after the existing primary GGHub restarts or manual GGHub failover completes. If the GGHub cluster can be restarted, then that’s the simplest solution. If the primary GGHub is not recoverable, then perform a manual GGHub failover to the standby GGHub, which includes ACFS failover. This typically takes several minutes. Replication stops until the new primary GGhub is started, so performing step 1 or step 2 should take little time. If there’s any orchestration, this should be automated.	If the previous GGHub eventually restarts, ACFS replication resumes in the other direction automatically. If the GGHub cluster is lost or unrecoverable, you need to rebuild a new standby GGHub. Replicat performance is degraded if the primary GGHub is not in the same region as the target database. Schedule a GGHub switchover with ACFS replication switchover to resume optimal Replicat performance to the target database.
Standby GGHub cluster crashes and is not recoverable	Impact: No application or replication impact. If the GGHub cluster can be restarted, then that’s the simplest solution, and ACFS replication will resume. If the standby GGHub is not recoverable, you can rebuild a new standby GGHub.	N/A
Complete Regional failure	Impact: Near Zero Application Downtime. GoldenGate replication resumes when the new primary database starts. One primary database is still available. All activity is routed to the existing available primary database to achieve zero application downtime. Refer to the Global Data Services Global Services Failover solution. For example, application services A-F routed to Database A and application services G-J routed to Database B. If Database A fails, all services will temporarily go to Database B. If the primary GGHub is still functional, GoldenGate replication will continue. If the primary GGHub is lost due to regional failure, then a manual GGHub failover is required. GoldenGate replication resumes and the primary databases resynchronize. Data loss is bounded by the Data Guard protection level. If Maximum availability or protection is configured, zero data loss is achieved. All committed transactions are in one or both databases. Workload can be rebalanced when Primary Database A and Database B are available and in sync. When Database A is up and running and in sync, services A-F can go back to Database A.	When the OCI region returns, re-establish configuration such as reinstate standby. If the previous GGHub eventually restarts, ACFS replication resumes in the other direction automatically. When possible, perform a Data Guard switchover (failback) to get back to the original state where one primary database exists in each region. Replicat performance is degraded if the primary GGHub is not in the same region as the target database. Schedule a GGHub switchover with ACFS replication switchover to resume optimal Replicat performance to the target database.