v2024.2 LTS Stable release with long-term support v2.23 Preview Preview release - not for production v2024.1 STS Stable release with standard-term support v2.20 LTS Stable release with long-term support v2.18 STS Stable release with standard-term support v2.14 LTS Stable release with long-term support Unsupported versions

xCluster Replication

Active universe with standby using xCluster deployment

xCluster Replication is an asynchronous replication feature in YugabyteDB that allows you to replicate data between independent YugabyteDB universes. You can set up unidirectional (master-follower) or bidirectional (multi-master) replication between two data centers:

  • Source - contains the original data that is subject to replication.
  • Target - recipient of the replicated data.

xCluster asynchronous replication

You can use xCluster Replication to implement disaster recovery for YugabyteDB. This is a good option where you have only two regions available, or the higher write latency of a global database is a problem. You do need to tolerate some small possibility of data loss due to asynchronous replication. xCluster Disaster Recovery (DR) adds high-level orchestration workflows to xCluster Replication to make end-to-end setup, switchover, and failover for disaster recovery simple and turnkey. For more details on using xCluster for disaster recovery, see xCluster Disaster Recovery.

xCluster Replication can be used to move data from one YugabyteDB universe to another for purposes other than disaster recovery. For example, downstream YugabyteDB universes used for reporting or "green" deployments of blue-green deployments can be kept asynchronously up to date with the main YugabyteDB universe.

You can use YugabyteDB Anywhere to set up xCluster Replication, monitor the status of replication, and manage changes to the replication when new databases or tables are added to the replication.

xCluster configurations

xCluster Replication supports the following replication configurations:

  • Transactional YSQL
  • Non-transactional YCQL/YSQL
  • Non-transactional bidirectional

For YSQL databases, transactional is recommended. This mode guarantees atomicity and consistency of transactions. The target universe is made read-only in this mode. If the target universe needs to support write operations, YSQL replication can be configured to use the non-transactional mode. However, this comes at the expense of SQL ACID guarantees. For more information on the inconsistencies that can arise with non-transactional YSQL, refer to Inconsistencies affecting transactions.

For YCQL databases, only non-transactional replication is supported.

Bidirectional replication refers to setting up xCluster Replication between two YSQL databases or YCQL tables on different universes in both directions, so that writes on either database or table can be replicated to the other database or table. Certain xCluster management operations need special attention in this case. See Bidirectional replication.

For more information about transactional and non-transactional modes, see Asynchronous replication modes.

Blog: Can Distributed Databases Achieve Transactional Consistency on Async Standbys? Yes, They Can.
Video: YFTT - Transactional xCluster
Set up xCluster Replication
Designate a universe to act as a source.
Manage tables and indexes
Perform DDL changes to databases in replication.
Bidirectional
Configure bidirectional replication.

Limitations

  • Currently, replication of DDL (SQL-level changes such as creating or dropping tables or indexes) is not supported. To make these changes requires first performing the DDL operation (for example, creating a table), and then adding the new object to replication in YugabyteDB Anywhere. In addition, xCluster does not support truncate operations. Refer to Manage tables and indexes.

  • xCluster Replication setup (and other operations that require making a full copy from source to target) forcefully drop the tables on the target if they exist before performing the restore.

    If there are any open SQL connections to the database on the target, they will be interrupted and you should retry the connection.

  • You can't add individual YSQL tables to replication; when adding YSQL tables or during xCluster setup, you must select the YSQL database with the tables you want, and all tables in a selected database are added to the replication.

    To be eligible for xCluster Replication, YSQL tables must not already be in replication. That is, the table can't already be in another xCluster configuration between the same two universes in the same direction. If a YSQL database includes tables considered ineligible for replication, the database as a whole cannot be replicated.

  • Setting up xCluster Replication between a universe earlier than or upgraded to v2.20.x, and a new v2.20.x universe is not supported. This is due to a limitation of xCluster deployments and packed rows. See Packed row limitations.

  • You can set up change data capture on a source universe in xCluster Replication, but not a target.

  • xCluster Replication is not supported for materialized views.

For more information on the YugabyteDB xCluster implementation and its limitations, refer to xCluster implementation limitations.