Lifecycle

Different operations are performed on the system during its lifecycle. The most relevant ones are switching over and testing or opening the secondary for validations, patching, and so on.

Perform a Switchover

A switchover is a planned operation where an administrator reverts the roles of the two sites. After a switchover, the primary system becomes secondary and the secondary system becomes primary. Performing a switchover will cause downtime in the primary site.

A switchover is performed following the standard procedures (see Switchover in Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery and SOA Suite on Oracle Cloud Infrastructure Marketplace Disaster Recovery.).

1. Propagate any pending configuration changes per steps provided in "Setup Ongoing Configuration Replication".
2. Stop servers in primary site.
3. Switchover DNS names.
4. Switchover database.
5. Start the servers in secondary site.

The main difference is that only the Oracle Cloud Infrastructure (OCI) Console is used to switchover the Oracle Autonomous Database instance.

Note:

For Remote Refreshable Clones, if a permanent switchover is performed (if the secondary becomes primary beyond a non-permanent test or verification), then you must create a peer refreshable clone in the original primary region to have a secondary system for tests and validations in the new standby (originally primary). The refreshable clone in secondary will become un-reconnectable since its source will now be a standby (refreshable clones cannot be created, maintained, or connected from standby Oracle Autonomous Database Serverless). It isn't possible to refresh it again and, if needed, you can remove the database to reduce costs. For the creation of the new refreshable clone in the original primary (now standby), follow the same procedure as with the first one.

Perform the following steps for the switchover operation:

1. Disable any scheduled replication while the switchover is performed, since it may fail and interfere with the switchover operation itself.
2. Stop the servers in the primary site.
   Use the Oracle WebLogic Administration Server Console or scripts to stop the Oracle WebLogic Server instances in the primary site.

   Note:

   The Admin server in primary site can remain up during switchover. However, it is recommended to stop it when the site is in standby role because it is expected that the domain configuration in the standby site will be overridden by the primary configuration during the lifecycle. If the Admin server is up while this happen, it will be running with a stale configuration.
3. Switchover the front-end DNS name.

   Perform the required DNS push in the DNS server hosting the names used by the system or alter the file host resolution in clients to point the front-end virtual name of the system to the public IP used by the Load Balancer in the secondary site.

   For scenarios where DNS is used for the external front-end resolution (such as OCI DNS or commercial DNS), you can use an API to push the change. To see an example that pushes this change in an OCI DNS, go to GitHub for example scripts to update the front-end DNS.

   Note:

   The TTL value of the DNS entry will affect the RTO of the switchover: if the TTL is high (example, 20 min), the DNS change will take that time to be effective in the clients. Using lower TTL values will make this to be faster; however, this can cause an overhead because clients will hit the DNS more frequently instead of using cached names. A good approach is to set the TTL to a low value temporarily (for example, 1 min), before the change in the DNS. Then, perform the change, and once the switchover procedure is completed, revert the TTL to its original value again.
4. Log into the Oracle Cloud Infrastructure (OCI) Console for the SECONDARY REGION, then navigate to the Autonomous Database.
5. Select the compartment hosting the Oracle WebLogic database and click the database name.
6. Select Switchover from the More Actions drop down menu, then confirm entering the standby database name.
7. Wait for the operation to complete.

   The status appears in the Work Requests menu under Resources on the left.

8. Start the secondary Admin Server (or restart if it was already started, so the configuration changes that were replicated while this was standby take effect.)
9. Start secondary managed servers (using the Oracle WebLogic Server Console or scripts).

Perform a Failover

A failover operation is performed when the primary site becomes unavailable, and it is commonly an unplanned operation. You can role-transition a standby database to a primary database when the original primary database fails and there is no possibility of recovering the primary database in a timely manner.

There may or may not be data loss, depending upon whether your primary and target standby databases were consistent at the time of the primary database failure. A failover procedure is similar to a switchover procedure, but you perform a failover instead a switchover operation in the database.

Normally, a failover operation is executed when an outage affects the primary region. Therefore, there may be some tasks that you can’t perform in primary. For example, you may not be able to stop the Oracle WebLogic Server processes in primary because the hosts are unreachable.

1. If possible, stop the WebLogic servers in primary site.
2. Switchover DNS names.
3. Failover the database.

   Note:

   When you use Oracle Autonomous Database Serverless, the failover link only shows when the primary database is unavailable and a standby database is available. Using the API, you can initiate manual failover at any time
4. Start the servers in secondary site.
5. Once a failover operation is finished, and the previous primary site is reachable again, you must perform the following manual tasks to prepare the system for a future switchback.
   1. Stop the Oracle WebLogic Server processes in the failed site.
      If you didn’t stop them during the failover, the processes may be hung. Make sure they are stopped.
   2. For Oracle Autonomous Database Serverless, you don’t need to manually reinstate the failed primary.
      After a manual Oracle Autonomous Data Guard failover, the standby database is automatically reconnected or if required automatically (transparently) reprovisioned when the region comes back online.
      See Notes for Manual Failover with a Standby Database for details.
   3. For Oracle Autonomous Database on Dedicated Exadata Infrastructure, reinstate the failed container database to an enabled, standby role from its Details page.
      After a failover, the role of the Standby container database becomes Primary and the role of the Primary container database becomes Disabled Standby with the Unavailable state.
      See Fail Over to the Standby in an Autonomous Data Guard Configuration for details.
   4. Verify the correct execution of the configuration replica (from the new primary to the new standby).