Jeremy Cole recently blogged about the feature SET GLOBAL sql_log_bin. In his blog post, Jeremy suggested that there is no strong use-case for this feature, and that it is too easy to run accidentally (i.e. SET GLOBAL instead of SET [SESSION]). The result of this incorrect usage is that slaves will drift out of sync from masters.
We discussed Jeremy's request in the MySQL team, and we agree that the syntax should produce an error in MySQL 5.7. However, we have not yet determined which steps should be taken for MySQL 5.5 and MySQL 5.6. The two proposals we would like to float are:
- The statement SET GLOBAL sql_log_bin=N produces a warning.
- The statement SET GLOBAL sql_log_bin=N produces an error.
Option #1 does not specifically solve Jeremy's reported issue, because even though the command provides a warning, it will still execute. Thus, the data-drift from accidental usage will still occur; the operator will simply be aware of the problem sooner.
Option #2 does not follow our standard policy regarding functionality changes in GA releases. That is to say that we are discussing making a special exception since this behaviour is regarded as dangerous and almost certainly unintended.
We are seeking input from the community as to which is the better of these two options:
- Which is your preference - option #1 or option #2?
- Do you agree that this specific situation warrants a behaviour change in GA releases?
Please leave a comment, or get in touch!
Thank you to the MySQL Community, on behalf of the MySQL team @ Oracle. Your bug reports, testcases and patches have helped create a better MySQL 5.6.20.
- Thank you to Jeremy Cole for reporting a case where InnoDB's redo log could become corrupt with externally stored blobs. Jeremy also provided a testcase to demonstrate the problem. Bug #69477.
- Thank you to Ronald Bradford for identifying that MySQL would continue to operate even though the binary log could not be written. Our team picked up Ronald's blog post, and filed a bug in response. Bug #51014.
- Thank you to Daniël van Eeden, Andrew Garner, Detlef Ulherr and Bjoern Boschman for reporting that mysql_install_db would always create a configuration file in /usr. We have added a new option --keep-my-cnf to preserve any existing configuration files, and not create a new file in /usr. Bug #71600, Bug #68318, Bug #68117, Bug #68416.
- Thank you to David Newgas for reporting that loading InnoDB full-text search as a plugin would fail. David also provided a suggested patch. Bug #70178.
- Thank you to Inaam Rana for reporting that the fix for a previous bug added superfluous buf_flush_list() logic to InnoDB startup code. Bug #70899.
- Thank you to Stewart Smith for reporting that some InnoDB internal locks did not account for memory ordering differences on non-intel platforms. While we had discovered this issue earlier in Bug #47213, Stewart's report and sample patches helped considerably. Bug #72539, Bug #47213.
- Thank you to Valeriy Kravchuk for reporting a case where queries on partitioned tables could return wrong results. Bug #71095.
- Thank you to Domas Mituzas for reporting that mysqlbinlog's --raw feature did not correctly handle errors caused by failed writes, leading to potential corruption. Bug #72597.
- Thank you to Raolh Rao for reporting that updating or deleting a row on a master that did not exist on a slave can create problems using row-based replication. Bug #72085.
- Thank you to Vlad Lesin for reporting that quotation marks were not always handled correctly by LOAD DATA INFILE when writing to the binary log. Bug #71603.
- Thank you to Simon Mudd for reporting that manually specifying an AUTO_INCREMENT value could cause a replication error in certain conditions. Bug #70583.
- Thank you to Julien Duponchelle for reporting that client applications could no longer set the BINLOG_DUMP_NON_BLOCK flag in the initial handshake to a MySQL 5.6 server. This functionality was removed by mistake and has now been restored. Bug #71178.
- Thank you to Arthur O'Dwyer for reporting a wrong results bug when using MIN(), MAX() and an aggregate function. Bug #69833.
- Thank you to Shlomi Noach and David Vaughan for reporting that a view defined on a UNION could create an invalid view definition. Bug #65388, Bug #72018.
- Thank you to Lynn Garren for reporting that configuring with cmake -DWITHOUT_SERVER to build clients without the server failed for builds outside of the source tree. Bug #66000.
- Thank you to Dan Kloke for reporting a case when a query using COUNT(DISTINCT) could return wrong results. Bug #52582.
- Thank you to Laurynas Biveinis and Sergey Vojtovich for reporting a situation where a thread deadlock could occur. Bug #71236.
- Thank you to Raghavendra Prabhu for reporting that MySQL did not compile with Bison 3. Bug #71250.
- Thank you to Santosh Praneeth Banda for reporting that uninstalling and reinstalling semisynchronous replication plugins while semisynchronous replication was active caused replication failures. Bug #70391.
- Thank you to Valeriy Kravchuk for reporting a situation when wrong results could be returned for GROUP BY queries. Bug #71097.
- Thank you to Yoshinori Matsunobu for reporting that client auto-reconnect did not work for clients linked against libmysqlclient. Bug #70026.
- Thank you to Daniël van Eeden for reporting that upgrades using RPM packages could change the ownership of an installation directory. Bug #71715.
- Thank you to Valeriy Kravchuk for requesting that MySQL provide option to link against libCstd instead of stlport4 on Solaris. We agree, and have added this functionality. Bug #72352.
- Thank you to Stewart Smith for reporting that various test-suite file permissions were not correct. Bug #71112, Bug #71113.
In addition, we would like to thank the MySQL Community for their feedback on our earlier proposal to deprecate mysqlhotcopy. Based on your feedback we have decided to officially deprecated mysqlhotcopy in 5.6.20, and it will be removed in MySQL 5.7.
Thank you again to all the community contributors listed above. If I missed a name here, please let me know!
Restarting production database servers with gigabytes of memory is difficult. It can lead to cold caches and other operational complexities.
The InnoDB team is looking to make improvements so that restarting MySQL is required as little as possible. Please help them out by answering which configuration settings you are most eager to see made dynamic.