| Bug #91654 | "Handling an Unexpected Halt of a Replication Slave" Documentation is uncertain | ||
|---|---|---|---|
| Submitted: | 16 Jul 2018 7:58 | Modified: | 20 Oct 2020 10:57 |
| Reporter: | Uday Varagani | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Documentation | Severity: | S3 (Non-critical) |
| Version: | 5.7, 8.0 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[16 Jul 2018 8:06]
Uday Varagani
Hello, Sorry for the missing data about documentation link. Bug 91655 is reported in its place and you can mark this as duplicate. Thanks.
[16 Jul 2018 8:14]
Uday Varagani
Marking this as Close as there is another one logged for this. This is duplicate of https://bugs.mysql.com/bug.php?id=91655.
[16 Jul 2018 8:24]
MySQL Verification Team
https://bugs.mysql.com/bug.php?id=91655 marked as duplicate of this one.
[16 Jul 2018 11:35]
MySQL Verification Team
Thanks for your report, our documentation team will update the documentation with relevant details all best Bogdan
[20 Aug 2018 18:06]
Jean-François Gagné
For reference, the missing link to the documentation in the description is the following: https://dev.mysql.com/doc/refman/5.7/en/replication-solutions-unexpected-slave-halt.html
[20 Aug 2018 18:08]
Jean-François Gagné
IMHO, single-threaded replication is crash safe for both server (mysqld) and OS (Linux) crashes with the following settings:
gtid_mode = OFF
relaly_log_info_repository = TABLE
relay_log_recovery = 1
It does not need sync_relay_log = 1.
The reason for needing sync_relay_log = 1 for multi-threaded replication is Bug#81840. The case where replication crash-recovery fails with MTS is described in more details in the bug report and in [1].
[1]: http://jfg-mysql.blogspot.com/2016/01/replication-crash-safety-with-mts.html
For replication crash recovery to fail with MTS, slave_preserve_commit_order needs to be disabled (which is the default setting). If slave_preserve_commit_order is enabled, then I believe multi-threaded replication is crash safe when relaly_log_info_repository = TABLE and relay_log_recovery = 1.
I want to point-out that all I write here is for gtid_mode = OFF. With gtid_mode = ON, this is a completely different situation. More about this in Bug#90997 and Bug#70659. There is even more to say about about gtid_mode = ON, but for that I need to write a lot and open a new bug report. Once done I will add a link in comments below.
[20 Oct 2020 10:57]
Margaret Fisher
Posted by developer: Thanks to all those who raised and contributed to discussions of this issue. The "Handling an Unexpected Halt of a Replica" topic has now been reworked in the 8.0 and 5.7 documentation to focus on a recommended combination of server settings for recovery, rather than addressing all the possible combinations. Please see the updated topics here: https://dev.mysql.com/doc/refman/8.0/en/replication-solutions-unexpected-replica-halt.html https://dev.mysql.com/doc/refman/5.7/en/replication-solutions-unexpected-replica-halt.html
Description: In the documentation link given below, single thread replication with below settings is mentioned to survive only a Server(MySQL) crash but not OS. Gidd = OFF relay_log_recovery = 1 relaly_log_info_repository = TABLE With the same settings and sync_relay_log = 1 in addition, multi threaded replication is mentioned to survive Server(MySQL) as well as OS crashes. No mention of why single threaded replication cant survive an OS crash where the multi threaded replication can with an additional setting sync_relay_log = 1 which can also be configured irrespective of applier thread count. How to repeat: NA Suggested fix: Update documentation about below things. 1. Why sync_relay_log = 1 doesn't matter in case of single threaded replication. 2. Can single threaded replication be OS crash safe with settings below. Gidd = OFF relay_log_recovery = 1 relaly_log_info_repository = TABLE sync_relay_log = 1