1. Global Data Services Concepts and Administration
  2. Global Data Services Failover Across Regions Flow

Global Data Services Failover Across Regions Flow

To fail over GDS services across regions, perform database switchover, start secondary apps, update/flush DNS, route traffic.

  1. The administrator has failed over or switched the production database to the secondary site. This is automatic if you are using Data Guard fast-start failover.
  2. The administrator starts the middle-tier application servers on the secondary site if they are not already running.
  3. The wide-area traffic manager selection of the secondary site can be automatic in the case of an entire site failure. The wide-area traffic manager at the secondary site returns the virtual IP address of a load balancer at the secondary site, and clients are directed automatically on the subsequent reconnect. In this scenario, the site failover is accomplished by an automatic domain name system (DNS) failover.

  4. Alternatively, a DNS administrator can manually change the wide-area traffic manager selection to the secondary site for the entire site or specific applications.

    The following is an example of a manual DNS failover:

    • Change the DNS to point to the secondary site load balancer: The primary (primary) DNS server is updated with the new zone information, and the change is announced with DNS NOTIFY.
    • The secondary DNS servers are notified of the zone update with a DNS NOTIFY announcement, and the secondary DNS servers pull the new zone information.
    • Clear affected records from caching DNS servers.

    A caching DNS server is used primarily for performance and fast response. The caching server obtains information from an authoritative DNS server in response to a host query and then saves (caches) the data locally. On a second or subsequent request for the same data, the caching DNS server responds with its locally stored data (the cache) until the response's time-to-live (TTL) value expires. At this time, the server refreshes the data from the zone master. If the DNS record is changed on the primary DNS server, then the caching DNS server does not pick up the change for cached records until TTL expires. Flushing the cache forces the caching DNS server to go to an authoritative DNS server again for the updated DNS information.

    • Flush the cache if the DNS server being used supports such a capability. The following is the flush capability of standard DNS BIND versions:
    • BIND 9.3.0: The command rndc flushname name flushes individual entries from the cache.
    • BIND 9.2.0 and 9.2.1: The cache can be flushed with the command rndc flush .
    • BIND 8 and BIND 9 up to 9.1.3: Restarting the named server clears the cache.
  5. Refresh local DNS service caching.

    Some operating systems might cache DNS information locally in the local name service cache. If so, this cache must also be cleared to recognize DNS updates quickly.

  6. The secondary site load balancer directs traffic to the secondary site middle-tier application server.

Parent topic: Managing Global Services