Bug #69135 | mysql.slave_master_info is not updated | ||
---|---|---|---|
Submitted: | 3 May 2013 13:06 | Modified: | 24 Mar 2014 12:48 |
Reporter: | Giuseppe Maxia | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Documentation | Severity: | S3 (Non-critical) |
Version: | 5.6.11 | OS: | Any |
Assigned to: | Jon Stephens | CPU Architecture: | Any |
[3 May 2013 13:06]
Giuseppe Maxia
[6 May 2013 11:50]
MySQL Verification Team
Hello Giuseppe, Thank you for the report. Verified as described. Thanks, Umesh
[6 May 2013 12:07]
Giuseppe Maxia
Why is this bug classified as 'D2'? Crash safe tables are one of the major features of MySQL 5.6, and if the table is not updated it means that replication is running blind.
[30 May 2013 14:46]
Matthew Lord
Isn't this expected (at least according to the documentation), if you don't set sync_master_info=1 ? https://dev.mysql.com/doc/refman/5.6/en/replication-options-slave.html#sysvar_sync_master_...
[30 May 2013 15:36]
Giuseppe Maxia
Matt, It is definitely not expected. I din't even suspect that synch_master_info existed. What good is the safe-crash-slave table if by default updates its status every 10,000 events? No. This is not expected.
[30 May 2013 15:48]
Matthew Lord
Hi Giuseppe! I noted "at least according to the documentation" because while this isn't technically a bug, but rather the documented and intentional behavior, I do agree that it's probably not expected from a logical user perspective. Perhaps the "fix" for this bug is simply to make sync_master_info=1 the default when master_info_repository = TABLE is set. What do you think about this potential solution? We don't want to have that generally default to 1 though as it has a noticeable performance impact on the master. Just FYI, this option has existed since 5.5. https://dev.mysql.com/doc/refman/5.5/en/replication-options-slave.html#sysvar_sync_master_... I'm not sure that we want to change the default value further. We already changed the default value from 0 to 10,000 in 5.6. But I'm interested to get your thoughts. To be truly crash-safe, you should also enable CRC checks to ensure that the binary log isn't "sync'd" but corrupted and thus not worth a whole lot in practice: https://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html#option_mysqld_... https://dev.mysql.com/doc/refman/5.6/en/replication-options-slave.html#option_mysqld_slave... Perhaps we could add a new option called --crash-safe-replication that sets up all of the related options (there are quite a few related ones, actually). Best Regards, Matt
[30 May 2013 16:17]
Giuseppe Maxia
Matt, Thanks for your suggestions. I suspect that the reason synch_master_info=1 is not the default is because it may have performance impact. As you know, I work for a company that has implemented this feature already many years ago, and the problem was solved by making the crash-safe tables enabled by default, coupled with block commit to sustain performance. With the current implementation, replication in MySQL 5.6 is not crash safe. If I had my way, I'd enable GTID and crash-safe tables by default, so that all the integration bugs that are still lurking in the background would be found and eventually fixed. If this bug can be fixed with a set of options, then the documentation should mention it explicitly in the user guide. Very few people go looking for every server variable in the manual, especially if they don't expect the new features highlighted in the "what's new" section not to be enabled. What could make life easier is a chapter in the manual that mentions best practices for replication with crash-safe tables, possibly explaining what performance degradation to expect with various values of synch_master_info.
[31 May 2013 14:38]
Luis Soares
Giuseppe, Matt, Allow me to add a comment. For crash-safeness you should have: - slave_relay_log_info=TABLE - relay_log_recovery=ON The first one ensures that positions are consistent with the data. The second one, ensures that the relay log is discarded if corrupted during the crash and that coordinates in master info are recovered from the relay log info (thus lifting the requirement to sync master info on every *event*, which would likely impact performance a bit). Also, let me point you to the documentation bug: BUG#67246 , in particular, Alfranio's comment: [26 Oct 2012 21:18] Alfranio Tavares Correia Junior Perhaps we can make things even more clear in the manual...
[4 Nov 2013 7:34]
MySQL Verification Team
Setting verified as a docs bug.
[4 Nov 2013 15:06]
Simon Mudd
Luis, Why do you _need_ relay_log_recovery=ON, as at least in 5.6 by default you have binlog checksums so you can determine if the binlogs are broken or not. There are other issues which I have raised a support ticket about which may mean that one really does not want to clean out relay logs on server startup as you may lose a lot of history which then has to be downloaded and used again. So off-topic for this bug but I'm not fullly convinced that relay_log_recovery=ON is such a good option as it currently works.
[4 Nov 2013 15:10]
Simon Mudd
Correction from previous comment: you can determine if the relay logs are corrupt or not.
[24 Mar 2014 12:48]
Jon Stephens
Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly.