---
title: "Set up transactional xCluster"
url: "https://docs.yugabyte.com/stable/deploy/multi-dc/async-replication/async-transactional-setup-automatic/"
---

# Set up transactional xCluster

Automatic setup of transactional (active-active single-master) replication between two universes

Set up transactional xCluster replication

- [Automatic](/stable/deploy/multi-dc/async-replication/async-transactional-setup-automatic/)
- [Semi-Automatic](/stable/deploy/multi-dc/async-replication/async-transactional-setup-semi-automatic/)
- [Fully Manual](/stable/deploy/multi-dc/async-replication/async-transactional-setup-manual/)

Note

To use automatic-mode transactional xCluster replication, both the Primary and Standby universes must be running v2025.2.1 or later.

Automatic transactional xCluster replication handles all aspects of replication for both data and schema changes.

In particular, DDL changes made to the Primary universe are automatically replicated to the Standby universe.

Warning

Not all DDLs can be automatically replicated yet; see [XCluster Limitations](/stable/architecture/docdb-replication/async-replication/#limitations "XCluster Limitations").

In this mode, xCluster replication operates at the YSQL database granularity. This means you only run xCluster management operations when adding and removing databases from replication, and not when tables in the databases are created or dropped.

## Set up Automatic mode replication

Before setting up xCluster replication, ensure you have reviewed the [Prerequisites](/stable/deploy/multi-dc/async-replication/#prerequisites "Prerequisites") and [Best practices](/stable/deploy/multi-dc/async-replication/#best-practices "Best practices").

DDLs must be paused on the Primary universe during the entire setup process. [#26053](https://github.com/yugabyte/yugabyte-db/issues/26053)

- [![Server Icon](/icons/database.svg) Yugabyted](#yugabyted)
- [Manual](#local)

The following assumes you have set up Primary and Standby universes. Refer to [Set up universes](/stable/deploy/multi-dc/async-replication/async-deployment/#set-up-universes "Set up universes").

1. Create a checkpoint on the Primary universe for all the databases that you want to be part of the replication.
   
   ```sh
   ./bin/yugabyted xcluster create_checkpoint \
       --replication_id <replication_id> \
       --databases <comma_separated_database_names> \
       --automatic_mode
   ```
   
   The command informs you how to perform the needed bootstraps -- databases must always be bootstrapped in automatic mode. For example:
   
   ```output
   +-------------------------------------------------------------------------+
   |                                yugabyted                                |
   +-------------------------------------------------------------------------+
   | Status               : xCluster create checkpoint success.              |
   | Bootstrapping        : Bootstrap is required for database `yugabyte`.   |
   +-------------------------------------------------------------------------+
   For each database which requires bootstrap run the following commands to perform a backup and restore.
    Run on source:
   ./yugabyted backup --cloud_storage_uri <AWS/GCP/local cloud storage uri>  --database <database_name> --base_dir <base_dir of source node>
    Run on target:
   ./yugabyted restore --cloud_storage_uri <AWS/GCP/local cloud storage uri>  --database <database_name> --base_dir <base_dir of target node>
   ```
2. Perform a full copy of the database(s) on the Primary to the Standby using distributed [backup](/stable/reference/configuration/yugabyted/#backup "backup") and [restore](/stable/reference/configuration/yugabyted/#restore "restore").
   
   A full copy is needed here: it is not sufficient to just set up the same schemas on both sides via DDLs, even if there is no data. That will not properly set up some internal metadata including Postgres OIDs.
3. Enable [point-in-time recovery (PITR)](/stable/manage/backup-restore/point-in-time-recovery/enable-pitr/ "point-in-time recovery (PITR)") on the database(s) on both the Primary and Standby universes:
   
   ```sh
   ./bin/yugabyted configure point_in_time_recovery \
       --enable \
       --retention <retention_period> \
       --database <database_name>
   ```
   
   The `retention_period` must be greater than the amount of time you expect the Primary universe to be down before it self recovers or before you perform a failover to the Standby universe.
4. Set up the xCluster replication.
   
   ```sh
   ./bin/yugabyted xcluster set_up \
       --target_address <ip_of_any_target_cluster_node> \
       --replication_id <replication_id> \
       --bootstrap_done
   ```
   
   You should see output similar to the following:
   
   ```output
   +-----------------------------------------------+
   |                   yugabyted                   |
   +-----------------------------------------------+
   | Status        : xCluster set-up successful.   |
   +-----------------------------------------------+
   ```

The following assumes you have set up Primary and Standby universes. Refer to [Set up universes](/stable/deploy/multi-dc/async-replication/async-deployment/#set-up-universes "Set up universes").

1. Create a checkpoint using the `create_xcluster_checkpoint` command, providing a name for the replication group, and the names of the databases to replicate as a comma-separated list.
   
   ```sh
   ./bin/yb-admin \
       --master_addresses <primary_master_addresses> \
       create_xcluster_checkpoint \
       <replication_group_id> \
       <comma_separated_namespace_names> \
       automatic_ddl_mode
   ```
   
   Note that automatic mode always requires bootstrapping databases so you will need to backup and restore the databases. Sample command output:
   
   ```output
   Waiting for checkpointing of database(s) to complete
   Checkpointing of yugabyte completed. Bootstrap is required for setting up xCluster replication
   Successfully checkpointed databases for xCluster replication group repl_group1
   Perform a distributed Backup of database(s) [yugabyte] and Restore them on the target universe
   Once the above step(s) complete run 'setup_xcluster_replication'
   ```
   
   You can also manually check the status as follows:
   
   ```sh
   ./bin/yb-admin \
   --master_addresses 127.0.0.1:7100,127.0.0.2:7100,127.0.0.3:7100 \
   is_xcluster_bootstrap_required repl_group1 yugabyte
   ```
   
   You should see output similar to the following:
   
   ```output
   Waiting for checkpointing of database(s) to complete
   Checkpointing of yugabyte completed. Bootstrap is required for setting up xCluster replication
   ```
2. Perform a full copy of the database on the Primary to the Standby using distributed backup and restore. See [Distributed snapshots for YSQL](/stable/manage/backup-restore/snapshot-ysql/ "Distributed snapshots for YSQL").
   
   A full copy is needed here: it is not sufficient to just set up the same schemas on both sides via DDLs, even if there is no data. That will not properly set up some internal metadata including Postgres OIDs.
3. Enable [point in time restore (PITR)](/stable/admin/yb-admin/#create-snapshot-schedule "point in time restore (PITR)") on the database(s) on both the Primary and Standby universes:
   
   ```sh
   ./bin/yb-admin \
       --master_addresses <standby_master_addresses> \
       create_snapshot_schedule \
       <snapshot-interval> \
       <retention-time> \
       <ysql.database_name>
   ```
   
   The `retention-time` must be greater than the amount of time you expect the Primary universe to be down before it self recovers or before you perform a failover to the Standby universe.
4. Set up the xCluster replication group.
   
   ```sh
   ./bin/yb-admin \
   --master_addresses <primary_master_addresses> \
   setup_xcluster_replication \
   <replication_group_id> \
   <standby_master_addresses>
   ```
   
   You should see output similar to the following:
   
   ```output
   xCluster Replication group repl_group1 setup successfully
   ```

## Monitor replication

For information on monitoring xCluster replication, refer to [Monitor xCluster](/stable/launch-and-manage/monitor-and-alert/xcluster-monitor/ "Monitor xCluster").

## Add a database to a replication group

The database should have at least one table in order to be added to replication. If it is a colocated database then there should be at least one colocated table in the database in order for it to be added to replication.

- [![Server Icon](/icons/database.svg) yugabyted](#yugabyted-add-db)
- [Manual](#local-add-db)

<!--THE END-->

1. Create a checkpoint on the Primary universe for all the databases that you want to add to an existing replication group.
   
   ```sh
   ./bin/yugabyted xcluster add_to_checkpoint \
       --replication_id <replication_id> \
       --databases <comma_separated_database_names>
   ```
   
   You should see output similar to the following:
   
   ```output
   Waiting for checkpointing of database to complete
   Successfully checkpointed database db2 for xCluster replication group repl_group1
   Bootstrap is not required for adding database to xCluster replication
   Create equivalent YSQL objects (schemas, tables, indexes, ...) for the database in the standby universe
   ```
2. If bootstrapping is required, perform a full copy of the database(s) on the Primary to the Standby using distributed [backup](/stable/reference/configuration/yugabyted/#backup "backup") and [restore](/stable/reference/configuration/yugabyted/#restore "restore"). If your source database is not empty or you are using automatic mode, it must be bootstrapped.
3. Enable [point-in-time recovery (PITR)](/stable/manage/backup-restore/point-in-time-recovery/enable-pitr/ "point-in-time recovery (PITR)") on the database(s) on both the Primary and Standby universes:
   
   ```sh
   ./bin/yugabyted configure point_in_time_recovery \
       --enable \
       --retention <retention_period> \
       --database <database_name>
   ```
   
   The `retention_period` must be greater than the amount of time you expect the Primary universe to be down before it self recovers or before you perform a failover to the Standby universe.
4. Add the databases to the xCluster replication.
   
   ```sh
   ./bin/yugabyted xcluster add_to_replication \
       --databases <comma_separated_database_names> \
       --replication_id <replication_id> \
       --target_address <IP-of-any-target-node> \
       --bootstrap_done
   ```

<!--THE END-->

1. Create a checkpoint.
   
   ```sh
   ./bin/yb-admin \
   --master_addresses <primary_master_addresses> \
   add_namespace_to_xcluster_checkpoint <replication_group_id> <namespace_name>
   ```
   
   You should see output similar to the following:
   
   ```output
   Waiting for checkpointing of database to complete
   Successfully checkpointed database db2 for xCluster replication group repl_group1
   Bootstrap is not required for adding database to xCluster replication
   Create equivalent YSQL objects (schemas, tables, indexes, ...) for the database in the standby universe
   ```
2. If bootstrapping is required, perform a full copy of the database(s) on the Primary to the Standby using distributed [backup](/stable/reference/configuration/yugabyted/#backup "backup") and [restore](/stable/reference/configuration/yugabyted/#restore "restore"). If your source database is not empty or you are using automatic mode, it must be bootstrapped.
3. Enable [point-in-time recovery (PITR)](/stable/manage/backup-restore/point-in-time-recovery/enable-pitr/ "point-in-time recovery (PITR)") on the database(s) on both the Primary and Standby universes:
   
   ```sh
   ./bin/yb-admin \
       --master_addresses <standby_master_addresses> \
       create_snapshot_schedule 1 10 ysql.yugabyte
   ```
4. Set up the database using the checkpoint.
   
   ```sh
   ./bin/yb-admin \
   --master_addresses <primary_master_addresses> \
   add_namespace_to_xcluster_replication <replication_group_id> <namespace_name> <standby_master_addresses>
   ```
   
   You should see output similar to the following:
   
   ```output
   Successfully added db2 to xCluster Replication group repl_group1
   ```

## Remove a database from a replication group

- [![Server Icon](/icons/database.svg) yugabyted](#yugabyted-remove-db)
- [Manual](#local-remove-db)

To remove a database from a replication group, use the following command:

```sh
./bin/yugabyted xcluster remove_database_from_replication \
    --databases <comma_separated_database_names> \
    --replication_id <replication_id> \
    --target_address <ip_of_any_target_cluster_node>
```

```sh
./bin/yb-admin \
-master_addresses <primary_master_addresses> \
remove_namespace_from_xcluster_replication <replication_group_id> <namespace_name> <standby_master_addresses>
```

You should see output similar to the following:

```output
Successfully removed db2 from xCluster Replication group repl_group1
```

Warning

If you want the databases being removed from replication on the target to be usable after dropping replication, you need to stop your workload (including performing DDLs) to them and wait for the replication lag to reach zero before dropping the replication group.

If you take no precautions then the target databases may be unusable; we strongly recommend dropping such databases rather than attempting to use them.

## Drop xCluster replication group

- [![Server Icon](/icons/database.svg) yugabyted](#yugabyted-drop)
- [Manual](#local-drop)

To drop a replication group, use the following command:

```sh
./bin/yugabyted xcluster delete_replication \
    --replication_id <replication_id> \
    --target_address <ip_of_any_target_cluster_node>
```

To drop a replication group, use the following command:

```sh
./bin/yb-admin \
-master_addresses <primary_master_addresses> \
drop_xcluster_replication <replication_group_id> <standby_master_addresses>
```

You should see output similar to the following:

```output
Outbound xCluster Replication group rg1 deleted successfully
```

Be careful using this outside of the switchover or failover workflows

If you want the databases being replicated to on the target to be usable after dropping replication, you need to stop your workload (including performing DDLs) and wait for the replication lag to reach zero before dropping the replication group.

Alternatively, you can follow the failover workflow to ensure the target cuts over to a consistent time.

If you take no precautions then the target databases may be unusable; we strongly recommend dropping such databases rather than attempting to use them.

## Making DDL changes

Warning

Most DDLs can be automatically replicated, however there are still some [Limitations](/stable/architecture/docdb-replication/async-replication/#limitations "Limitations").

DDL operations must only be performed on the Primary universe. All schema changes are automatically replicated to the Standby universe.

## Check which universe is primary

To determine which universe is the Primary in xCluster replication, connect to a database that is in replication and run the following command:

```sql
SELECT yb_xcluster_ddl_replication.get_replication_role();
```

```output
 get_replication_role
----------------------
 source
(1 row)
```

The `source` role indicates that you are talking to the Primary version of the database and that it is ready to accept traffic.

Other role values are possible depending on whether a setup or switchover is in progress and whether you are talking to the Primary or Standby. These other roles are subject to change in future releases.
