MySQL Bugs: #92064: Information for the recovery of the IO thread is NOT in mysql.slave_master

Bug #92064	Information for the recovery of the IO thread is NOT in mysql.slave_master_info.
Submitted:	18 Aug 2018 18:39	Modified:	31 Aug 2018 12:09
Reporter:	Jean-François Gagné	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Documentation	Severity:	S3 (Non-critical)
Version:	5.6, 5.7, 8.0	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
Hi,

in [1], [1b], [2], 2[b] and [3], I can read: "The server then stores information required for the recovery of the I/O thread in the mysql.slave_master_info [...]".  This is false !

[1]: https://dev.mysql.com/doc/refman/5.6/en/replication-solutions-unexpected-slave-halt.html

[1b]: https://dev.mysql.com/doc/refman/5.6/en/slave-logs.html

[2]: https://dev.mysql.com/doc/refman/5.7/en/replication-solutions-unexpected-slave-halt.html

[2b]: https://dev.mysql.com/doc/refman/5.7/en/slave-logs.html

[3]: https://dev.mysql.com/doc/refman/8.0/en/replication-solutions-unexpected-slave-halt.html

The information required for crash recovery of the I/O thread is not in mysql.slave_master_info but in mysql.slave_relay_log_info table. As well described in [4], [5], [6] and [7], and following Bug#73038, relay_log_recovery does not need the IO Thread position but the SQL Thread position.

[4]: https://medium.com/booking-com-infrastructure/better-crash-safe-replication-for-mysql-a336...

[5]: https://dev.mysql.com/doc/refman/5.6/en/replication-options-slave.html#sysvar_relay_log_re...

[6]: https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#sysvar_relay_log_re...

[7]: https://dev.mysql.com/doc/refman/8.0/en/replication-options-slave.html#sysvar_relay_log_re...

It is a common misconception that crash safe replication needs master_info_repository to TABLE, but this is not the case.  I asked for clarification on the resiliency introduced by master_info_repository to TABLE in Bug#82667, but so far, I have not received those clarification.  I added a comment in Bug#82667 about this.  I also discussed this subject in the past in [8].

[8]: http://jfg-mysql.blogspot.com/2016/08/discussion-about-sync-master-info-and-replication-pa...

Many thanks for looking into that,

JFG

How to repeat:
No steps to repeat for documentation bug

Suggested fix:
Consider a serious rewrite [1], [1b], [2], 2[b] and [3].  From what I see, there are others things that are false there, including the reference to sync_relay_log.  More details about this in [8].

Hello Jean-François,

Thank you for the report!

regards,
Umesh

Sorry about the comment about sync_relay_log in hot to fix.  I missed that this was for MTS and as a work-around for Bug#81840.

Note that another work-around for this bug is to set slave_preserve_commit_order = ON.

Related: more things to fix in that documentation reported in Bug#92093.

Posted by developer:
 
Thanks for the report and the detailed information. I've updated the following topics specifically for the issues covered in this bug and your comment on Bug #82667:

"Handling an Unexpected Halt of a Replication Slave"
https://dev.mysql.com/doc/refman/8.0/en/replication-solutions-unexpected-slave-halt.html
"Replication Relay and Status Logs"
https://dev.mysql.com/doc/refman/8.0/en/slave-logs.html
"Slave Status Logs"
https://dev.mysql.com/doc/refman/8.0/en/slave-logs-status.html
and the 5.7 and 5.6 versions. The updates should be visible online soon. I'll work on the further issues in subsequent weeks.