Bug #93397 | Replication does not start if restart MySQL after init without start slave. | ||
---|---|---|---|
Submitted: | 29 Nov 2018 8:43 | Modified: | 3 Sep 2019 11:06 |
Reporter: | Jean-François Gagné | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
Version: | 5.7.24 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[29 Nov 2018 8:43]
Jean-François Gagné
[30 Nov 2018 11:57]
MySQL Verification Team
Hello Jean-François, Thank you for the report and steps. Observed this with 5.7.24 build. regards, Umesh
[30 Nov 2018 11:58]
MySQL Verification Team
test results - 5.7.24
Attachment: 93397_5.7.24.results (application/octet-stream, text), 8.28 KiB.
[14 Dec 2018 11:14]
MySQL Verification Team
Bug #93615 marked as duplicate of this one
[22 Mar 2019 5:57]
MySQL Verification Team
Bug #94730 marked as duplicate of this one
[25 Mar 2019 1:43]
kfpanda kf
In which version will this problem be fixed?
[29 May 2019 12:08]
Simon Mudd
Related to https://bugs.mysql.com/83713
[29 May 2019 12:14]
Simon Mudd
So adding comment from the other related bug#83713: * Seen recently on 5.7.25-1.el7 rpm (CentOS 7) (my /etc/my.cnf config file is available privately in that bug for reference) root@myhost [(none)]> start slave io_thread; ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository And we saw this in the log: 2019-05-23T10:00:19.306164Z 288564 [ERROR] Slave SQL for channel '': Slave failed to initialize relay log info structure from the repository, Error_code: 1872 So given there's no reporting of the actual error that happened here (only that an error occurred) can we at least improve logging to provide more information? Then we can at least determine what the problem is and work out how to avoid it. Oracle seems unable to reproduce this but a similar issue has also been reported by Derek Perkins in 8.0. If there are multiple possible problems that can occur when the current error is reported then distinguishing them would be good, as would providing a more detailed error report of the problem seen. Thanks.
[29 May 2019 12:19]
Jean-François Gagné
Maybe related: Bug#92882.
[30 May 2019 4:49]
MySQL Verification Team
Bug #83713 marked as duplicate of this one.
[30 May 2019 6:53]
Jean-François Gagné
Hi Umesh, I am not sure Bug#83713 is a duplicate of this bug. I think is it more related to Bug#92882. Bug#83713 involves a crash and MTS, and this bug does not involve a crash nor MTS. However, Bug#92882 involves both a crash and MTS. I agree the error messages are very similar though, so I guess all of this is related in some way that I do not understand. Cheers, JFG
[3 Sep 2019 11:06]
Margaret Fisher
Posted by developer: Changelog entry added for MySQL 8.0.19 and 5.7.29: If a replication slave was set up using a CHANGE MASTER TO statement that did not specify the master log file name and master log position, then shut down before START SLAVE was issued, then restarted with the option --relay-log-recovery set, replication did not start. This happened because the receiver thread had not been started before relay log recovery was attempted, so no log rotation event was available in the relay log to provide the master log file name and master log position. In this situation, the slave now skips relay log recovery and logs a warning, then proceeds to start replication.