Binlog Error Causes Abnormal Exit

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: Binlog报错异常退出

| username: 普罗米修斯

【TiDB Usage Environment】Testing Environment
【TiDB Version】tidb3.0.0 tidb5.2.4
【Encountered Issue】After performing table creation operations in the upstream cluster, it was found that the downstream cluster binlog did not synchronize. Checking drainer showed an abnormal exit.



On the drainer server, sudo systemctl restart drainer-8249.service

The service starts normally, but the error persists, and drainer still exits.
I want to skip this DDL operation, so I added ignore-txn-commit-ts in drainer.toml, but there is no such timestamp in drainer.log.

| username: songxuecheng | Original post link

Manually execute the DDL directly on the downstream, and then restart the drainer.

| username: 普罗米修斯 | Original post link

I deleted the newly created table upstream and downstream just now, then restarted the drainer on the drainer server, but the logs still report the same error. When I used ansible-playbook to restart on the TiDB server, it indicated a successful restart, but the actual status is still not up.


| username: 普罗米修斯 | Original post link

After restarting the drainer server, it still reports the same error and exits. Please take a look!

| username: songxuecheng | Original post link

What is the version of binlog?

| username: songxuecheng | Original post link

You can try converting this time and then add it to ignore-txn-commit-ts and restart to see if it works.

| username: 普罗米修斯 | Original post link

Could you please tell me how to convert this time to a timestamp?

| username: 普罗米修斯 | Original post link

Binlog is included with TiDB v3.0.0.

| username: songxuecheng | Original post link

Replace it yourself.

| username: 普罗米修斯 | Original post link

After converting with Python and adding it to the drainer configuration file, the drainer still exits after restarting. :lying_face:


| username: songxuecheng | Original post link

Try setting checkpoint-tso + 1 to ignore as well.

| username: 普罗米修斯 | Original post link

It still doesn’t work. After restarting, the drainer still exits.

| username: yilong | Original post link

  1. You can first find out what the corresponding table ID is specifically. Check if there is any information in the historical job.
  2. If it is a test environment, or if you have confirmed that the table has been dropped, stop the drainer and then change the schema-version in the savepoint file to 0 before restarting the drainer. Generally, it is in the data.drainer/savepoint file.
| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.