Bug #70659 | Make crash safe slave work with gtid + less durable settings | ||
---|---|---|---|
Submitted: | 18 Oct 2013 18:31 | Modified: | 21 Oct 2013 13:23 |
Reporter: | Yoshinori Matsunobu (OCA) | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
Version: | 5.6.14 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[18 Oct 2013 18:31]
Yoshinori Matsunobu
[21 Oct 2013 13:23]
MySQL Verification Team
Hello Yoshinori, Thank you for the bug report and test case. Verified as described. Thanks, Umesh
[17 May 2018 23:40]
Pura Vida
Regarding the suggested fix: "Truncating binary log based on the above position makes binary log and InnoDB consistent each other." It won't work well if this slave serves as a master of its own slave because the transactions in binary log may have already replicated. I would change it skip writing to the binary for transactions already recorded there.
[21 Aug 2018 17:53]
Jean-François Gagné
Related with . suggested fix for MySQL 5.7 and 8.0: Bug#92109.
[5 Dec 2020 2:05]
Jean-François Gagné
While doing tests for Bug#101874, I tested replication crash safety with GTID, sync_binlog = 0 and innodb_flush_log_at_trx_commit = 2 in a recent MySQL 8.0, and I did not get replication breakage. I suspect that replication crash safety with GTID and less durable settings was introduced with WL#9211 in MySQL 8.0.17. Could we get an official statement from Oracle on this subject ?