MySQL Bugs: #88487: Incongruent cases in table 17.3 (Factors influencing ST slave recovery)

Bug #88487	Incongruent cases in table 17.3 (Factors influencing ST slave recovery)
Submitted:	14 Nov 2017 15:51	Modified:	23 Nov 2017 13:27
Reporter:	Gabriel Ciciliani	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Documentation	Severity:	S3 (Non-critical)
Version:	5.6	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
Table 17.3 presented at https://dev.mysql.com/doc/refman/5.6/en/replication-solutions-unexpected-slave-halt.html presents the following first 3 rows:

GTID,MASTER_AUTO_POSITION,relay_log_recovery,relay_log_info_repository,Crash type,Recovery guaranteed,Relay log impact

1) OFF,Not relevant,1,TABLE,Any   ,Yes,Lost
2) OFF,Not relevant,1,TABLE,Server,Yes,Lost
3) OFF,Not relevant,1,Any  ,OS    ,No ,Lost

Row (1) says that if you are using relay_log_recovery=1 and relay_log_info_repository=TABLE, Recovery would be guaranteed for *Any* crash type

At the same time, row (3) says that when using relay_log_recovery=1 and for *Any* option relay_log_info_repository (TABLE or FILE), Recovery would NOT be guaranteed when the OS crashes.

As per my understanding, row (3) conflicts with row (1) where we say that if you are using relay_log_info_repository=TABLE, Recovery is always guaranteed.

Could you please clarify this?

Thanks!

How to repeat:
Please see Table 17.3: "Factors Influencing Single-threaded Replication Slave Recovery" 

at

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

Hello Gabriel,

Thank you for the report and feedback.

Thanks,
Umesh

Posted by developer:
 
Thanks again. I have confirmed that the first row is present in error in the table for a single-threaded slave, and it has now been removed from the documentation. The remaining two rows that distinguish between Server and OS crash type are correct.