A typical way of configuring GoldenGate replication to an Oracle RAC database in on-premises environments relies on configuring a Clusterware service and a virtual IP for GoldenGate. This allows the GoldenGate service to be highly available by moving between the nodes of the cluster.
In a default FlashGrid cluster setup virtual IPs are on the "public" network that is isolated from the rest of the cloud network and from the other clusters. Therefore, it is not possible to access a virtual IP from outside of the cluster.
Options for configuring highly available Oracle GoldenGate replication to a database on FlashGrid cluster:
- Configure both Extract and Replicat on the target cluster. Recommended for replication between two FlashGrid clusters.
- Configure Passive Extract. Recommended for replication to FlashGrid cluster from a standalone database or from an on-prem RAC cluster.
- Use GoldenGate Hub on a separate cluster
- Use FlashGrid cluster VIP Manager service
- Connect two clusters in one CLAN network
Configure both Extract and Replicat on the target cluster
This method is recommended for replication between two FlashGrid clusters. By running Extract on the target cluster we completely avoid the need to have a VIP for GoldenGate on the target cluster. Note that this method requires configuring appropriate data access permissions for the Extract user connecting to the source database.
Example of configuring GoldenGate with Extract on the target can be found here: Example of configuring GoldenGate with Extract on target
Configure Passive Extract
This method is recommended for replication to FlashGrid cluster from a standalone database or from an on-prem RAC cluster. In such configuration the GoldenGate connection is established from the target cluster instead of the source cluster. As a result, there is no need for GoldenGate VIP on the target cluster.
Please follow Oracle documentation https://docs.oracle.com/goldengate/1212/gg-winux/GWUAD/wu_security.htm#GWUAD386
Use GoldenGate Hub on a separate cluster
Oracle GoldenGate Hub is an architectural concept that places the Oracle GoldenGate software on separate server(s). It can be used to offload GoldenGate processing and management from the database cluster to a separate cluster. The main advantages of such a configuration:
- Can be configured with GI XAG (standalone agent) for GoldenGate service HA and can initiate connection to databases without relying on HA VIP.
- Offloads database servers. Most GoldenGate processes run on dedicated servers without competing for resources with the databases.
- The GoldenGate servers can be scaled up or down independently of database servers.
- Simplifies troubleshooting in case of errors or performance issues.
- Software updates, configuration and maintenance tasks can be done independently on GoldenGate and database systems.
Use FlashGrid cluster VIP Manager service
This method is available if the first two methods are not practical for some reason. It allows exposing the GoldenGate VIP to the hosts outside of the cluster. Note that additional routing configuration is required at the VPC/VNet level. Contact FlashGrid support if you need to use this method.
Connect two clusters in one CLAN network
This method is available if the first three methods are not practical for some reason. It allows having the same "public" network between two clusters with full transparency of VIPs. However, it is recommended only if replications needs to be done between no more than three clusters. It also requires upfront planning at the cluster deployment stage to ensure that all clusters use non-overlapping IP addresses on the shared public network. Contact FlashGrid support if you need to use this method.
Note that standard best practices for configuring GoldenGate are sufficient if any of the following is true:
- the target database is not on FlashGrid cluster (e.g. standalone database in the cloud or RAC on-premises),
- or replication is done between two databases within the same FlashGrid cluster,
- or GoldenGate service failover is not required (service tied to one node only).