Deploying a ZooKeeper‑Managed DBLE Cluster for MySQL High Availability

Environment Architecture

The diagram shows a three‑node ZooKeeper cluster managing a three‑node DBLE cluster, which in turn provides coordinated access to a MySQL 5.7.13 backend.

Purpose

Use ZooKeeper to keep DBLE node metadata consistent so that if any DBLE node fails the remaining nodes continue serving traffic, and verify the architecture with experiments.

Deployment Dependencies

JDK 1.8+ with JAVA_HOME set

MySQL instances with remote login permissions

Install DBLE (3 nodes)

wget https://github.com/actiontech/dble/releases/download/2.19.05.0%2Ftag/actiontech-dble-2.19.05.0.tar.gz

tar zxvf actiontech-dble-2.19.05.0.tar.gz

Edit schema.xml in dble/conf/ to define write and read hosts, e.g.:

<writeHost host="hostM1" url="ip1:3306" user="your_user" password="your_psw">
    <readHost host="hostS1" url="ip2:3306" user="your_user" password="your_psw"/>
</writeHost>

Deploy ZooKeeper Cluster

Download ZooKeeper 3.4.12, set ZOOKEEPER_HOME, copy zoo_sample.cfg to zoo.cfg and edit:

tickTime=2000
initLimit=10
syncLimit=5
clientPort=2181
dataDir=/opt/zookeeper/data
dataLoginDir=/opt/zookeeper/logs
server.id=zk1_server_ip:2888:3888
server.id=zk2_server_ip:2888:3888
server.id=zk3_server_ip:2888:3888

Create a myid file on each node containing its server ID, then start each ZooKeeper instance: cd zookeeper-3.4.12/bin && ./zkServer.sh start Verify the ensemble with: cd zookeeper-3.4.12/bin && ./zkServer.sh status Deploy DBLE Cluster

Configure myid.properties on each DBLE node (example for node A):

cluster=zk
ipAddress=zk_server_ip:2181
clusterId=cluster-1
myid=1

Repeat with different myid values on the other nodes, then start DBLE: cd dble/bin && ./dble start Confirm all DBLE nodes are online via ZooKeeper:

[zk: localhost:2181(CONNECTED) 0] ls /dble/cluster-1/online
[001, 3, server_2]

Simple Tests

Scenario 1 – Reload configuration : modify schema.xml on DBLE‑A, run reload @@config_all;, and verify the change appears on DBLE‑B and DBLE‑C.

Scenario 2 – View synchronization : create a view through DBLE, check that the view exists in ZooKeeper under /dble/cluster-1/view, and confirm it is visible on all DBLE nodes but not in the underlying MySQL.

Scenario 3 – Node failure : stop DBLE‑A, alter a table via DBLE‑C, and verify the schema change is reflected on DBLE‑B, demonstrating that the cluster continues to serve requests despite a node outage.

Conclusions

Using ZooKeeper to coordinate DBLE provides consistent metadata across the cluster, enables configuration propagation with reload @@config_all, stores view definitions centrally in ZooKeeper, and maintains service availability when individual nodes fail.

For detailed synchronization status and further operations, refer to the official documentation: DBLE Cluster Documentation .