Introduction

In real-world deployments, the following architecture is typically adopted to guarantee high availability and data integrity:

• Arbitration Cluster

  When using distributed coordination service for consensus, it is critical to deploy an odd number of nodes. This setup prevents split-brain issues by ensuring the cluster can always elect a leader during network partitions, thus maintaining continuous service.

• Database Cluster

  The database relies on a Primary-Standby architecture. This approach not only provides local high availability via replication but also facilitates cross-datacenter disaster recovery. This ensures that services continue uninterrupted even in the event of a data center failure.

The deployment architecture diagram is shown below:

flowchart
  subgraph DCS
    dcs01 e1@<--> dcs02
    dcs02 e2@<--> dcs03
    dcs03 e3@<--> dcs01
    e1@{ animation: slow }
    e2@{ animation: slow }
    e3@{ animation: slow }
  end
  subgraph ECOX
    direction LR
    id1[(ecox01)] e4@--sync--> id2[(ecox02)]
    id2[(ecox02)] e5@--async--> id3[(ecox03)]
    e4@{ animation: slow }
    e5@{ animation: slow }
  end
  DCS e6@--> ECOX
  ECOX e7@--> DCS
  e6@{ animation: slow }
  e7@{ animation: slow }

In this guide, we will deploy a PostgreSQL cluster using ECOX and ZooKeeper on the following hosts:

IP Address	Hostname	Description
10.9.5.5	dcs01	Distributed coordination service node
10.9.5.6	dcs02	Distributed coordination service node
10.9.5.9	dcs03	Distributed coordination service node
10.9.9.68	ecox01	Database cluster node
10.9.9.69	ecox02	Database cluster node
10.9.9.70	ecox03	Database cluster node