MySQL 5.6.19 was recently released (it is the latest MySQL 5.6, is GA), and is available for download here.
I should actually call this post “5.6.18 and 5.6.19 Overview and Highlights”.
The 5.6 “Release Notes” Index provides an entry/changelog for 5.6.18 and says it was released 2014-04-11. However, it’s not available in the community download archives. This isn’t mentioned in the 5.6.18 changelogs, but it is in the 5.6.19 changelogs, where it says:
“There is no MySQL Community Server 5.6.18. That version number was used for an out-of-schedule release of the Enterprise Edition to address the OpenSSL ‘Heartbleed’ issue. This issue did not affect the Community Edition because it uses yaSSL, not OpenSSL, so a new release of the Community Server was not needed, and 5.6.17 is followed by 5.6.19.”
While Heartbleed did not affect the *community* versions of MySQL 5.6, it does affect the *commercial* versions of MySQL 5.6 (less than 5.6.18). This is because the *community* version of MySQL 5.6 was built using yaSSL (unaffected SSL library), whereas the *commercial* version of MySQL 5.6 was build using OpenSSL (vulnerable SSL library). So take note of this if you’re running *commercial* MySQL 5.6.
There is also an important “known limitation” of this release, which affects MySQL 5.6.10 through and including 5.6.18, which is:
“If you have InnoDB tables with full-text search indexes and you are upgrading from MySQL 5.6.10 to a MySQL version up to and including MySQL 5.6.18, the server will fail to start after the upgrade (Bug#72079). This bug is fixed in MySQL 5.6.19. As a workaround, remove full-text search indexes prior to upgrading and rebuild full-text search indexes after the upgrade is completed.”
So beware of this if you’re running 5.6.10+, using InnoDB full-text search indexes, and plan on upgrading to 5.6.11 – 5.6.18.
There was also one other bug fixed in the 5.6.18 release notes, but just a rather obscure one related to running a collated subquery on an ARCHIVE table containing an AUTO_INCREMENT column.
Now, as for 5.6.19, there are more fixes:
2 Functionality Added or Changed, which all seem quite minor:
- The obsolete and unmaintained charset2html utility has been removed from MySQL distributions. (Bug #71897, Bug #18352347)
- The mysqlbug, mysql_waitpid, and mysql_zap utilities have been deprecated and will be removed in MySQL 5.7.
And I counted 32 bug fixes (6 InnoDB, 7 Replication, and 19 misc. bugs).
I found the more important/noteworthy bug fixes to be:
- InnoDB: After upgrading from 5.6.10 to MySQL versions up to and including MySQL 5.6.18, InnoDB would attempt to rename obsolete full-text search auxiliary tables on server startup, resulting in an assertion failure. (Bug #18634201, Bug #72079)
- InnoDB: The fix for Bug#17699331 caused a high rate of read/write lock creation and destruction which resulted in a performance regression. (Bug #18345645, Bug #71708). This regression bug affects versions 5.6.16 – 5.6.18.
- InnoDB: For each insert, memset would be called three times to allocate memory for system fields. To reduce CPU usage, the three memset calls are now combined into a single call. (Bug #17858679, Bug #71014)
- InnoDB: Enabling the InnoDB Table Monitor would result in a ib_table->stat_initialized assertion failure. (Bug #17039528, Bug #69641)
- InnoDB: With innodb_max_dirty_pages_pct=0 buffer pool flushing would not be initiated until the percentage of dirty pages reached at least 1%, which would leave up to 1% of dirty pages unflushed. (Bug #13029450, Bug #62534)
- Replication: Log rotation events could cause group_relay_log_pos to be moved forward incorrectly within a group. This meant that, when the transaction was retried, or if the SQL thread was stopped in the middle of a transaction following one or more log rotations (such that the transaction or group spanned multiple relay log files), part or all of the group was silently skipped. This issue has been addressed by correcting a problem in the logic used to avoid touching the coordinates of the SQL thread when updating the log position as part of a relay log rotation whereby it was possible to update the SQL thread’s coordinates when not using a multi-threaded slave, even in the middle of a group. (Bug #18482854)
- Replication: In certain cases, the server mishandled triggers and stored procedures that tried to modify other tables when called by CREATE TABLE … SELECT. This is now handled correctly as an error. (Bug #18137535)
- Replication: When used on a table employing a transactional storage engine, a failed TRUNCATE TABLE was still written to the binary log and thus replayed on the slave. This could lead to inconsistency when the master retained data that was removed on the slave. Now in such cases TRUNCATE TABLE is logged only when it executes successfully. (Bug #17942050, Bug #71070)
- For indexes on prefixes or character string columns, index corruption could occur for assignment of binary data to the column due to improper character counting. (Bug #18359924)
- mysqldump could create table definitions in the dump file that resulted in Too many columns errors when reloading the dump file. (Bug #17477959)
- On Windows, REPAIR TABLE and OPTIMIZE TABLE failed for MyISAM tables with .MYD files larger than 4GB. (Bug #69683, Bug #17235179)
- If you’re running 5.6 *commercial*, and not running 5.6.18 or 5.6.19, you need to upgrade now.
- If you’re running 5.6.10 through 5.6.18 and using InnoDB full-text indexes, and if you upgrade to a 5.6 version less than 5.6.19, you will encounter problems (though there is a work-around mentioned above).
- The InnoDB fixes were somewhat specific, so I would only consider the regression bug that affected 5.6.16 – 5.6.18 to be an overall worrier, but read through them to be sure none of the others affect you.
- Similarly, the couple replication fixes were also somewhat specific, so read through those to see if they could affect you.
The full changelogs can be viewed here (which has more details about all of the bugs listed above), 5.6.18 and 5.6.19 listed respectively:
Hope this helps. 🙂