Replacing OCP Nodes Using the ANTMAN Tool in OceanBase Cloud Platform

1 Introduction

OceanBase Cloud Platform (OCP) is an enterprise‑grade database management platform built around OceanBase. In production environments OCP is usually installed first, and later hardware changes such as machine relocation or replacement may require swapping OCP nodes.

2 Environment Background

Earlier OCP releases required three Docker packages—OCP software, metadb, and obproxy—while later versions combine DB and Proxy into a single Docker image. The metadb component remains separate and must be replaced with the ANTMAN tool.

Software Information

Software

Version

OCP

ocp-all-in-one:3.3.3-20220906114643

metadb+proxy

OB2277_OBP320_x86_20220429

Proxy

4.1.1_20230519_x86

antman

t-oceanbase-antman-1.4.3-20220807073355.alios7.x86_64

3 Operation Process

3.1 Environment Check / Preparation

Verify the replacement machine’s environment (disk partitioning, admin user creation, Docker installation, etc.). Then run the pre‑check script:

cd /root/t-oceanbase-antman/clonescripts/
sh precheck.sh -m ocp

Log into the meta database and ensure the tenant’s primary ZONE points to the node that will be replaced, then perform a manual primary switch.

MySQL [oceanbase]> select * from __all_Server;
... (output omitted for brevity) ...
MySQL [oceanbase]> alter tenant sys primary_zone='META_OB_ZONE_2;META_OB_ZONE_3,META_OB_ZONE_1';
Query OK, 0 rows affected

Modify obcluster.conf on the execution host or copy it from the original OCP, and ensure the Docker image is available under /root/t-oceanbase-antman :

55obffocp:~/t-oceanbase-antman # cat obcluster.conf
ZONE1_RS_IP=10.10.100.9
ZONE2_RS_IP=10.10.100.87
ZONE3_RS_IP=122.44.11.2
... (rest of file omitted) ...
OCP_VERSION=3.3.3

Check and set the cluster passwords using getpass.sh and setpass.sh scripts.

55obffocp:~/t-oceanbase-antman/tools # bash setpass.sh -s 0Aa255yK^F
Password of root@sys is 0Aa255yK^F
...

3.2 Adding New Machine

Execute the ANTMAN manage.sh script to add the new node:

55obffocp:~/t-oceanbase-antman # ./manage.sh -i ob,ocp,obproxy -l 133.55.22.19 -z 1 -R Jnydzycscc@123 -A OceanBase#123

The script installs the OB, OBProxy, and OCP Docker containers on the target host, logs progress, and reports when each component is ready.

Explanation of Key Options

133.55.22.19 – physical IP of the replacement server.

-z 1 – assign the new server to ZONE 1, matching the existing zone of 10.10.100.9 .

-R and -A – root and admin passwords for the target host.

-i – install components; use -c to clear them.

After a successful install, the new node can be accessed via the OCP UI (IP:8080) or directly through the OBProxy port (2883).

3.3 Adding New Tenant

Log into the OCP metadb sys tenant and add the new meta_ob Docker instance:

MySQL [oceanbase]> alter system add server '133.55.22.19:2882' zone 'META_OB_ZONE_1';
Query OK, 0 rows affected

3.4 Removing Old Server

Delete the old server from the meta database:

MySQL [oceanbase]> alter system delete server '10.10.100.9:2882' zone 'META_OB_ZONE_1';
Query OK, 0 rows affected

3.5 Updating Server Information

Update the OCP compute_host table to reflect the new IP address:

mysql -h10.10.100.87 -P2883 -uroot@ocp_meta -p'rSf@jO%6EO' -Docp -c
update compute_host set inner_ip_address='133.55.22.19', name='55obffocp' where inner_ip_address='10.10.100.9';

3.6 Cleaning Up Old Services

Run the ANTMAN script with the -c option to remove OB, OBProxy, and OCP Docker containers from the replaced machine:

55obffocp:~/t-oceanbase-antman # ./manage.sh -c ob,ocp,obproxy -l 10.10.100.9 -z 1 -R 'Dt!n(Rg4Av!t' -A OceanBase#123

The script stops and removes each Docker container, confirming that the services have been cleared.

4 Summary

Using the ANTMAN tool to replace OCP nodes simplifies the process compared with the OAT method, as it adds the new machine to the same ZONE, migrates units within that ZONE, and then decommissions the old server, resulting in less impact on OCP metadata.

While ANTMAN reduces the number of manual steps, both methods require careful handling of zone configuration, resource pools, and memory limits to avoid migration failures.

Proceed with the method that best fits your cluster version and operational constraints.