Handling and Fixing MySQL Bugs

As the most widely used database in the field of the Internet, MySQL performs exceptionally well in terms of functionality and performance, but in daily use, we often encounter bugs hidden in various MySQL modules.

If a bug is encountered during the production process and it causes a MySQL instance to crash, it may affect online business. Therefore, we need to fix the bug promptly to prevent more serious consequences.

Generally speaking, the bugs we encounter are usually introduced by MySQL during its official development process.

If a fix is needed, there are the following two situations: If there is an official fix, but you do not want to upgrade to the corresponding official fixed version, then we need to find the corresponding fix and apply it through a patch; For bugs without an official fix, it is necessary to report the bug to the official, and then try to fix it yourself.

This time, we will take a bug that has already been fixed by the official as an example, and provide a detailed introduction to the handling process for the first situation.

Recently, during the process of developing new features for KlustronDB's Klustore instances, we discovered a MySQL crash issue.

The stack information of the crash is as follows:

By analyzing the stack and core file information of the Crash, we determined that this was a Crash occurring during the process of an import tablespace operation on a table with added columns. Therefore, based on this information, we can search the official Bug database for related Bugs.

Step 1: Search the official bug database based on the bug information to find the official fix.

Go to the official Bug database MySQL Bugs, select the Advanced search tab, enter the keyword 'crash instant', and select the status 'Closed' (Fixed Bugs)

Click 'Search' to get a bug list like the following:

Upon careful examination, I found that the bug with ID 107517 is related to the issue we encountered, so I clicked in to view the detailed information as follows:

The information from all aspects of the crash stack on the Bug page is the same as the crash we encountered, so it can be determined that this Bug is the one we encountered.

The last part of the bug page indicates that this bug has been fixed in version 8.0.31, so we need to find the patch in versions after 8.0.31.

In addition, we can also find information about this bug in the official 8.0.31 release notes:

There are two corresponding bug numbers here. The 6-digit one (bug#107517) is the external number, which is the number we can see in the bug system, while the 8-digit internal number (bug#34307874) corresponds to a page that only MySQL internal developers can see.

We have noted down this 8-digit internal number bug#34307874, which will be used in the next step.

Step 2: Look for the official repair patch:

To find the official fix patch, you first need to get all the code commit logs from the cloned official repository using git log, and then use the internal bug number bug#34307874 obtained in the previous step to find the corresponding commit, and get the commit ID: 8afe86a32dbafed86be55921ac75d8c8dfc89e4c.

Then, by using git show 8afe86a32dbafed86be55921ac75d8c8dfc89e4c > instant_import.bug, you can get the corresponding patch.

It should be noted here that a bug may have multiple commits, and you must get the patches corresponding to all the commits.

Step 3: Apply the fix patch to your local code repository

After obtaining all the official fix codes, we need to apply all the patches in order, one by one, in the local code repository.

After all patches are applied and MySQL is compiled, a simple verification is needed.

Official fixes usually have a corresponding MTR test case. For example, in the case above, there is a new test case called bug34307874.test. In the compiled mysql-test directory, you can run: ./mtr -mem bug34307874 to execute this test case, and if it passes, it indicates that the bug has been fixed.

Next, you can package and release MySQL.

The above mainly introduces a method for dealing with bugs that have already been fixed officially. This method is suitable for situations where one does not want to upgrade to the officially fixed version. Overall, it is not complicated, and I hope it can help everyone.

In subsequent articles, we will also introduce how to fix official bugs you encounter on your own, as well as the process of submitting the fixes to the officials. Stay tuned.

END