High-availability of database services has been a feature of Oracle Real Application Servers since many versions. Basically, when a database instance fails, a service which has got this instance as a preferred instance, fails over to another available instance.
Unfortunately, the service did not fail back to the original instance as soon as the instance is up again.
The administrator had to relocate the service
OR Needs to configure the fan callout script
You can refer my old blog post – fan-callouts-for-rac
This has changed with Oracle Database 19c.
Starting with Oracle Database release 19.3, if you specify yes for the -failback attribute of a service,
then, after failing over to an available instance when the last preferred instance went down, the service
transfers back to a preferred instance when one becomes available. For earlier releases, you can automate
fail back to the preferred instance by using FAN callouts.
Dynamic Services Fallback Option
For a dynamic database service that is placed using “preferred” and “available” settings,
you can now specify that this service should fall back to a “preferred” instance when it becomes
available if the service failed over to an available instance.
The Dynamic Services Fallback Option allows for more control in placing dynamic database services
and ensures that a given service is available on a preferred instance as long as possible.
#Create serv19c Service inside the acs pluggable database.
srvctl add service -db cdb -pdb acs -service serv19c -preferred cdb1 -available cdb2 -failback YES
#Review the configuration of pdb
-bash-4.2$ srvctl config service -db cdb -service serv19c Service name: serv19c Server pool: Cardinality: 1 Service role: PRIMARY Management policy: AUTOMATIC DTP transaction: false AQ HA notifications: false Global: false Commit Outcome: false Failover type: Failover method: Failover retries: Failover delay: Failover restore: NONE Connection Load Balancing Goal: LONG Runtime Load Balancing Goal: NONE TAF policy specification: NONE Edition: Pluggable database name: acs Hub service: Maximum lag time: ANY SQL Translation Profile: Retention: 86400 seconds Failback : true Replay Initiation Time: 300 seconds Drain timeout: Stop option: Session State Consistency: DYNAMIC GSM Flags: 0 Service is enabled Preferred instances: cdb1 Available instances: cdb2 CSS critical: no
#Review the status of service
-bash-4.2$ srvctl status service -db cdb -service serv19c Service serv19c is not running. #Starting the service -bash-4.2$ srvctl start service -db cdb -service serv19c #Review the status of service -bash-4.2$ srvctl status service -db cdb -service serv19c Service serv19c is running on instance(s) cdb1
#From Node1 we will reboot the machine1
#From Node2 review the status of service
-bash-4.2$ srvctl status service -db cdb -service serv19c Service serv19c is running on instance(s) cdb2
#Once Node1 is comes back in Cluster Service are automatically failback. 🙂
-bash-4.2$ srvctl status service -db cdb -service serv19c Service serv19c is running on instance(s) cdb1
Thank you for visiting this blog.