Comparison of MySQL stop slave/reset slave Commands with OceanBase Equivalents and Experimental Analysis

1 Background

In MySQL master‑slave replication, commands such as stop slave; reset slave all are used to stop replication and remove slave metadata. The article investigates whether similar commands exist in the distributed database OceanBase and what differences they have.

Explanation

MySQL performs synchronization in the slave; OceanBase provides comparable scenarios in a master‑standby cluster.

OceanBase does not have the exact stop slave; reset slave all commands, but offers similar functionality.

Environment Preparation

A single OceanBase master‑standby cluster is used for the experiments.

2 OceanBase “stop slave”

Several experiments are conducted to observe how the clog (change log) influences the state of an OceanBase master‑standby cluster.

Experiment 1: Disable clog synchronization and check cluster availability

Disable clog synchronization on the primary cluster:

MySQL [(none)]> alter system disable cluster synchronization 'hwc_cluster' cluster_id=1682755173;

Query the standby status:

MySQL [(none)]> select * from oceanbase.v$ob_standby_status\G;
...
cluster_status: DISABLED
synchronization_status: CLUSTER IS DISABLED

Conclusion: Disabling clog synchronization shuts down the OceanBase master‑standby cluster.

Experiment 2: Data loss under special conditions

Set clog retention to one day, insert new data after one day, then re‑enable clog synchronization and verify whether the standby receives the new rows.

MySQL [(none)]> ALTER SYSTEM SET clog_expire_days=1;
MySQL [lpp]> select * from test;
+------+------+ 
| c1   | c2   |
+------+------+ 
| 1   | eee  |
| 2   | eee  |
| 3   | eee  |
+------+------+
MySQL [lpp]> insert into test(c1,c2) values(4,'ddd');
MySQL [(none)]> alter system enable cluster synchronization 'hwc_cluster' cluster_id=1682755173;
MySQL [lpp]> select /*+READ_CONSISTENCY(WEAK) */ * from test;
+------+------+ 
| c1   | c2   |
+------+------+ 
| 1   | eee  |
| 2   | eee  |
| 3   | eee  |
| 4   | ddd  |
+------+------+

Conclusion: The standby cluster synchronizes the newly inserted data.

Principle: When clog synchronization is re‑enabled, OceanBase automatically checks data consistency and pulls missing baseline data.

Experiment 3: Query standby while clog is stopped

With clog synchronization active, the standby can query data. After stopping clog, queries to the standby return a timeout error.

MySQL [lpp]> select /*+READ_CONSISTENCY(WEAK) */ * from test;
ERROR 4012 (HY000): Timeout

Conclusion: Stopping clog makes the standby cluster unavailable.

3 OceanBase “reset slave all”

In MySQL, reset slave all removes replication metadata, allowing the slave to operate independently. In OceanBase, the equivalent is to decouple the master‑standby cluster, a more complex procedure documented in the official guide.

4 Differences between MySQL and OceanBase replication

MySQL

Command executed on the slave.

Stop replication: stop slave .

Remove replication: reset slave all .

If binlog sync breaks and the master’s logs expire, re‑enabling sync may cause data loss on the slave.

The slave remains usable when replication is stopped.

OceanBase

Command executed on the primary cluster.

Stop replication: alter system disable cluster synchronization 'hwc_cluster' cluster_id=... .

Remove replication: decouple the standby cluster (can be done via OCP V3.3.0 white‑screen operation).

When clog sync is broken, the primary’s logs may expire, but re‑enabling sync does not lose data on the standby.

The standby becomes unusable when clog sync is stopped.

References

[1] Decoupling standby cluster procedure: https://www.oceanbase.com/docs/enterprise-oceanbase-database-cn-10000000000946147