Why Does OceanBase MySQL Binlog Position Stay Stuck? A Troubleshooting Guide

Background

When configuring a binlog task for an OceanBase (MySQL tenant) and executing show master status, the File Position does not increase.

Scenario Demonstration

-- OB MySQL tenant
MySQL [(none)]> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001| 155      |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+

MySQL [(none)]> create database test_xxxxxxxxxx;
Query OK, 1 row affected (0.05 sec)

MySQL [(none)]> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001| 155      |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+

After executing the SQL, the Position does not grow, indicating the SQL was not recorded to the binlog.

Scenario Analysis

Since the binlog task was created successfully, normally any change SQL should be recorded. If not, two possibilities exist:

Binlog task is in an abnormal state;

Binlog Service does not support the executed SQL.

Question 1: Is the Binlog task normal?

Method 1: Show the tenant’s primary Binlog instance information

show binlog status for tenant ob_4_2_1_10.tnt_mysql;

If a record is returned, the primary Binlog instance is running normally.

Method 2: Show the Binlog instances contained in the tenant

show binlog instances for ob_4_2_1_10.tnt_mysql;

If the columns running, obcdc_running, and convert_running are all “Yes”, the Binlog task is operating correctly.

Question 2: How to identify SQL not supported by Binlog Service?

Check the primary Binlog instance of the tenant. In the returned JSON, the status field contains binlog_instance (the primary Binlog name) and client_id (the instance’s working directory, where logs reside).

show binlog status for tenant ob_4_2_1_10.tnt_mysql \G
...
"binlog_instance":"oke7f7u26h",
...
"client_id":"/usr/local/oblogproxy/run/oke7f7u26h",
...

Log into the Binlog Service and inspect the log directory:

# cd /usr/local/oblogproxy/run/oke7f7u26h/log
# grep test_xxxxxxxxxx binlog_instance.log
[2025-08-28 07:38:30.279512] [info] ddl_parser.cpp(124): parser:[create database test_xxxxxxxxxx,]
...
DDL event that is not supported by the downstream is encountered and is empty after conversion, original sql: create database test_xxxxxxxxxx

The log shows the downstream does not support the CREATE DATABASE statement, so it was discarded, leaving the binlog Position unchanged.

Conclusion

When a change statement on an OceanBase MySQL tenant does not advance the binlog Position while the Binlog instance is healthy, the likely cause is that the downstream does not support the SQL, causing the Binlog Service to drop it.