GridGain Developers Hub
GitHub logo GridGain iso GridGain.com
GridGain Software Documentation

GoldenGate Replication

Oracle GoldenGate Integration provides a solution for real-time integration and replication of all your GoldenGate compatible data-sources and your GridGain cluster. When GoldenGate integration replication is configured, GridGain will automatically receive updates from the configured GoldenGate source database while at the same time transforming the data from source to GridGain compatible cache objects. GoldenGate also enables high availability and disaster tolerance with core functionality that supports real-time data integration, while preserving performance and ensuring scalability.

Roles

These are the main roles in GoldenGate Replication process: source DB, extractor, trails and GridGainHandler (GoldenGate Java Adapter).

  • Source DB - Database that contains the data to be replicated.

  • Extractor - This process runs on the source system and is the data-capture mechanism of GoldenGate. It can be configured for both initial loading of the source data as well as to synchronize the changed data on the source with the target. This can also be configured to propagate any DDL changes on those databases where DDL change support is available.

  • Trails - These are series of files that GoldenGate stores on disks and these files are written to and read from by the Extract processes. Depending on the configuration chosen, these trail files can exist on the source as well as on the target systems.

GoldenGate replication has the following accessible scheme:

Replication to GridGain cluster on source side
and target side

Features

Batching

Updates from the source database can be performed in different modes. If the replication is done in tx mode, updates are first accumulated by the transaction and then populated to cache in batches.

Failover

GridGain Handler supports failover. If the GoldenGate handle fails during processing or replication stops for some reason, GridGain Handler restarts processing from the last successfully processed transaction.

Conflict Resolution

In active-active scenarios, updates to a key in the cache occurring from multiple sources is called a conflict. To ensure a consistent conflict resolution across different data centers, users can plug in their own implementation of conflict resolver. See Conflicts Resolution for more information.