Why Does SHOW MASTER STATUS Fail in OceanBase ODP? A Step‑by‑Step Debug Guide

Background

After setting up a Binlog Server on a black screen, executing show master status via ODP on a business tenant results in an error.

Error Message

MySQL [(none)]> SHOW MASTER STATUS;
ERROR 10102 (HY000): OBProxy connect binlog service failed

The error indicates that OBProxy cannot connect to the Binlog Service.

Possible reasons include:

Incorrect binlog_service_ip configured on ODP.

Binlog Service is abnormal.

Network policy preventing ODP from reaching the Binlog Service.

The actual case did not fall into these categories.

Analysis

Log into the ODP node that reported the error and locate the specific trace ID.

cd /home/admin/obproxy/log/
grep 'SHOW MASTER STATUS' obproxy_error.log

Find the corresponding trace ID and timestamp in the logs:

2025-08-20 20:11:28.412550,odp_4_3_5_0,,,,ob_4_3_5_2:tnt_binlog:,OB_MYSQL,,,OB_MYSQL_COM_QUERY,SHOW,failed,-4016,SHOW MASTER STATUS,5000311us,0us,0us,0us,Y0-00007F9173F016A0,,10.186.65.4:22106,,0,,Internal error,

Search the proxy log using the trace ID:

sed -n '/\[2025-08-20 20:11:28/,$p' obproxy.log | grep Y0-00007F9173F016A0 | less

The logs reveal that the Binlog Service IP cannot be found; the configured binlog_service_ip is 10.186.65.46:2983, which points to a previously used Binlog Server that is now offline.

Check the ODP configuration:

MySQL [(none)]> show proxyconfig like 'binlog_service_ip';
+-------------------+-------------------+---------------------------------------------------------------+-------------+---------------+-------+--------------+
| name              | value             | info                                                          | need_reboot | visible_level | range | config_level |
+-------------------+-------------------+---------------------------------------------------------------+-------------+---------------+-------+--------------+
| binlog_service_ip | 10.186.65.52:2983 | binlog service ip/hostname list, format ip1:sql_port1;...    | false       | SYS           |       | LEVEL_VIP    |
+-------------------+-------------------+---------------------------------------------------------------+-------------+---------------+-------+--------------+

The IP in the configuration does not match the one used in the logs.

Inspect the ODP configuration database:

cd /home/admin/obproxy/etc/
sqlite3 proxyconfig_v1.db
.header on
.mode column
select tenant_name, cluster_name, name, value, config_level from proxy_config where name='binlog_service_ip';

tenant_name  cluster_name  name              value               config_level
-----------  ------------  ----------------  -----------------  ------------
tnt_binlog   ob_4_3_5_2    binlog_service_ip 10.186.65.46:2983  LEVEL_TENANT
                       binlog_service_ip 10.186.65.52:2983  LEVEL_GLOBAL

The tenant‑level entry points to the offline server.

Manual Fix

Update the tenant‑level entry to the correct IP:

update proxy_config set value='10.186.65.52:2983' where name='binlog_service_ip' and tenant_name='tnt_binlog' and cluster_name='ob_4_3_5_2';

Restart ODP for the change to take effect.

Steps That Led to the Issue

Configured Binlog Server 1 + ODP 1 for tenant tnt_binlog, setting binlog_service_ip to Server 1’s address.

Later configured Binlog Server 2 + ODP 1 for the same tenant, updating binlog_service_ip to Server 2’s address.

Using different Binlog Servers with the same ODP for the same tenant caused the conflict.

Additional Notes

When deleting a Binlog task, the tenant‑level binlog_service_ip entry in the ODP config file is not removed. If another Binlog Server exists, ODP will still create a Binlog task using the old entry, which may be unexpected for users.