MySQL 5.6 has lots of big and shinny new replication features. In fact some, like global transaction identifiers or multi-threaded slave, are multiple features together under one big headline. Therefore, they get a lot of buzz and since they are complex, game-changing and very exciting to the end user, they deserve a lot of blog posts. But what about other smaller enhancements that are in 5.6 but that do not get so much highlight?
Let me present a few that I think are particularly interesting, especially for monitoring and/or configuration purposes. To get more details, click on the links and they will take you to the feature requests or worklog entries.
As a consequence, a patch was written that made the server prepend error messages, reported in SHOW SLAVE STATUS, with the timestamp at which the related failure was reported as an error. That patch was pushed to 5.6.1. Later, it was decided that the timestamp should have its own field in SHOW SLAVE STATUS instead of being embedded into the error message.
So it was changed, and starting from 5.6.3, SHOW SLAVE STATUS has:
- Last_IO_Error_Timestamp: A timestamp in YYMMDD HH:MM:SS format that shows when the most recent I/O error took place.
- Last_SQL_Error_Timestamp: A timestamp in YYMMDD HH:MM:SS format that shows when the last SQL error occurred.
- Master_Retry_Count: The number of times the slave can attempt to reconnect to the master in the event of a lost connection.
Basically, Matthew wanted MASTER_RETRY_COUNT to be dynamically settable through the slave configuration command "CHANGE MASTER TO". Given that MASTER_CONNECT_RETRY was already a configuration option that one could change dynamically, it only made sense to make MASTER_CONNECT_RETRY to be dynamically configurable also. As such, a new parameter to "CHANGE MASTER TO" was added:
- MASTER_RETRY_COUNT: Limits the number of reconnection attempts and updates the value of the Master_Retry_Count column in the output of SHOW SLAVE STATUS.
Mark submitted a feature request asking that the error message printed when slave failed to connect to the master, should be improved to provide details on the reconnection attempts.
As a consequence, changes were made so that once a reconnection to the master failed, the error message would print out the number of times the slave
has retried instead of showing the value of MASTER_RETRY_COUNT. This was implemented in 5.6, so when a MySQL 5.6 slave fails to connect, the user can inspect through SHOW SLAVE STATUS how many reconnect attempts have been made so far. This information is included as part of the message in the Last_IO_Error field for connection failures.
To be precise, this feature was released in 5.6.1
Domas had requested that the user should be allowed to specify that the replication IO thread should bind to some IP when connecting to the master, instead of always using the default address.
This is especially interesting if the host where mysqld is running has several interfaces with different routes to the same master. The configuration of the binding is dynamic and can be done through the command "CHANGE MASTER TO". For this purpose a new parameter was devised:
- MASTER_BIND: for use on replication slaves having multiple network interfaces, and determines which of the slave's network interfaces is chosen for connecting to the master.
- Master_Bind: Shows the network interface that the slave is bound to, if any, set using the MASTER_BIND option for the CHANGE MASTER TO statement.
It was released as part of 5.6.2.
- log_bin_basename: The variable shows the full path to the binary log files, excluding the extension added by the server.
- relay_log_basename: The variable shows the full path to the relay log files, excluding the extension added by the server.
- log_bin_index: The variable shows the full path to the binary log index file.
- relay_log_index: The variable shows the full path to the relay log index file.
This change was introduced in 5.6.2.
Once again, I think the reporters deserve a big "thank you" since they took the time to write up the feature requests and therefore improving MySQL, so here goes: Thank you Matt Lord, Mikiya Okuno, Matthew Montgomery, Mark Callaghan, Domas Mituzas, Mats Kindahl! Looking forward to more requests! In the meantime, enjoy MySQL 5.6!