MySQL 5.5.45 Overview and Highlights

MySQL 5.5.45 was recently released (it is the latest MySQL 5.5, is GA), and is available for download here:

http://dev.mysql.com/downloads/mysql/5.5.html

This release, similar to the last 5.5 release, is mostly uneventful.

There were 0 “Functionality Added or Changed” items this time, 1 “Security Fix”, and just 9 bugs overall fixed.

Out of the 9 bugs, there were 3 InnoDB bugs, 1 security-related bug, and 1 potential crashing bug. Here are the ones worth noting:

  • InnoDB: An index record was not found on rollback due to inconsistencies in the purge_node_t structure.
  • InnoDB: An assertion was raised when InnoDB attempted to dereference a NULL foreign key object.
  • InnoDB: On Unix-like platforms, os_file_create_simple_no_error_handling_func and os_file_create_func opened files in different modes when innodb_flush_method was set to O_DIRECT. (Bug #76627)
  • 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)
  • Crashing Bug: GROUP BY or ORDER BY on a CHAR(0) NOT NULL column could lead to a server exit.

I don’t think I’d call any of these urgent for all (unless you run the latest RHEL/CentOS with SSL connections + a DHE SSL cipher specifed with –ssl-cipher=DHE-RSA-…), but if running 5.5, especially if not a very recent 5.5, you should consider upgrading.

For reference, the full 5.5.45 changelog can be viewed here:

http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-45.html

Hope this helps.

MySQL 5.5.44 Overview and Highlights

MySQL 5.5.44 was recently released (it is the latest MySQL 5.5, is GA), and is available for download here:

http://dev.mysql.com/downloads/mysql/5.5.html

This release, similar to the last 5.5 release, is mostly uneventful.

There were 0 “Functionality Added or Changed” items this time, and just 15 overall bugs fixed.

Out of the 15 bugs, there were 5 InnoDB bugs (1 of which also spans partitioning), 1 security-related bug, 1 performance-related, and 3 additional potential crashing bugs. Here are the ones worth noting:

  • InnoDB: An assertion was raised on shutdown due to XA PREPARE transactions holding explicit locks.
  • InnoDB: Removal of a foreign key object from the data dictionary cache during error handling caused the server to exit.
  • InnoDB: SHOW ENGINE INNODB STATUS output showed negative reservation and signal count values due to a counter overflow error.
  • InnoDB: Estimates that were too low for the size of merge chunks in the result sorting algorithm caused a server exit.
  • InnoDB; Partitioning: The CREATE_TIME column of the INFORMATION_SCHEMA.TABLES table now shows the correct table creation time for partitioned InnoDB tables. The CREATE_TIME column of the INFORMATION_SCHEMA.PARTITIONS table now shows the correct partition creation time for a partition of partitioned InnoDB tables. The UPDATE_TIME column of the INFORMATION_SCHEMA.TABLES table now shows when a partitioned InnoDB table was last updated by an INSERT, DELETE, or UPDATE. The UPDATE_TIME column of the INFORMATION_SCHEMA.PARTITIONS table now shows when a partition of a partitioned InnoDB table was last updated. (Bug #69990)
  • Security-related: A user with a name of event_scheduler could view the Event Scheduler process list without the PROCESS privilege.
  • 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)
  • Crashing Bug: SHOW VARIABLES mutexes were being locked twice, resulting in a server exit.
  • Crashing Bug: Under certain conditions, the libedit command-line library could write outside an array boundary and cause a client program crash.
  • 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.

I don’t think I’d call any of these urgent for all, but if running 5.5, especially if not a very recent 5.5, you should consider upgrading.

For reference, the full 5.5.44 changelog can be viewed here:

http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-44.html

Hope this helps.

MySQL 5.5.43 Overview and Highlights

MySQL 5.5.43 was recently released (it is the latest MySQL 5.5, is GA), and is available for download here:

http://dev.mysql.com/downloads/mysql/5.5.html

