MySQL 5.6.17 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.17.

In particular:

  • Thanks to Anthony Pong for reporting a confusing error message when mysql_install_db could not locate the required Perl modules. Bug #69844.
  • Thanks to Jervin Real for reporting a recently introduced performance regression with compressed InnoDB tables. Bug #71436.
  • Thanks to Laurynas Biveinis for reporting a race condition in InnoDB on shutdown. Bug #70430.
  • Thanks to Jervin Real for reporting that innodb_data_file_path could not be specified in kilobytes, as was indicated in the manual. Bug #68282.
  • Thanks to Elena Stepanova for reporting that InnoDB miscalculates auto-increment after changing auto_increment_increment. Bug #65225.
  • Thanks to qinglin zhang for reporting a memory leak in the slave sql thread, plus providing a suggested patch. While we did not end up using qinglin's patch, we value the contribution. Bug #71197.
  • Thanks to 徹 赤松 for reporting that SHOW SLAVE STATUS incorrectly reported the master's SSL information. Bug #70866.
  • Thanks to Yoshinori Matsunobu for reporting an issue where a slave can't continue replication after the master's crash recovery Bug #70669
  • Thanks to Erik Hoekstra for pointing out that using slave-parallel-workers may result in the error log being spammed with warnings. Bug #68429.
  • Thanks to Ovais Tariq for identifying that slaves with an additional auto-increment were not updated correctly. Bug #69680.
  • Thanks to Simon Mudd for suggesting that modifications to performance_schema tables should not be replicated. Bug #67159.
  • Thanks to Miguel Angel Nieto for identifying that temporary files created by binlog cache are not cleaned up. Bug #66237.
  • Thanks to hickey liu for reporting a race-condition in semi-sync replication. Bug #66411.
  • Thanks to Yoshinori Matsunobu for reporting excessive mutex contention in semi-sync replication. Bug #70218.
  • Thanks to honza horak for suggesting that mysqld --help should exit with a zero error code. Bug #70058.
  • Thanks to Jonathan Weaver for identifying that MySQL community edition client programs could not connect to MySQL enterprise servers with SSL enabled. Bug #68788.
  • Thanks to Jørgen Thomsen for reporting that mysqldump did not support the secure-auth parameter. Bug #69051.
  • Thanks to Raghavendra Prabhu for reporting an assertion when running Random Query Generator (RQG). Bug #69969.
  • Thanks to Tim McLaughlin for reporting that wrong results could be returned in a SELECT DISTINCT...GROUP BY query. We also thank Tim for reducing the bug to a minimal testcase. Bug #70657.
  • Thanks to Hartmut Holzgraefe for suggesting improvements to warnings written to the error log for invalid collations. Bug #68144.
  • Thanks to Ralf Adams for reporting that wrong results could be returned when using ALL() and GROUP BY. Ralf also provided a minimal testcase, which was useful in reproducing the issue. Bug #71244.
  • Thanks to Elena Stepanova for identifying that unquoted file names for variable values are accepted but parsed incorrectly. Bug #69703.
  • Thanks to Valeriy Kravchuk for suggesting that innodb_ft_result_search_limit should have a predictable maximum value. Bug #71554.

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:

Jervin Real (2), Yoshinori Matsunobu (2), Elena Stepanova (2)

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

- Morgan

  • Ram

    Hi Morgan,

    I'm getting below error on mysql 5.6.17 while creating a new instance

    2ada885aa760 InnoDB: Expected to open 4 undo tablespaces but was able

    2014-06-27 19:12:02 2ada885aa760 InnoDB: to find only 0 undo tablespaces.

    2014-06-27 19:12:02 2ada885aa760 InnoDB: Set the innodb_undo_tablespaces parameter to the

    2014-06-27 19:12:02 2ada885aa760 InnoDB: correct value and retry. Suggested value is 0

    • http://www.tocker.ca/ Morgan Tocker

      Hi Ram,

      This is covered in the manual:
      http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_undo_tablespaces
      "The number of innodb_undo_tablespaces must be set prior to initializing InnoDB. Attempting to restart InnoDB after changing the number of innodb_undo_tablespaces will result in a failed start with an error stating that InnoDB did not find the expected number of undo tablespaces."

      It is not a new change to 5.6.17.

      • Ram

        Thank you for reply, I already went through that manual.

        I'm creating new MySQL instance with version 5.6.17 with below parameters in my config file..

        System tablespaces are in /db/**/table/** , I created sub directory undo for undo tablespace and tried to create new instance but it's failing with below error.
        innodb_undo_tablespaces =4

        innodb_undo_directory =/db/**/table/**/undo

        innodb_undo_logs =0

        If I remove those above parameters, I can successfully create a new instance. My question is should undo tablespaces reside in separate drive or any other requirement??

  • Ram

    I'm using below parameters in my config file
    innodb_undo_tablespaces =4

    innodb_undo_directory =/db/**/table/**/undo

    innodb_undo_logs =0

  • Ram

    Thank you for reply but I already went through that manual.

    I'm creating new MySQL instance with version 5.6.17 with below parameters in my config file..

    System tablespaces are in /db/**/table/** , I created sub directory undo for undo tablespace and tried to create new instance but it's failing with below error.
    innodb_undo_tablespaces =4

    innodb_undo_directory =/db/**/table/**/undo

    innodb_undo_logs =0

    If I remove those above parameters, I can successfully create a new instance. My question is should undo tablespaces reside in separate drive or any other requirement??