Comparing Active-Active and Active-Passive Configurations
A common use case for Oracle GoldenGate is High Availability to reduce the downtime that occurs during planned or unplanned outages.
When implementing Oracle GoldenGate for this use case, you can configure active-active replication, where two or more databases are configured for read and write traffic from the application, or configure active-passive (also called Live Standby), where read and write traffic for the application should only connect to a single database at a time. This also ties in closely with Oracle’s Maximum Availability Architecture patterns of Gold and Platinum.
Using Oracle GoldenGate this way can reduce the Recovery Time Objective to zero for nearly any kind of outage.
Use the following guidelines to decide which method you should use for your application.
Both methods are configured similar to a unidirectional topology, where a replication stream is configured from a source to a target. However, the administrator will also configure replication from the target back to the source. This means that loop detection needs to be considered for any Extracts and Replicats involved in bidirectional replication. To learn about loop detection, see Enabling Bi-Directional Loop Detection. It also means that any active-passive or active-active topology can only be configured when the databases are certified for both capture and delivery. See the certification matrix to learn about the supported operating system and databases.Active-Active High Availability Purposes
-
During unplanned outages, users can be immediately connected to another database in the active-active environment.
-
For planned outages, you can slowly move users (or drain connections) over to another database prior to taking the server offline for a better user experience.
In both cases the Recovery Time Objective (RTO) is zero because the other database is already open for both read and write activity.
Oracle GoldenGate replication is asynchronous, so there could be a situation
where two transactions modify the same row at the same time on different databases. When
the system attempts to replicate these changes to the other server, it can create a
conflict. To resolve these conflicts, administrators need to be configure Oracle
GoldenGate using the COMPARECOLS / RESOLVECONFLICT
(CC/RC) options or using the Automatic Conflict Detection and Resolution (ACDR) feature,
which is only available in Oracle database. Both methods have some requirements and
recommendations to ensure smooth operation and eventual consistency of your data.
Oracle GoldenGate can support multiple active-active topologies including Data Mesh and Hub and Spoke models.
In a data mesh model, all databases are connected to each other. A mesh style works well when you have just a few databases, usually four or less.
GoldenGate Stream Analytics implements a data mesh platform, allowing you to visually construct data pipelines that perform continuous ETL or advanced analytics on any data that is moving in realtime windows that can be as small as 1 milliseconds. Using Stream Analytics, you can easily ingest data events from all database using Oracle GoldenGate.
See About Stream Analytics to know more.
In a hub and spoke model, each read-write database is a spoke, and sends data to the hub, the hub then sends data to all the other spokes. The hub-and-spoke model works better for large number of deployments, but due to the extra hop at the hub, the latency is higher which can cause additional conflicts.
For more information about configuring active-active replication with Oracle GoldenGate, refer to this technical paper: https://www.oracle.com/a/ocom/docs/ogg-best-practices-active-active.pdf.
Active-Passive for High Availability Purposes
In an active-passive environment, a bidirectional replication is configured but the application is only connected to one server at a time. In the event of an outage, you cannot connect to the other database until the Oracle GoldenGate Replicat has applied the last transaction, which means the RTO will be equal to the Oracle GoldenGate lag. Typical lag for Oracle GoldenGate is about 4-7 seconds, so this can achieve very low RTO values and because write activity will only happen on one database at a time, there is no need to worry about data collisions. Active-passive doesn’t have the application and schema restrictions that exist in an active-active application, so it can be used on third party applications like Siebel and PeopleSoft. A typical active-passive implementation is one passive database for each active database.
If your application can tolerate a few seconds of downtime (RTO of about 4-6 seconds) then it is recommended to use the active-passive architecture. It’s easier to implement and maintain, has fewer application and table dependencies, and will work for package applications. However, if you truly need an RTO of zero, then active-active should be the architecture.