19c RAC : Dynamic Cluster Services

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

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

#reboot

#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