Disaster Recovery EARLY ACCESS

Fail over to a replica cluster in case of unplanned outages

Use xCluster Disaster Recovery (DR) to recover from an unplanned outage (failover) or to perform a planned switchover. Planned switchover is commonly used for business continuity and disaster recovery testing, and failback after a failover.

A DR configuration consists of the following:

  • a DR primary cluster, which serves both reads and writes.
  • a DR replica cluster, which can also serve reads.

RPO and RTO for failover and switchover

Data from the DR primary is replicated asynchronously to the DR replica (which is read only). Due to the asynchronous nature of the replication, DR failover results in non-zero recovery point objective (RPO). In other words, data not yet committed on the DR replica can be lost during a failover. The amount of data loss depends on the replication lag, which in turn depends on the network characteristics between the clusters. By contrast, during a switchover RPO is zero, and no data is lost, because the switchover waits for all data to be committed on the DR replica before switching over.

The recovery time objective (RTO) for failover or switchover is very low, and determined by how long it takes applications to switch their connections from one cluster to another. Applications should be designed in such a way that the switch happens as quickly as possible.

DR further allows for the role of each cluster to switch during planned switchover and unplanned failover scenarios.

Disaster recovery

xCluster DR vs xCluster Replication

 

Set up Disaster Recovery
Designate a cluster to act as a DR replica.
Unplanned failover
Fail over to the DR replica in case of an unplanned outage.
Planned switchover
Switch over to the DR replica for planned testing and failback.
Add and remove tables and indexes
Perform DDL changes to databases in replication.

Schema changes

Table and index-level schema changes must be performed in the same order as follows:

  1. The DR primary cluster.
  2. The DR replica cluster.

You don't need to make any changes to the DR configuration.

To learn more, refer to Manage tables and indexes

Limitations

  • Currently, automatic replication of DDL (SQL-level changes such as creating or dropping tables or indexes) is not supported. For more details on how to propagate DDL changes from the DR primary to the DR replica, see Manage tables and indexes.

  • If a database operation requires a full copy, any application sessions on the database on the DR target will be interrupted while the database is dropped and recreated. Your application should either retry connections or redirect reads to the DR primary.