This release, similar to the last 5.5 release, is mostly uneventful.

There were only 2 “Functionality Added or Changed” items this time, and 10 additional bugs fixed.

Out of the 10 bugs, there was 1 InnoDB bug, 1 replication bug, and 6 crashing bugs, all of which seemed rather minor or obscure. Here are the ones worth noting:

  • Functionality Changed: CMake support was updated to handle CMake version 3.1.
  • Functionality Added: 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)
  • Replication: When using a slave configured to use a special character set such as UTF-16, UTF-32, or UCS-2, the receiver (I/O) thread failed to connect. The fix ensures that in such a situation, if a slave’s character set is not supported then default to using the latin1 character set.
  • InnoDB: Certain InnoDB errors caused stored function and trigger condition handlers to be ignored.
  • Large values of the transaction_prealloc_size system variable could cause the server to allocate excessive amounts of memory. The maximum value has been adjusted down to 128K. A similar change was made for transaction_alloc_block_size. Transactions can still allocate more than 128K if necessary; this change reduces the amount that can be preallocated, as well as the maximum size of the incremental allocation blocks.
  • Crashing Bug: Ordering by a GROUP_CONCAT() result could cause a server exit.
  • Crashing Bug: A malformed mysql.proc table row could result in a server exit for DROP DATABASE of the database associated with the proc row.
  • Crashing Bug: A server exit could occur for queries that compared two rows using the <=> operator and the rows belonged to different character sets.
  • Crashing Bug: The optimizer could raise an assertion due to incorrectly associating an incorrect field with a temporary table.
  • Crashing Bug: The server could exit due to an optimizer failure to allocate enough memory for resolving outer references.
  • Crashing Bug: Creating a FEDERATED table with an AUTO_INCREMENT column using a LIKE clause results in a server exit.

I don’t think I’d call any of these critical, but if running 5.5, especially if not a very recent 5.5, you should consider upgrading.

For reference, the full 5.5.43 changelog can be viewed here:

http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-43.html

Hope this helps.

 

MySQL 5.5.42 Overview and Highlights

MySQL 5.5.42 was recently released (it is the latest MySQL 5.5, is GA), and is available for download here:

http://dev.mysql.com/downloads/mysql/5.5.html

This release, similar to the last 5.5 release, is mostly uneventful.

There were only 3 “Functionality Added or Changed” bugs this time, all related to SSL, and only 9 bugs overall fixed.

