By default, VIPs and database services automatically fail over to a surviving instance in the case of a crash or node eviction. The RAC VIP will automatically fail back to its home node once the failed database instance restarts. VIPs and database services can also be manually relocated, perhaps for maintenance reasons, allowing a node to be taken offline without affecting user connections to the database.
The following code shows how to relocate a database service using srvctl:
srvctl status service -d OLTP -s ACTIVE_SRV Service ACTIVE_SRV is running on instance(s) OLTP2 srvctl relocate service -d OLTP -s ACTIVE_SRV -i OLTP2 -t OLTP1 $ srvctl status service -d OLTP -s ACTIVE_SRV Service ACTIVE_SRV is running on instance(s) OLTP1
In addition to the database servers, Oracle GI can also be installed on other nodes to form a single cluster. For example, in the case of six nodes, four can be used as database servers and two additional nodes for GoldenGate. The Oracle database would run on four nodes and GoldenGate would run on one of the remaining two nodes, with failover configured to its dedicated twin. Due to the GoldenGate Manager and data pump processes, which are configured to use the GoldenGate application VIP, the failover will be automatic across the two dedicated nodes and will always be available to connect to a database instance on the four node RAC.
When the GoldenGate VIP is configured, it can run on any single node in the cluster. Unlike the RAC VIP, it does not automatically fail back, and if necessary, it can be manually relocated. The following sections discuss the various methods of manual failover.
- Once the GoldenGate application and VIP are registered with the GI, we can manually fail over to another node. This is achieved by the DBA logged in to a node in the cluster as the
oracleuser and executing the followingcrsctlcommand. This will force a failover of both the application and VIP from node1to node2in the following example:$GRID_HOME/bin/crsctl relocate resource xag.ogg_1-vip.vip –n rac2 -fThe
-foption forces the online process to relocate. Without this, a warning is given and no action is taken. The following screenshot shows thestdoutmessages and commands:
- It is also possible to perform the same operation using the XAG
agctlutility, as shown in the following command. However, nostdoutis returned if the command succeeds:$GRID_HOME/bin/agctl relocate goldengate ogg_1 --node rac2
This is exactly what happens automatically when a node crashes or gets evicted from the cluster. The GoldenGate Manager process is restarted on the surviving node. Here, its configuration autostarts the Extract and Replicat processes.
We discussed GoldenGate topologies in Chapter 1, Getting Started, which included the active-active configuration. This particular architecture lends itself to high availability by providing an alternative system that users can fail over to.
The GoldenGate active-active HA architecture
Under the normal operation, the database is available to the application at Site A and Site B. Both databases are kept in synchronization by GoldenGate's bidirectional-changed data capture and delivery mechanism. Should one site fail, application logic will enable failover to the surviving system. The options and considerations are discussed in the Chapter 7, Advanced Configuration.
Oracle RAC is one of the most popular database configurations, which was first introduced in Oracle 9i, superseding Oracle Parallel Server. GoldenGate plays a major role in the Oracle 12c RAC environment, especially with the advent of Oracle's engineered solutions that feature Infiniband networks. Such configurations provide a fast, robust, and highly available OLTP and OLAP solution in the same Oracle-Sun equipment rack.
In this chapter, you learned how to configure GoldenGate on Oracle RAC, leveraging high availability through clusterware configuration techniques and explored the shared storage solutions available in the Oracle 12c Grid Infrastructure.
We also discovered the importance of failover within a cluster, which relocates the GoldenGate Manager process to the surviving node. This restores data replication to downstream systems, all in the name of HA.
In the next chapter, you will learn how to leverage the advanced configuration features of GoldenGate, enabling you to tailor the product to meet your specific solution requirements. This includes data selection and filtering, data transformation, macro and token definitions, and calling stored procedures and User Exits to extend GoldenGate's functionality and flexibility.