In the previous blog post, we talked about GDS load balancing use cases. In this post, we will take a look at the role-based global service failover across databases – upon Data Guard role transition.

GDS is quite effective in achieving higher availability and improved manageability for the global services running on replicated databases. It takes into account configured global service placement policies while performing the service failover across databases.

Global services can be configured with a role attribute allowing specific services to be active only when the configured role matches the specific role of the database (primary, physical standby, snapshot standby, logical standby etc.).  Figure 1A depicts replicated databases in a GDS Configuration. Read Write service runs on the primary database while the Read Only service runs on the standby database. As illustrated in Figure 1B, when role transition happens in Data Guard Broker configuration, GDS relocates the global services automatically as per the role attribute. In the event when the last standby database in a Pool goes down, the Read Only service with the ‘Standby’ role can also be configured to failover to the primary.

 

Figure 1A: Role-based global services

Figure 1B: Automatic relocation of global services upon Data Guard role transition

To achieve this capability, you would define the global services as shown below.

GDSCTL>add service -service order_entry_srvc -gdspool sales  –preferred_all –role PRIMARY

GDSCTL>add service -service reporting_srvc -gdspool sales  –preferred_all –role PHYSICAL_STANDBY –failover_primary

It is as simple as that. There is no need to write custom logic or database startup triggers to achieve this behavior.

In the next blog post, we will study the global service failover use case for Oracle GoldenGate.