As you know, in a RAC environment when creating a service, you can define preferred instances and available instances. In this case, the service will by default run on the preferred instance.
If for any reason the preferred instance fails, or the entire node becomes unavailable, the service will be moved to the available instance. Even after restarting the preferred instance, the service will not automatically fail back; it will continue running on the available instance. To move it back to the preferred instance, you need to manually perform a relocate operation.
Example:
In this example, we create a service named mysrv in Oracle 11g:
[grid@node1 ~]$ crsctl query crs releaseversion
Oracle High Availability Services release version on the local node is [11.2.0.4.0]
[oracle@node1 ~]$ srvctl add service -d mydb -s mysrv -r instance1 -a instance2
After creating the service, start it. You will see that the service is running on the preferred instance:
[oracle@node1 ~]$ srvctl start service -d mydb -s mysrv
[oracle@node1 ~]$ srvctl status service -d mydb -s mysrv
Service mysrv is running on instance(s) instance1
Question: What happens to this service if the preferred instance fails?
[oracle@node1 ~]$ srvctl stop instance –d mydb –I instance1 –f
By checking the status of the service, we can see that it has automatically failed over to the second instance:
[oracle@node1 ~]$ srvctl status service –d mydb –s mysrv
Service mysrv is running on instance(s) instance2
Even after restarting instance1, the service remains on instance2 and does not return to the preferred instance:
[oracle@node1 ~]$ srvctl start instance -d mydb -i instance1
[oracle@node1 ~]$ srvctl status service -d mydb -s mysrv
Service mysrv is running on instance(s) instance2
To manually relocate the service back to instance1, you can run the following command:
[oracle@node1 ~]$ srvctl relocate service -d mydb -s mysrv -i instance2 -t instance1
[oracle@node1 ~]$ srvctl status service -d mydb -s mysrv
Service mysrv is running on instance(s) instance1
As you can see, by executing the srvctl relocate service command, the service was moved from instance2 to instance1.
New in Oracle 19c: Automatic Failback
In Oracle 19c, a new parameter called failback was added to the srvctl add service command, enabling automatic relocation of a service back to its preferred instance under such circumstances.
Example:
We want to create two services, srv_nonfailback and srv_failback, where failback is only enabled for srv_failback:
[grid@node1 ~]$ crsctl query crs releaseversion
Oracle High Availability Services release version on the local node is [19.0.0.0.0]
[oracle@node1 ~]$ srvctl add service -d db19c -service srv_nonfailback -preferred instance1 -available instance2
[oracle@node1 ~]$ srvctl add service -d db19c -service srv_failback -preferred instance1 -available instance2 -failback YES
[oracle@node1 ~]$ srvctl config service -d db19c|egrep -i ‘Service name|instances’
Service name: srv_failback
Preferred instances: instance1
Available instances: instance2
Service name: srv_nonfailback
Preferred instances: instance1
Available instances: instance2
Start both services:
[oracle@node1 ~]$ srvctl start service -d db19c -s srv_nonfailback,srv_failback
[oracle@node1 ~]$ srvctl status service -d db19c -s srv_nonfailback,srv_failback
Service srv_nonfailback is running on instance(s) instance1
Service srv_failback is running on instance(s) instance1
Now, let’s test the behavior of both services by shutting down the first node completely with a reboot:
[root@node1 ~]# reboot
After the node goes down, both services are relocated to instance2:
[oracle@node2 ~]$ srvctl status service -d db19c
Service srv_failback is running on instance(s) instance2
Service srv_nonfailback is running on instance(s) instance2
When the first node comes back online, the service srv_failback automatically relocates back to its preferred instance (instance1), while srv_nonfailback continues to run on instance2:
[oracle@node1 ~]$ srvctl status service -d db19c
Service srv_failback is running on instance(s) instance1
Service srv_nonfailback is running on instance(s) instance2
Top comments (0)