Technology Sharing | How to find the fixed BUG content based on the MySQL crash log

Author: Yue Mingqiang

A member of the DBA team of Aikesheng Beijing Branch, responsible for the operation and maintenance of the database management platform and MySQL problem handling. Good at fault location of MySQL.

Source of this article: original submission

* Produced by the Aikesheng open source community, original content is not allowed to be used without authorization, please contact the editor and indicate the source for reprinting.

---

Running problems generally occur in production, you can look through the error log, and most of them can be solved. Sometimes the database suddenly crashes and restarts. At this time, we will find "This could be because you hit a bug" in the error log, and then hit a bunch of unintelligible stacks. At this time, if you cross the conclusion that you have encountered a bug, you will probably get a crit output: there is no evidence, how did the bug appear, how the official repaired it, and in what version it was repaired. So next, I will find a detailed BUG repair record based on the stack information in the existing error log.

1. View the current error log

MySQL crashes abnormally, check the error log, the red box is the location information

Note: If this kind of similar BUG information appears, you should not only look at this part of the information, but first check whether there is an error message before MySQL exits abnormally. No demonstration here

Two, gdb view the location of the error file

Use gdb to track the location of the error file. The previous error file is mysqld, which is the gdb mysqld file. If it is another file, such as a group replication plug-in, then it is gdb.

First, b first the name of the function, as shown below:

It can be seen that two positions are found later, and then we add the offset, and then b:

Obviously, the second one found is the file in mysql. Download the source package of the same version from the official website and decompress it. After looking for line 410 in the file pipeline_stats.h, make sure that the function name is Pipeline_member_stats()

Three, view the changed content of the function

Find this file in the official mysql address on github

https://github.com/mysql/mysql-server

Search for the corresponding keyword to the location

The default code on the website is the latest version of 8.0, take it down and compare it with the code of version 8.0.18

Four, view the history of changes

Through the comparison tool, you can see that there are some changes in the function code. Next, let’s look at the reasons for changing this part of the code. Open the Blame on the left to see the historical change records.

Most of the changes in this function are caused by Bug#30049349, you can go in to see the detailed content of the bug. The article pointed out that when stop group_replication, P_S check may cause the database to crash. The repair method is when stop group_replication. Add a read-write lock to the related table in P_S to prohibit query

It can also be found in the Release Notes of the MySQL official website. The bug was fixed in version 8.0.20

You can also view historical changes from the History of the entire file

V. Conclusion

The article mainly mentions finding bugs that have been fixed currently through the error log. If you encounter the above error in the error log, you should analyze the error before the crash. Part of the crash error can be found without using the stack to locate the error. If the code is not directly modified when the bug is fixed, it may become invalid. At this time, you need to sort out the code pointed to by the stack, figure out this part of the logic, and analyze it again.