# Deployment in two data centers

**URL:** <https://forum.yugabyte.com/t/deployment-in-two-data-centers/2495>\
**Category:** General\
**Created:** [February 7, 2024, 11:22am UTC](https://forum.yugabyte.com/t/deployment-in-two-data-centers/2495 "2024-02-07T11:22:22Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Uladzislau](https://avatars.discourse-cdn.com/v4/letter/u/eb9ed0/32.png) [@Uladzislau](https://forum.yugabyte.com/u/Uladzislau)\
**Post date:** [February 7, 2024, 11:22am UTC](https://forum.yugabyte.com/t/deployment-in-two-data-centers/2495/1 "2024-02-07T11:22:22Z")

</div>

Hi, please help me figure this out.

I need to deploy a multi data center cluster. Exactly 2 data centers. Two clusters with bidirectional replication are not suitable, since we have many tables that need to be replicated. And in the setup\_universe\_replication command you need to specify the IDs of all tables. It seems there is no way to specify that certain databases need to be replicated.

Would it be ok to do the following setup instead? 3 nodes in one data center and 3 nodes in another data center in one cluster. On each node there is a master + tserver. Set the replication factor to 6. We need that if the connection between the data centers is lost, both clusters continue to work. Also, if one data center is lost, another cluster could service client requests.  
Will this option be fault-tolerant and is it normal to use this approach?

---

<div class="post-metadata">

**Author:** ![dorian\_yugabyte](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/dorian_yugabyte/32/206_2.png) [@dorian\_yugabyte](https://forum.yugabyte.com/u/dorian_yugabyte)\
**Post date:** [February 7, 2024, 12:09pm UTC](https://forum.yugabyte.com/t/deployment-in-two-data-centers/2495/2 "2024-02-07T12:09:26Z")

</div>

Hi @Uladzislau

> [@Uladzislau](#):
>
> Two clusters with bidirectional replication are not suitable, since we have many tables that need to be replicated.

Can you be more clear why you mean that this is not suitable?

> [@Uladzislau](#):
>
> Set the replication factor to 6.

RF must be an odd number, see [Deployment checklist for YugabyteDB clusters | YugabyteDB Docs](https://docs.yugabyte.com/preview/deploy/checklist/#replication).

> [@Uladzislau](#):
>
> We need that if the connection between the data centers is lost, both clusters continue to work. Also, if one data center is lost, another cluster could service client requests.

This option will require you to have 2 separate clusters and be connected with xCluster [xCluster replication (2+ regions) in YugabyteDB | YugabyteDB Docs](https://docs.yugabyte.com/preview/explore/multi-region-deployments/asynchronous-replication-ysql/).

It won’t work with a single cluster with synchronous replication (even if you had 3 regions).

---

<div class="post-metadata">

**Author:** ![Uladzislau](https://avatars.discourse-cdn.com/v4/letter/u/eb9ed0/32.png) [@Uladzislau](https://forum.yugabyte.com/u/Uladzislau)\
**Post date:** [February 7, 2024, 4:16pm UTC](https://forum.yugabyte.com/t/deployment-in-two-data-centers/2495/3 "2024-02-07T16:16:08Z")

</div>

> [@dorian\_yugabyte](#):
>
> Can you be more clear why you mean that this is not suitable?

It is not convenient that you need to manually or using a script get the IDs of all tables and list them in the setup\_universe\_replication command. Also, when changing the database schema, you will have to constantly add new tables to replication.

I would like to be able to replicate all databases with all schemas and tables without having to list all the IDs of all tables.

Maybe I missed something?

---

<div class="post-metadata">

**Author:** ![dorian\_yugabyte](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/dorian_yugabyte/32/206_2.png) [@dorian\_yugabyte](https://forum.yugabyte.com/u/dorian_yugabyte)\
**Post date:** [February 8, 2024, 7:31am UTC](https://forum.yugabyte.com/t/deployment-in-two-data-centers/2495/4 "2024-02-08T07:31:10Z")

</div>

> [@Uladzislau](#):
>
> I would like to be able to replicate all databases with all schemas and tables without having to list all the IDs of all tables.

This is in the roadmap, to replicate all tables. DDL conflicts is a separate issue though.

> [@Uladzislau](#):
>
> Maybe I missed something?

You’ll need 3 DCS with normal synchronous replication.

---

<div class="post-metadata">

**Author:** ![Uladzislau](https://avatars.discourse-cdn.com/v4/letter/u/eb9ed0/32.png) [@Uladzislau](https://forum.yugabyte.com/u/Uladzislau)\
**Post date:** [February 8, 2024, 11:44am UTC](https://forum.yugabyte.com/t/deployment-in-two-data-centers/2495/5 "2024-02-08T11:44:06Z")

</div>

> [@dorian\_yugabyte](#):
>
> You’ll need 3 DCS with normal synchronous replication.

But we only have 2 data centers. A third is not planned.

---

<div class="post-metadata">

**Author:** ![Uladzislau](https://avatars.discourse-cdn.com/v4/letter/u/eb9ed0/32.png) [@Uladzislau](https://forum.yugabyte.com/u/Uladzislau)\
**Post date:** [February 8, 2024, 11:45am UTC](https://forum.yugabyte.com/t/deployment-in-two-data-centers/2495/6 "2024-02-08T11:45:32Z")

</div>

> [@dorian\_yugabyte](#):
>
> You’ll need 3 DCS with normal synchronous replication.

If I get you right. There is no way to replicate 2 data centers with asynchronous replication and not list the IDs of all tables.

---

<div class="post-metadata">

**Author:** ![dorian\_yugabyte](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/dorian_yugabyte/32/206_2.png) [@dorian\_yugabyte](https://forum.yugabyte.com/u/dorian_yugabyte)\
**Post date:** [February 8, 2024, 11:57am UTC](https://forum.yugabyte.com/t/deployment-in-two-data-centers/2495/7 "2024-02-08T11:57:45Z")

</div>

> [@Uladzislau](#):
>
> But we only have 2 data centers. A third is not planned.

With the constraints you mentioned (2 dcs being able to function if either one of them goes down) you can only use xCluster.

> [@Uladzislau](#):
>
> There is no way to replicate 2 data centers with asynchronous replication and not list the IDs of all tables.

Not yet.

---

<div class="post-metadata">

**Author:** ![Uladzislau](https://avatars.discourse-cdn.com/v4/letter/u/eb9ed0/32.png) [@Uladzislau](https://forum.yugabyte.com/u/Uladzislau)\
**Post date:** [February 8, 2024, 5:49pm UTC](https://forum.yugabyte.com/t/deployment-in-two-data-centers/2495/8 "2024-02-08T17:49:21Z")

</div>

> [@dorian\_yugabyte](#):
>
> Not yet.

Thanks for the info.

---

<div class="post-metadata">

**Author:** ![Hari\_yb](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/hari_yb/32/813_2.png) [@Hari\_yb](https://forum.yugabyte.com/u/Hari_yb)\
**Post date:** [June 18, 2024, 5:03pm UTC](https://forum.yugabyte.com/t/deployment-in-two-data-centers/2495/9 "2024-06-18T17:03:45Z")

</div>

We will support the database level APIs from the next release  
[[xCluster] Support Database/Keyspace level replication · Issue #10984 · yugabyte/yugabyte-db · GitHub](https://github.com/yugabyte/yugabyte-db/issues/10984) .

But this is going to be for YSQL only. And it will be transactional uni-direction replication. We do not support Bi-Directional Transactional xCluster since with async replication there is always a lag, and we cannot guarantee consistency when writing to both sides at the same time. You can have 2 DBs, with unidirectional transactional xCluster on different directions and write to the appropriate side.  
You will have to run the YSQL DDL change on both sides, but you dont have to worry about getting the ID and adding it to replication. The automatic replication of DDLs itself is planned in [[DocDB] xcluster: Automatically propagate DDL changes across clusters · Issue #11537 · yugabyte/yugabyte-db · GitHub](https://github.com/yugabyte/yugabyte-db/issues/11537)
