MySQL 5.6.26 was recently released (it is the latest MySQL 5.6, is GA), and is available for download here.
For this release, there are 3 “Functionality Added or Changed” items, 1 “Security Fix”, and 36 other bug fixes.
Out of those other 36 bugs, 13 are InnoDB, 1 Partitioning, 3 Replication, and 19 misc. (including 3 potentially crashing bug fixes, and 1 performance-related fix) Here are the ones of note:
- Functionality Added/Changed: Replication: When using a multi-threaded slave, each worker thread has its own queue of transactions to process. In previous MySQL versions, STOP SLAVE waited for all workers to process their entire queue. This logic has been changed so that STOP SLAVE first finds the newest transaction that was committed by any worker thread. Then, it waits for all workers to complete transactions older than that. Newer transactions are not processed. The new logic allows STOP SLAVE to complete faster in case some worker queues contain multiple transactions. (Bug #75525)
- Functionality Added/Changed: Previously, the max_digest_length system variable controlled the maximum digest length for all server functions that computed statement digests. However, whereas the Performance Schema may need to maintain many digest values, other server functions such as MySQL Enterprise Firewall need only one digest per session. Increasing the max_digest_length value has little impact on total memory requirements for those functions, but can increase Performance Schema memory requirements significantly. To enable configuring digest length separately for the Performance Schema, its digest length is now controlled by the new performance_schema_max_digest_length system variable.
- Functionality Added/Changed: Previously, changes to the validate_password plugin dictionary file (named by the validate_password_dictionary_file system variable) while the server was running required a restart for the server to recognize the changes. Now validate_password_dictionary_file can be set at runtime and assigning a value causes the named file to be read without a restart. In addition, two new status variables are available. validate_password_dictionary_file_last_parsed indicates when the dictionary file was last read, and validate_password_dictionary_file_words_count indicates how many words it contains. (Bug #66697)
- Security-related: Due to the LogJam issue (https://weakdh.org/), OpenSSL has changed the Diffie-Hellman key length parameters for openssl-1.0.1n and up. OpenSSL has provided a detailed explanation at http://openssl.org/news/secadv_20150611.txt. To adopt this change in MySQL, the key length used in vio/viosslfactories.c for creating Diffie-Hellman keys has been increased from 512 to 2,048 bits. (Bug #77275)
- InnoDB: Importing a tablespace with a full-text index resulted in an assertion when attempting to rebuild the index.
- InnoDB: Opening a foreign key-referenced table with foreign_key_checks enabled resulted in an error when the table or database name contained special characters.
- InnoDB: The page_zip_verify_checksum function returned false for a valid compressed page.
- InnoDB: A failure to load a change buffer bitmap page during a concurrent delete tablespace operation caused a server exit.
- InnoDB: After dropping a full-text search index, the hidden FTS_DOC_ID and FTS_DOC_ID_INDEX columns prevented online DDL operations. (Bug #76012)
- InnoDB: An index record was not found on rollback due to inconsistencies in the purge_node_t structure. (Bug #70214)
- Partitioning: In certain cases, ALTER TABLE … REBUILD PARTITION was not handled correctly when executed on a locked table.
- Replication: If flushing the cache to the binary log failed, for example due to a disk problem, the error was not detected by the binary log group commit logic. This could cause inconsistencies between the master and the slave. The fix uses the binlog_error_action variable to decide how to handle this situation. If binlog_error_action=ABORT_SERVER, then the server aborts after informing the client with an ER_BINLOGGING_IMPOSSIBLE error. If binlog_error_action=IGNORE_ERROR, then the error is ignored and binary logging is disabled until the server is restarted again. The same is mentioned in the error log file, and the transaction is committed inside the storage engine without being added to the binary log. (Bug #76795)
- Replication: When using GTIDs, a multi-threaded slave which had relay_log_recovery=1 and that stopped unexpectedly could encounter a relay-log-recovery cannot be executed when the slave was stopped with an error or killed in MTS mode error upon restart. The fix ensures that the relay log recovery process checks if GTIDs are in use or not. If GTIDs are in use, the multi-threaded slave recovery process uses the GTID protocol to fill any unprocessed transactions. (Bug #73397)
- Replication: When two slaves with the same server_uuid were configured to replicate from a single master, the I/O thread of the slaves kept reconnecting and generating new relay log files without new content. In such a situation, the master now generates an error which is sent to the slave. By receiving this error from the master, the slave I/O thread does not try to reconnect, avoiding this problem. (Bug #72581)
- Crashing Bug: Incorrect cost calculation for the semi-join Duplicate Weedout strategy could result in a server exit.
- Crashing Bug: For large values of max_digest_length, the Performance Schema could encounter an overflow error when computing memory requirements, resulting in a server exit.
- Crashing Bug: GROUP BY or ORDER BY on a CHAR(0) NOT NULL column could lead to a server exit.
- Performance-related: When choosing join order, the optimizer could incorrectly calculate the cost of a table scan and choose a table scan over a more efficient eq_ref join. (Bug #71584)
So while there were no major changes, and not too many overall bug fixes, the security fix could be an issue if you run the latest RHEL/CentOS with SSL connections + a DHE SSL cipher specifed with –ssl-cipher=DHE-RSA-… Also, some of those InnoDB bugs are nasty, especially the fulltext bugs, thus if you use InnoDB’s fulltext, I’d recommend planning for an upgrade.
The full 5.6.26 changelogs can be viewed here (which has more details about all of the bugs listed above):
Hope this helps. 🙂
MySQL 5.6.25 was recently released (it is the latest MySQL 5.6, is GA), and is available for download here.
For this release, there are 2 “Functionality Added or Changed” items of note:
- Functionality Added/Changed: MySQL distributions now include an innodb_stress suite of test cases. Thanks to Mark Callaghan for the contribution. (Bug #76347)
- Functionality Added/Changed: my_print_defaults now masks passwords. To display passwords in cleartext, use the new –show option.
In addition to those, there were 55 other bug fixes:
- 10 InnoDB
- 8 Replication
- 3 Partitioning (one overlaps w/ an InnoDB bug fix)
- 35 Miscellaneous (and 6 of those were specifically for “MySQL Enterprise Firewall”)
The highlights for me are 5 of the replication bugs, 1 partitioning bug, 1 performance-related bug, 1 wrong results bug, and 9 crashing bugs:
- Replication: When using semisynchronous replication performance was degrading when the number of threads increased beyond a certain threshold. To improve performance, now only the thread which is committing is responsible for deleting the active transaction node. All other operations do not touch this active transaction list. (Bug #75570)
- Replication: When binary logging was enabled, using stored functions and triggers resulting in a long running procedure that inserted many records caused the memory use to increase rapidly. This was due to memory being allocated per variable. The fix ensures that in such a situation, memory is allocated once and the same memory is reused. (Bug #75879)
- Replication: If an error was encountered while adding a GTID to the received GTID set, the log lock was not being correctly released. This could cause a deadlock. (Bug #75781)
- Replication: When master_info_repository=TABLE the receiver thread stores received event information in a table. The memory used in the process of updating the table was not being freed correctly and this could lead to an out of memory error. The fix ensures that after an event is flushed to the relay log file by a receiver thread, the memory used is freed. (Bug #72885, Bug #69848)
- Replication: Using mysqlbinlog to process log events greater than 1.6GB failed with an out of memory error. This was caused by an internal error converting the length variable. The fix upgrades the length variable to avoid overflow in both encoding and decoding functions. (Bug #74734)
- Partitioning: Executing an ALTER TABLE on a partitioned table on which a write lock was in effect could cause subsequent SQL statements on this table to fail. (Bug #74288).
- Performance-related: Certain queries for the INFORMATION_SCHEMA TABLES and COLUMNS tables could lead to excessive memory use when there were large numbers of empty InnoDB tables. (Bug #72322)
- Incorrect Results: Queries that included a HAVING clause based on nondeterministic functions could produce incorrect results. (Bug #69638)
- Crashing Bug: For small values of the read_rnd_buffer_size system variable, internal caching of temporary results could fail and cause query execution failure.
- Crashing Bug: A failed FLUSH PRIVILEGES statement followed by statements to create or drop accounts could cause a server exit.
- Crashing Bug: SHOW VARIABLES mutexes were being locked twice, resulting in a server exit.
- Crashing Bug: For join queries with a large number of tables, the server could exit converting the join to a semi-join.
- Crashing Bug: Deleting rows from mysql.user following by granting privileges to a new account could result in a server exit.
- Crashing Bug: Within a stored procedure, access to view columns after DDL or FLUSH TABLES statements in the procedure could cause a server exit.
- Crashing Bug: Execution of certain BINLOG statements while temporary tables were open by HANDLER statements could cause a server exit.
- Crashing Bug: For a prepared statement with an ORDER BY that refers by column number to a GROUP_CONCAT() expression that has an outer reference, repeated statement execution could cause a server exit.
- Crashing Bug: Specifying –general_log_file= (with an empty value) at server startup caused the server to fail and exit.
So while there were no major changes, the partitioning fix could fix a potentially serious issue if you think you might encounter it (some partitioning use-cases involve frequent ALTERs), the replication fixes could potentially be important for you, and the numerous crashing (and performance-related & wrong results) bugs are important if you’re performing the operations that trigger them. So read through these, and if you’ll be affected by any of the above, or think you might be, then I’d recommend upgrading.
On a side note, there are several serious “MySQL Enterprise Firewall” bug fixes in this release, which I omitted above since the general public doesn’t have access to it, but if you are using it, you should upgrade due to the number of potentially serious bugs that exist in prior versions.
The full 5.6.25 changelogs can be viewed here (which has more details about all of the bugs listed above):
Hope this helps. 🙂
MySQL 5.6.24 was recently released (it is the latest MySQL 5.6, is GA), and is available for download here.
For this release, there are 4 “Functionality Added or Changed” items:
- Functionality Added/Changed: CMake support was updated to handle CMake version 3.1.
- Functionality Added/Changed: The server now includes its version number when it writes the initial “starting” message to the error log, to make it easier to tell which server instance error log output applies to. This value is the same as that available from the version system variable. (Bug #74917)
- Functionality Added/Changed: ALTER TABLE did not take advantage of fast alterations that might otherwise apply to the operation to be performed, if the table contained temporal columns found to be in pre-5.6.4 format (TIME, DATETIME, and TIMESTAMP columns without support for fractional seconds precision). Instead, it upgraded the table by rebuilding it. Two new system variables enable control over upgrading such columns and provide information about them:
- avoid_temporal_upgrade controls whether ALTER TABLE implicitly upgrades temporal columns found to be in pre-5.6.4 format. This variable is disabled by default. Enabling it causes ALTER TABLE not to rebuild temporal columns and thereby be able to take advantage of possible fast alterations.
- show_old_temporals controls whether SHOW CREATE TABLE output includes comments to flag temporal columns found to be in pre-5.6.4 format. Output for the COLUMN_TYPE column of the INFORMATION_SCHEMA.COLUMNS table is affected similarly. This variable is disabled by default.
- Functionality Added/Changed: Statement digesting as done previously by the Performance Schema is now done at the SQL level regardless of whether the Performance Schema is compiled in and is available to other aspects of server operation that could benefit from it. The default space available for digesting is 1024 bytes, but can be changed at server startup using the max_digest_length system variable.
In addition to those, there were 50 other bug fixes:
- 15 InnoDB
- 4 Replication
- 1 Partitioning
- 30 Miscellaneous
The highlights for me are the Partitioning bug and 2 of the Replication bugs (of the 15 InnoDB bugs, 5 were related to full-text search, and 6 were related to Memcached plugin, and the other 4 were mostly obscure):
- Partitioning: A number of ALTER TABLE statements that attempted to add partitions, columns, or indexes to a partitioned table while a write lock was in effect for this table were not handled correctly.
- Replication: When gtid_mode=ON and slave_net_timeout was set to a low value, the slave I/O thread could appear to hang. This was due to the slave heartbeat not being sent regularly enough when the dump thread found many events that could be skipped. The fix ensures that the heartbeat is sent correctly in such a situation.
- Replication: When replicating from a MySQL 5.7.6 or later server to a MySQL 5.6.23 or earlier server, if the older version applier thread encountered an Anonymous_gtid_log_event it caused an assert. The fix ensures that these new log events added in MySQL 5.7.6 and later do not cause this problem with MySQL 5.6.24 and later slaves.
So while there were no major changes, the partitioning fix covered a number of bugs, the replication fixes could potentially be important for you, and the numerous InnoDB full-text and Memcached fixes would be important if you’re using either of those. Thus if you rely on any of this, I’d consider upgrading.
The full 5.6.24 changelogs can be viewed here (which has more details about all of the bugs listed above):
Hope this helps. 🙂
MySQL 5.6.23 was recently released (it is the latest MySQL 5.6, is GA), and is available for download here.
For this release, there is 1 “Security Note”, 3 “Functionality Changed”, and 5 “Compilation Notes”, all benign, but let me address them:
- Security Note: The linked OpenSSL library for the MySQL Commercial Server has been updated from version 1.0.1j to version 1.0.1k. Issues fixed in the new version are described at http://www.openssl.org/news/vulnerabilities.html.
- Functionality Changed: Support for the SSL 2.0 and SSL 3.0 protocols has been disabled because they provide weak encryption. (Bug #19820550, Bug #19921150)
- Functionality Changed: yaSSL was upgraded to version 2.3.7. (Bug #19695101, Bug #20201864)
- Functionality Changed: The valid date range of the SSL certificates in mysql-test/std_data has been extended to the year 2029. (Bug #18366947)
In addition to those, there were 37 other bug fixes:
- 13 InnoDB
- 5 Replication
- 18 Miscellaneous
- 1 Partitioning
The highlights for me are the Partitioning bug, 1 of the Replication bugs, and 8 of the InnoDB bugs, as 1 was a regression bug (crashing/corruption) and the others include bugs that raise invalid assertions, server halts, break replication, and so forth, though all in all, I wouldn’t say any of these are very common and require immediate attention:
- InnoDB: If a DROP DATABASE statement failed on the master, mismatched tables could be left on the slave, breaking replication. This was caused by the DROP TABLE statement being binary logged if at least one table was deleted during the DROP DATABASE operation. The fix ensures that in such a situation the DROP TABLE statement is binary logged with the IF EXISTS option. (Bug #74890, Bug #20041860)
- InnoDB: A tablespace export operation set the purge state to PURGE_STATE_STOP but the purge thread did not check the purge state until the current purge operation was completed. In the case of a large history list, the tablespace export operation was delayed, waiting for the current purge operation to finish. The purge state is now checked with every purge batch. (Bug #20266847, Bug #75298)
- InnoDB: An ALTER TABLE … ADD INDEX operation raised an assertion due to assertion code that did not allow an online index status of ONLINE_INDEX_ABORTED_DROPPED. The assertion code has been relaxed. (Bug #20198726)
- InnoDB: DML operations on a table with full-text search indexes raised an invalid assertion. (Bug #19905246) References: This bug is a regression of Bug #19314480.
- InnoDB: A multiple-table delete operation caused the server to halt. (Bug #19815702)
- InnoDB: A FLUSH TABLES operation raised an assertion. (Bug #19803418)
- InnoDB: With change buffering enabled, a buffered sequence of operations that should not have been buffered resulted in an Unable to purge a record error. (Bug #19528825, Bug #73767)
- InnoDB: A slow shutdown (innodb_fast_shutdown=0) after crash recovery raised an assertion. Slow shutdown did not wait for background rollback operations to finish before proceeding. (Bug #16862810)
- Partitioning: A failed ALTER TABLE … TRUNCATE PARTITION statement or a failed TRUNCATE TABLE statement against a partitioned table sometimes left inconsistent metadata in the table cache; subsequent SQL statements reusing this metadata failed, and could in some cases also lead to a failure of the server. (Bug #74292, Bug #19786861)
- Replication: When using SHOW SLAVE STATUS to monitor replication performance, Seconds_Behind_Master sometimes displayed unexpected lag behind the master. This was caused by Previous_gtids log events being written to the slave’s relay log with a timestamp behind the master, and then being used to calculate the Seconds_Behind_Master. This fix ensures that events generated on the slave that are added to the relay log and are not used when calculating Seconds_Behind_Master. (Bug #72376, Bug #18622657)
So while there were no major changes, those 8 InnoDB bugs, especially in total, are of concern, so I’d consider upgrading if I were running InnoDB on a prior version of 5.6.
And with the yaSSL updates, if you use SSL connections, you may want to consider upgrading as well.
The full 5.6.23 changelogs can be viewed here (which has more details about all of the bugs listed above):
Hope this helps. 🙂
MySQL 5.6.22 was recently released (it is the latest MySQL 5.6, is GA), and is available for download here.
For this release, there is 1 “Security Note”, 2 “Functionality Changed”, and 5 “Compilation Notes”, all benign, but let me address them:
- Security Note: The linked OpenSSL library for the MySQL Commercial Server has been updated from version 1.0.1h to version 1.0.1j. Issues fixed in the new version are described at http://www.openssl.org/news/vulnerabilities.html.
- Functionality Changed: Replication: The variable binlogging_impossible_mode has been renamed binlog_error_action. binlogging_impossible_mode is now deprecated. (Bug #19507567)
- Functionality Changed: Security: yaSSL was upgraded to version 2.3.5. (Bug #19695101)
- Compilation Notes: These are all rather minor, so I’ll spare the full entries here. However, if you build MySQL from source, it would be worth several minutes to read the 5 notes in the changelogs.
In addition to those, there were 46 other bug fixes:
- 17 InnoDB
- 9 Replication
- 19 Miscellaneous
- 1 Partitioning
The highlights for me are 6 of the InnoDB bugs, as 2 were regression bugs (crashing/corruption), 2 potentially corruption causing, another crashing, and 1 halting:
- InnoDB: An ALTER TABLE operation raised an assertion. When a foreign key object was removed from the dictionary cache, an incorrect foreign key object was removed from the rb-tree. (Bug #19908343) References: This bug is a regression of Bug #18806829.
- InnoDB: Pages with a checksum value of zero were incorrectly treated as empty pages. A page should only be considered empty if its checksum value and LSN field values are zero. (Bug #19500258, Bug #73689) References: This bug is a regression of Bug #17335427.
- InnoDB: The dict_set_corrupted() function attempted to update the clustered index of the SYS_INDEXES data dictionary table incorrectly. (Bug #19584379).
- InnoDB: The InnoDB data dictionary was not updated when a ALTER TABLE … CHANGE COLUMN operation changed the case of the column name. (Bug #19465984).
- InnoDB: A memory access violation caused fts_optimize_thread and mysqld to terminate. (Bug #19314480).
- InnoDB: A procedure, called from a function to perform an operation on a temporary table, caused the server to halt/stall. (Bug #19306524)
So while there were no major changes, those 6 InnoDB bugs (2 being regression bugs) are definitely of concern, so I’d be sure to review these to see if you’re running an affected version, and consider upgrading if so.
And with the yaSSL updates, if you use SSL connections, you may want to consider upgrading as well.
The full 5.6.22 changelogs can be viewed here (which has more details about all of the bugs listed above):
Hope this helps. 🙂