Out of the 9 bugs, there were 2 InnoDB bugs, and 1 replication bug, all of which seemed rather minor or obscure. Here are the ones worth noting:

  • Support for the SSL 2.0 and SSL 3.0 protocols has been disabled because they provide weak encryption. (Bug #19820550, Bug #19921150)
  • yaSSL was upgraded to version 2.3.7. (Bug #19695101, Bug #20201864)
  • The valid date range of the SSL certificates in mysql-test/std_data has been extended to the year 2029. (Bug #18366947)
  • InnoDB: An error occurred when the push_warning_printf function was invoked during server recovery. This function was previously used to print a warning message to the client. Also, current_thd was NULL when the server was restarted. (Bug #20144839)
  • InnoDB: A multiple-table delete operation caused the server to halt. (Bug #19815702)
  • 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)

I don’t think I’d call any of these critical, but similar to the last release, if you depend on yaSSL, you may want to consider upgrading to ensure you’re using the latest yaSSL.

For reference, the full 5.5.42 changelog can be viewed here:

http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-42.html

Hope this helps.

 

MySQL 5.5.41 Overview and Highlights

MySQL 5.5.41 was recently released (it is the latest MySQL 5.5, is GA), and is available for download here:

http://dev.mysql.com/downloads/mysql/5.5.html

< Forgive me for the flurry of my latest release "Overview and Highlights" that will follow, as I had a serious-at-the-time health issue that delayed me for about a month. Back on track now though. :) >

This release, similar to the last 5.5 release, is mostly uneventful.

There was only 1 “Functionality Added or Changed” bugs this time, and 14 bugs overall fixed.

Out of the 14 bugs, there were 6 InnoDB bugs, and 2 replication bugs, all of which seemed rather minor or obscure. The one worth noting is the “Functionality Added or Changed” item, which was:

  • yaSSL was upgraded to version 2.3.5. (Bug #19695101)

With the recent yaSSL issues, if you use SSL certificates, you may want to consider upgrading to ensure you’re using the latest yaSSL.

Lastly, I should note there were some CMake notes, so if you compile MySQL yourself and use CMAKE, please see the full 5.5.41 changelogs.

For reference, the full 5.5.41 changelog can be viewed here:

http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-41.html

Hope this helps.

 

MySQL 5.6.21 Overview and Highlights

MySQL 5.6.21 was recently released (it is the latest MySQL 5.6, is GA), and is available for download here.

For this release, there was 1 “InnoDB Notes” and 1 “Functionality Added or Changed” bug fix (and 0 “Security Fix”), so not much there, but of course they should be noted:

  1. InnoDB Note: The –skip-innodb option is now deprecated and its use results in a warning. It will be removed in a future MySQL release. This also applies to its synonyms (–innodb=OFF, –disable-innodb, and so forth).
  2. Functionality Added: Internally, spatial data types such as Geometry are represented as BLOB values, so when invoked with the –hex-blob option, mysqldump now displays spatial values in hex. (Bug #43544, Bug #11752369)

In addition to those, there were 43 other bug fixes (the “partitioning” bug is also an “InnoDB” bug):

  • 12 InnoDB
  • 13 Replication
  • 18 Miscellaneous
  •   1 Partitioning

The highlights for me were 3 InnoDB regression bugs fixed and an important InnoDB/Partitioning performance-related bug fix as well (there were also 2 InnoDB/memcached bugs, and 13 replication bugs, so if using memcached or replication, you should review the full changelogs), so check if they might have affected you:

  1. InnoDB: An ALTER TABLE … ADD FOREIGN KEY operation could cause a serious error. (Bug #19471516, Bug #73650, Bug #73761 – Public, & Percona Bug #1366073)
  2. InnoDB: During recovery, a segmentation fault would occur when marking a table as corrupt. (Bug #18942294)
  3. InnoDB: With a transaction isolation level less than or equal to READ COMMITTED, gap locks were not taken when scanning a unique secondary index to check for duplicates. As a result, duplicate check logic failed allowing duplicate key values in the unique secondary index. (Bug #19140907, Public Bug #73170) References: This bug is a regression of Bug #16133801 (Public Bug #68021).
  4. InnoDB; Partitioning: Large numbers of partitioned InnoDB tables could consume much more memory when used in MySQL 5.6 or 5.7 than the memory used by the same tables used in previous releases of the MySQL Server. (Bug #17780517, Bug #70641) References: This bug was introduced by Bug #11764622, Bug #57480.

Conclusions:

So while there were no major changes, those 3 InnoDB 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.

The last bug really only relates to partitioned InnoDB tables, so if you’re not using them, then it’s not really a big deal. However, of course, if you are and you are running an affected version, then I would consider upgrading due to the memory over-consumption.

Similarly, if running memcached, I’d recommend checking those fixes and affected versions to see if you might benefit from an upgrade also.

The full 5.6.21 changelogs can be viewed here (which has more details about all of the bugs listed above):

http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-21.html

Hope this helps. 🙂

 

MySQL 5.5.40 Overview and Highlights

MySQL 5.5.40 was recently released (it is the latest MySQL 5.5, is GA), and is available for download here:

http://dev.mysql.com/downloads/mysql/5.5.html

This release, similar to the last 5.5 release, is mostly uneventful.

There were 0 “Functionality Added or Changed” bugs this time, and 18 bugs overall fixed.

Out of the 18 bugs, most seemed rather minor or obscure, but there are 3 I think are worth noting (all 3 are InnoDB-related, regressions, and serious if you encounter them, so best to be aware of them):

  • InnoDB: An ALTER TABLE … ADD FOREIGN KEY operation could cause a serious error. (Bug #19471516, Bug #73650)
  • InnoDB: With a transaction isolation level less than or equal to READ COMMITTED, gap locks were not taken when scanning a unique secondary index to check for duplicates. As a result, duplicate check logic failed allowing duplicate key values in the unique secondary index. (Bug #19140907) References: This bug is a regression of Bug #16133801.
  • InnoDB: During recovery, a segmentation fault would occur when marking a table as corrupt. (Bug #18942294)

Unfortunately, none of the bug reports are viewable. Even the one in public bug tracker has been marked “private”. So there is no telling what versions this affects. Bugs #73648 & 73648, the next closest viewable bugs were submitted 8/19/14 and 8/20/14, respectively. Thus it was a recently filed bug, and hopefully doesn’t affect too many previous versions. If I were running 5.5.39, using InnoDB with FKs, I think I’d upgrade. In fact, I might upgrade anyway because of the 3rd bug as well, because corruption is not that uncommon during recovery, and a segmentation fault at that time would just make a bad day worse.

For reference, the full 5.5.40 changelog can be viewed here:

http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-40.html

Hope this helps.

 

MySQL 5.6.20 Overview and Highlights

MySQL 5.6.20 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 Fix”, 1 “InnoDB Important Change”, and 7 “Functionality Added or Changed” fixes, all of which should be read in case they might affect you (though for this release, these mostly appear to be minor – some [default] changes, build notes/changes, and deprecations):

  1. Security Fix: The linked OpenSSL library for the MySQL 5.6 Commercial Server has been updated from version 1.0.1g to version 1.0.1h. Versions of OpenSSL prior to and including 1.0.1g are reported to be vulnerable to CVE-2014-0224. This change does not affect the Oracle-produced MySQL Community build of MySQL Server 5.6, which uses the yaSSL library instead.
  2. InnoDB Important Change: Redo log writes for large, externally stored BLOB fields could overwrite the most recent checkpoint. The 5.6.20 patch limits the size of redo log BLOB writes to 10% of the redo log file size. The 5.7.5 patch addresses the bug without imposing a limitation. For MySQL 5.5, the bug remains a known limitation. As a result of the redo log BLOB write limit introduced for MySQL 5.6, innodb_log_file_size should be set to a value greater than 10 times the largest BLOB data size found in the rows of your tables plus the length of other variable length fields (VARCHAR, VARBINARY, and TEXT type fields). Failing to do so could result in “Row size too large” errors. No action is required if your innodb_log_file_size setting is already sufficiently large or your tables contain no BLOB data. (Bug #69477)
  3. Replication: The new system variable binlog_impossible_mode controls what happens if the server cannot write to the binary log, for example, due to a file error. For backward compatibility, the default for binlog_impossible_mode is IGNORE_ERROR, meaning the server logs the error, halts logging, and continues updates to the database. Setting this variable to ABORT_SERVER makes the server halt logging and shut down if it cannot write to the binary log. (Bug #51014)
  4. CMake support was updated to handle CMake version 3.
  5. New Debian7, Ubuntu12.04, and Ubuntu14.04 distribution support that was introduced with 5.6.17 now comes with the platform-specific packaging source placed under the packaging directory, in the deb-precise, deb-wheezy, and deb-trusty directories.
  6. Support for LinuxThreads has been removed from the source code. LinuxThreads was superseded by NPTL in Linux 2.6. (Bug #72888)
  7. By default, mysql_install_db creates a my.cnf file in the installation base directory using a template. This may be undesireable for some deployments. To enable this behavior to be suppressed, mysql_install_db now supports a –keep-my-cnf option to preserve any existing my.cnf file and not create a new my.cnf file. (Bug #71600)
  8. The mysqlhotcopy utility is now deprecated and will be removed in a future version of MySQL. Among the reasons for this: It works only for the MyISAM and ARCHIVE storage engines; it works on Unix but not Windows. Alternatives include mysqldump and MySQL Enterprise Backup.
  9. The timed_mutexes system variable has no effect and is deprecated.

In addition to those, there were 52 other bug fixes:

  • 11 InnoDB
  • 09 Replication
  • 01 Partitioning
  • 31 Miscellaneous

There were 2 regression bugs fixed, so check if they might have affected you:

  1. InnoDB: A regression introduced in MySQL 5.6.5 would cause full-text search index tables to be created in the system tablespace (space 0) even though innodb_file_per_table was enabled.
  2. When a SELECT included a derived table in a join in its FROM list and the SELECT list included COUNT(DISTINCT), the COUNT() returned 1 even if the underlying result set was empty.

Conclusions:

I’ve not too much to say about this release regarding whether one should upgrade or not. I will say that if you are running a *Commercial* version of MySQL 5.6, pre-5.6.20, and you use SSL, then you should upgrade. Aside from that, it more depends if you’re affected by one of these bugs or not.

The full 5.6.20 changelogs can be viewed here (which has more details about all of the bugs listed above):

http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-20.html

Hope this helps. 🙂

 

MySQL 5.5.39 Overview and Highlights

MySQL 5.5.39 was recently released (it is the latest MySQL 5.5, is GA), and is available for download here:

http://downloads.skysql.com/archive/index/p/mysql/v/5.5.39

This release, similar to the last 5.5 release, is mostly uneventful.

There were two “Functionality Added or Changed” and 24 bugs fixed.

The “Functionality Added or Changed” changes are:

  • CMake support was updated to handle CMake version 3.
  • The timed_mutexes system variable has no effect and is deprecated.

Out of the 24 bugs, most seemed rather minor or obscure, but here are the ones I think are worth noting (crashing, security, wrong results, deadlock):

  • InnoDB: Opening a parent table that has thousands of child tables could result in a long semaphore wait condition.
  • Partitioning: Selecting from a table having multiple columns in its primary key and partitioned by LIST COLUMNS(R), where R was the last (rightmost) column listed in the primary key definition, returned an incorrect result. (Bug #71095)
  • Replication: When using row-based replication, updating or deleting a row on the master that did not exist on the slave led to failure of the slave when it tried to process the change. This problem occurred with InnoDB tables lacking a primary key. (Bug #72085)
  • Replication: A group of threads involved in acquiring locks could deadlock in a certain scenario. (Bug #69954)
  • ALTER TABLE on a partitioned table could result in the wrong storage engine being written into the table’s .frm file and displayed in SHOW CREATE TABLE.
  • MyISAM temporary files could be used to mount a code-execution attack.
  • An assertion could be raised when creating a index on a prefix of a TINYBLOB or GEOMETRY column in an InnoDB column.
  • Deadlock could occur if three threads simultaneously performed INSTALL PLUGIN, SHOW VARIABLES, and mysql_change_user(). (Bug #71236, Bug #72870)
  • MySQL did not compile with Bison 3. A workaround is to downgrade to Bison 2. (Bug #71250)

For reference, the full 5.5.39 changelog can be viewed here:

http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-39.html

Hope this helps.

 

MySQL 5.5.38 Overview and Highlights

MySQL 5.5.38 was recently released (it is the latest MySQL 5.5, is GA), and is available for download here:

http://downloads.skysql.com/archive/index/p/mysql/v/5.5.38

This release, similar to the last 5.5 release, is mostly uneventful.

Out of the mere 13 bugs, most were benign, but I thought there were two worth mentioning (just because one is a slight performance improvement for InnoDB, and the other relates to slave consistency, so always important to see if it could affect you):

  1. 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)
  2. 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 reference, the full 5.5.38 changelog can be viewed here:

http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-38.html

Hope this helps.