# `2-DC` with `Binlog` Replication Deployment Solution

+ Similar to the `MySQL` `primary-standby` solution. Two `TiDB` clusters are deployed in two `DCs`, one acts as the Primary and the other as the Secondary
+ The primary `DC` handles all the requests and the data written to the primary DC is asynchronously written to the secondary `DC` via `Binlog`
+ If the primary `DC` goes down, the requests can be switched to the secondary cluster
  + Similar to `MySQL`, some data might be lost
+ Not like `MySQL`, this solution can ensure the `HA` within the same `DC`:
  + If some nodes within the `DC` went down, the online workloads won't be impacted and no manual efforts are needed because the cluster will automatically re-elect leaders to provide services

------------------------------------------------------------

Two data centers with `Binlog` synchronization is similar to the traditional primary/secondary plan in `MySQL`. 

The two data centers each deploy a standalone `TiDB` cluster, which we call the source cluster and the sink cluster. Under normal circumstances, all requests are made to the source cluster, and the written data is asynchronously synchronized to and written from the cluster through `Binlog`.

When the data center hosts source cluster fails, the business can switch to the sink cluster. Similar to `MySQL`, some data will be missing in this case. Compared to `MySQL`, the advantage of this solution is `HA` in the data center — when a small number of nodes fail, the service is automatically recovered by re-electing the `leader` without manual intervention.