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

xCluster deployment

Unidirectional (master-follower) and bidirectional (multi-master) replication

By default, YugabyteDB provides synchronous replication and strong consistency across geo-distributed data centers. However, many use cases do not require synchronous replication or justify the additional complexity and operating costs associated with managing three or more data centers. A cross-cluster (xCluster) deployment provides asynchronous replication across two data centers or cloud regions. Using an xCluster deployment, you can use unidirectional (master-follower) or bidirectional (multi-master) asynchronous replication between two universes (aka data centers).

For information on xCluster deployment architecture, replication scenarios, and limitations, refer to xCluster architecture.

Deploy transactional xCluster
Set up transactional unidirectional replication.
Deploy non-transactional xCluster
Set up non-transactional unidirectional or bidirectional replication.

Prerequisites

  • If the root certificates for the source and target clusters are different, (for example, the node certificates for target and source nodes were not created on the same machine), copy the ca.crt for the source cluster to all target nodes, and vice-versa. If the root certificate for both source and target clusters is the same, you can skip this step.

    Locate the ca.crt file for the source cluster on any node at <base-dir>/certs/ca.crt. Copy this file to all target nodes at <base-dir>/certs/xcluster/<replication-id>/. The <replication-id> must be the same as you configured in Step 1.

    Similarly, copy the ca.crt file for the target cluster on any node at <base-dir>/certs/ca.crt to source cluster nodes at <base-dir>/certs/xcluster/<replication-id>/.

  • Global objects like users, roles, tablespaces are not managed by xCluster. You must explicitly create and manage these objects on both source and target universes.

Best practices

  • Set the YB-TServer cdc_wal_retention_time_secs flag to 86400 on both source and target universe.

    This flag determines the duration for which WAL is retained on the source universe in case of a network partition or a complete outage of the target universe. The value depends on how long a network partition of the source cluster or an outage of the target cluster can be tolerated.

  • Make sure all YB-Master and YB-Tserver flags are set to the same value on both the source and target universes.

  • Monitor CPU usage and ensure it remains below 65%. Note that xCluster replication typically incurs a 20% CPU overhead.

  • Monitor disk space usage and ensure it remains below 65%. Allocate sufficient disk space to accommodate WALs generated based on the cdc_wal_retention_time_secs setting, which is higher than the default log_min_seconds_to_retain value.