MySQL 5.6.21 Community Release Notes

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.21.

In particular:

  • Thank you to Yoshinori Matsunobu who reported that during recovery GTID-based replication would need to scan all binary logs. We have since introduced an option for simplified recovery in the case a large number of binary log files exist. Bug #69097.
  • Thank you to Michael Newton for reporting that mysqldump should hexdump geometry data types when invoked with the --hex-blob command line option. Although we did not use his patch, we also thank Martin Hradil for contributing to the bug report. Bug #43544.
  • Thank you to Yoshinori Matsunobu for reporting that a large number of partitions could consume much more memory than previous versions of MySQL. This regression was introduced from an earlier bug fix. Bug #70641.
  • Thank you to Tianzhou Chen for reporting a security issue. Bug #73650.
  • Thank you to Qixiu Xiao for reporting that retrieving multiple values (gets) via InnoDB’s memcached interface would return incorrect results. The InnoDB memcached interface does not currently support retrieval of multiple values at once, and has since been changed to produce an error instead. Bug #72453.
  • Thank you to David Schwartz for reporting that performing operations on a timed out key would fail using InnoDB’s memcached interface. Bug #72586.
  • Thank you to Jeremy Cole for reporting that a failed in-place ALTER TABLE operation would leave behind a non-unique temporary file, preventing future modifications. Jeremy also provided a testcase demonstrating how to easily reproduce the issue. Bug #72594.
  • Thank you to Inaam Rana for reporting inaccurate handling of srv_activity_count in the InnoDB source code. Inaam also contributed a patch to fix the issue. Bug #72137.
  • Thank you to Jeremy Cole for providing an example where InnoDB will drastically under fill pages. Thank you also to Davi Arnaut, who commented on Jeremy’s bug report, and demonstrated a simpler test-case to be able to reproduce. Bug #67718.
  • Thank you to Sadao Hiratsuka for reporting that mysqlbinlog could not safely concatenate files with GTID-based replication. Bug #71695.
  • Thank you to Yoshinori Matsunobu for reporting that with semi-sync replication, setting a slave to a binary log position in the future would cause an assertion on the master. We have changed the behaviour to produce an error. Bug #70327.
  • Thank you to Alexander Du for reporting that when an SQL thread which was waiting on a lock is killed, it could cause transactions to be skipped on a slave. Bug #69873.
  • Thank you Zhai Weixiang for reporting that a server could hang on shutdown when semi-sync replication is in use. Bug #71047.
  • Thank you to Santosh Praneeth Banda for reporting that starting/stopping the sql thread on a slave could cause a transaction to be logged with a different GTID than on the master. Bug #72313.
  • Thank you to Hartmut Holzgraefe for reporting that having two slaves with the same server_uuid resulted in a misleading error message. Based on Hartmut’s feedback, the slave error now identifies the duplicate server UUID and the master error identifies the zombie thread that has been killed. Bug #72578.
  • Thank you to Jean-François Gagné for reporting an out of memory scenario when using RBR and slave having different data types. Bug #72610.
  • Thank you to Rolf Martin-Hoster for reporting that MySQL did not correctly handle the general or slow query log as a FIFO or socket file. Bug #67088.
  • Thank you to Laurynas Biveinis for reporting that A simultaneous OPTIMIZE TABLE and online ALTER TABLE on the same InnoDB table could result in deadlock. Laurynas also provided a test-case and example patch. Bug #71433.
  • Thank you to Elena Stepanova for reporting that the query cache was not correctly invalidated when a CASCADE DELETE or CASCADE UPDATE constraint was specified, and the table names contained special characters. Bug #72547.

Thank you again to all the community contributors listed above. In particular, the MySQL team would like to call out the names that appear more than once in this release:

Yoshinori Matsunobu (3), Laurynas Biveinis (2), Jeremy Cole (2)

If I missed a name here, please let me know!

– Morgan

Published by

morgo

I joined MySQL AB in 2006, left, and am now back at Oracle working on the MySQL team. I’ve also worked at Percona and InPowered.

  • Greg Lane

    There is a lot of great fixes here. One I have a question about is bug #43544 being resolved. I found a bug, #72495, in myqlbinlog that was related to #43544. I wonder if the fix on #43544 also corrects this issue. Would you know if this possibly was checked?

    • The bug #72495 is still present in 5.6.21. Here is the testcase I tried:

      create table point (location POINT);
      insert into point values(GeomFromText(‘POINT(1 1)’)),(GeomFromText(‘POINT(2 2)’)),(GeomFromText(‘POINT(3 3)’));

      Rbook-8:data root# ../bin/mysqlbinlog –base64-output=decode-rows -v -v Rbook-8-bin.000002 | grep -F “Don’t know how to handle column”
      ### @1=!! Don’t know how to handle column type=255 meta=4 (0004)# at 594

      • Greg Lane

        I hadn’t been able to test it as of yet, but I had hoped it would since now the data will be in hex. Figured that may clear up the problem because of the change.

  • Laurynas Biveinis

    Thanks Morgan. I feel that I’m getting much more credit than deserved: I have not independently reported the issue in bug 69097, I just discovered that it was fixed in 5.6.21. Then bug 71433 is a joint work between me and Rich Prohaska and Joel Epstein of Tokutek, not me alone.