MySQL Bugs: #73038: Better document (or fix) relay_log

Bug #73038	Better document (or fix) relay_log_recovery.
Submitted:	18 Jun 2014 14:14	Modified:	8 Jul 2014 11:51
Reporter:	Jean-François Gagné	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Documentation	Severity:	S3 (Non-critical)
Version:	5.6.19	OS:	Any
Assigned to:	David Moss	CPU Architecture:	Any

Description:
At http://dev.mysql.com/doc/refman/5.6/en/replication-options-slave.html#sysvar_relay_log_rec..., we can read:

Enables automatic relay log recovery immediately following server startup, which means that the replication slave discards all unprocessed relay logs and retrieves them from the replication master.

This is not exact.  The unprocessed relay logs are not discarded by the recovery process.  When starting MySQL, the recovery process creates a new relay log file, initializes the SQL thread position to this new relay log, and initialize the IO thread to the SQL thread position.  In this process, no logs are deleted.

The relay logs will be deleted when the SQL thread will be started and only if relay_log_purge = 1.  If MySQL is started with skip-slave-start or with relay_log_purge = 0, nothing is deleted.

How to repeat:
See description.

Suggested fix:
Adjust the documentation or delete the relay logs.

Note that if the documentation is adjusted, relay_log_purge = 0 does not guarantee relay logs consistency.  In this case, it is probably worth mentioning in the documentation that relay_log_purge = 0 is not crash-safe.

Hello Jean,

Thank you for the bug report.
Considering Bug #73039, marking this as Doc change request.

Thanks,
Umesh

Hi Umesh,

thanks for looking into that.  Ok to mark this as a Doc change request.

I just want to point out that Bug #73039 and this one are unrelated.  It happens that Bug #73039 is about not executing relay_log_recovery (so not discarding relay logs), but this bug is about precising documentation on what "discarding" means.  "Discarding" can be interpreted as delete (rm/unlink), which is not what relay log recovery is doing.  In the current implementation, relay logs dating from before a crash can still exist.  This is a subtle thing, but it can lead to problem if someone is processing relay logs and expects those to be an exact continuous copy from the master (without duplicate events).

JFG

Thanks for your feedback. I have updated the documentation with commits 39247 and 39248 as follows:
http://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#sysvar_relay_log_rec...:
Enables automatic relay log recovery immediately following server startup. The recovery process creates a new relay log file, initializes the SQL thread position to this new relay log, and initializes the IO thread to the SQL thread position. Reading of the relay log from the master then continues.

....
Enabling the --relay-log-recovery option when relay-log-purge is disabled risks reading the relay log from files that were not purged, leading to data inconsistency, and is therefore not crash-safe.

Posted by developer:
 
Thanks for your feedback. I have updated the documentation with commits 39247 and 39248 as follows:
http://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#sysvar_relay_log_rec...:
Enables automatic relay log recovery immediately following server startup. The recovery process creates a new relay log file, initializes the SQL thread position to this new relay log, and initializes the IO thread to the SQL thread position. Reading of the relay log from the master then continues.

....
Enabling the --relay-log-recovery option when relay-log-purge is disabled risks reading the relay log from files that were not purged, leading to data inconsistency, and is therefore not crash-safe.