Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: tiup升级时，tidb启动报Table ‘mysql.bind_info’ doesn’t exist
【TiDB Usage Environment】Production\Test Environment\POC
【TiDB Version】
v5.4.0
【Encountered Problem】
When running tiup cluster upgrade tidb-test v5.4.1, an error occurred.
In the logs
The current cluster status is as follows
【Reproduction Path】What operations were performed to cause the problem
【Problem Phenomenon and Impact】
It should be due to the large version upgrade span.
The logs show that the TiDB startup version is v6.1.0.
The version upgrade span shouldn’t be the issue. The logs show that the TiDB startup version is v6.1.0.
The first upgrade to v5.4.1 failed, then I tried upgrading to v6.1.0 and encountered the same error.
According to the error message, the system table was not created.
The upgraded version does not match the logs.
The command was to upgrade to 5.4.1
But TiDB started as 6.1.0
I guess it might be related to version confusion. Each version upgrade has patches, and it seems that the table creation statements in the patches were not executed.
It’s a bit strange. I just looked at the source code of the startup script, and the bind_info table has been around since version 3.0. Moreover, subsequent upgrades did not involve deleting and recreating the table, only updating table data or upgrading the table structure. The issue is caused by the startup script checking and updating the bind_info table data during the upgrade process, but the table does not exist in the database.
Upgraded twice
The first time was an upgrade to v5.4.1 which failed and reported an error.
The second time was an upgrade to v6.1.0 which also reported an error.
This bind_info table already existed in v5.4.0, but the upgrade reported it as missing.
I personally suspect that:
During the upgrade, some operations were running, because I found create table actions in the tidb-server logs. It’s normal for the upgraded version to add new system tables.
Another possibility is that it needs to modify existing system tables, such as adding or modifying fields.
I don’t know if this is related. It’s very strange for a table to be lost after an upgrade. Moreover, even if you create the table according to the script, it doesn’t make sense without data. The documentation mentions that upgrading during the execution of DDL statements will result in “undefined behavior,” which is unclear. Currently, based on logs and source code, we can only analyze the cause of the error. Let’s see if the official team has any case studies to explain this. For now, it seems that upgrading from 5.4 to 6.1 should be fine. Issues might only arise when upgrading from versions before 3.0, which involve the creation of bind_info tables.
How can we fix this now? Is it possible to copy this data from another TiKV? The entire database won’t start, and it’s urgent.
If the table is not a memory table, it won’t be lost. Otherwise, if there is a cancellation of the DDL operation, there might be deletions during this process.
Hello, just to confirm, after the first upgrade from 5.4.0 to 5.4.1, did it report that mysql.bind_info could not be found?
Please provide the tidb-server logs to facilitate troubleshooting. Thank you.
We redid it, and the logs are no longer available.
Sure, could you please provide the contents of the bind_info table? If it’s convenient, please remember to anonymize the data. Thanks.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
|
username: qhd2004
|
username: 
|
username: 
|
username: 
|
username: 
|
username: