MySQL Bugs: #98889: Crash Recovery & Waiting for GTID thread to start timed out

Bug #98889	Crash Recovery & Waiting for GTID thread to start timed out
Submitted:	10 Mar 2020 11:10	Modified:	13 Apr 2020 12:43
Reporter:	Ben Huang	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	8.0.18	OS:	CentOS (CentOS Linux release 7.7.1908 (Core))
Assigned to:		CPU Architecture:	x86

Description:
An unknown error was encountered on MySQL Community Server, then MySQL Community Server started crash recovery.

However, MySQL Community Server hung up and the output of error log printed "[Note] [MY-012922] [InnoDB] Waiting for purge to start"

We are trying to find out the reason why MySQL can not start up in source code.

the source code details as follow:
    os_thread_sleep(50000)

does it mean that MySQL Server needed 50000 seconds to started?

please read the attachment in my bugs report.

How to repeat:
Abnormal killing MySQL Server.

the logs as follows:

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
04:02:56 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x7fe6f3cf4140
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7fe41d356d80 thread_stack 0x46000

...

2020-03-10T12:34:36.371014+08:00 0 [ERROR] [MY-011975] [InnoDB] Wait for GTID thread to start timed out
2020-03-10T12:34:36.376322+08:00 0 [Note] [MY-012922] [InnoDB] Waiting for purge to start

mysql error log

Attachment: bap_slave_mysqld-error.log (application/octet-stream, text), 160.41 KiB.

source code snapshot

Attachment: QQ_20200310191159.png (image/png, text), 33.89 KiB.

source code snapshot

Attachment: QQ_20200310191244.png (image/png, text), 16.84 KiB.

source code snapshot

Attachment: QQ_20200310191256.png (image/png, text), 19.00 KiB.

source code snapshot

Attachment: QQ_20200310191306.png (image/png, text), 16.33 KiB.

Hello Mr. Huang,

Thank you for your bug report.

However, I do not see what is the problem here. Simply, main InnoDB thread can not start until purge is finished. Which is happening in another thread.

You obviously have some hard corruption due to storage failure or some other hardware or OS problems.

In any case, this is not our bug, unless you supply us with info on the main cause of the problem. There are so many different possible scenarios here, that we can not conclude that this is our bug.

If it is our bug, we do require a fully repeatable test case. That means a set of SQL statements that would lead always to the problems that you are reporting here.

hello,

Our MySQL Community Server still hung up in "[Note] [MY-012922] [InnoDB] Waiting for purge to start". We just hope that it could start up.

And, could you help me to find out the reason why "os_thread_sleep(50000)". Does it means that MySQL could start up after 50000 seconds

Hi,

Can you run SQL commands ??? If yes, then it is OK. If not, then we need a fully repeatable test case, as explained in our previous comment.

Regarding that sleep(), it happens only in one of many threads that run within our server.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I was also hit by the same bug.

Workaround : The MySQL server from where backup was taken was disabled with binary logs. Enabled the binary logs on source server, retaken the backup and Successfully restored on destination server.