Percona Server 5.6.22-71.0 is now available

Percona ServerPercona is glad to announce the release of Percona Server 5.6.22-71.0 on January 12, 2015. Download the latest version from the Percona web site or from the Percona Software Repositories.

Based on MySQL 5.6.22, including all the bug fixes in it, Percona Server 5.6.22-71.0 is the current GA release in the Percona Server 5.6 series. Percona Server is open-source and free – and this is the latest release of our enhanced, drop-in replacement for MySQL. Complete details of this release can be found in the 5.6.22-71.0 milestone on Launchpad.

New Features:

  • Percona Server has implemented improved slow log reporting for queries in stored procedures.
  • TokuDB storage engine package has been updated to version 7.5.4. Percona Server with an older version of TokuDB could hit an early scaling limit when the binary log was enabled. TokuDB 7.5.4 fixes this problem by using the hints supplied by the binary log group commit algorithm to avoid fsync’ing its recovery log during the commit phase of the 2 phase commit algorithm that MySQL uses for transactions when the binary log is enabled.

Bugs Fixed:

  • Debian and Ubuntu init scripts no longer have a hardcoded server startup timeout. This has been done to accommodate situations where server startup takes a very long time, for example, due to a crash recovery or buffer pool dump restore. Bugs fixed #1072538 and #1328262.
  • A read-write workload on compressed InnoDB tables might have caused an assertion error. Bug fixed #1268656.
  • Selecting from GLOBAL_TEMPORARY_TABLES table while running an online ALTER TABLE in parallel could lead to server crash. Bug fixed #1294190.
  • A wrong stack size calculation could lead to a server crash when Performance Schema tables were storing big amount of data or in case of server being under highly concurrent load. Bug fixed #1351148 (upstream #73979).
  • A query on an empty table with a BLOB column may crash the server. Bug fixed #1384568 (upstream #74644).
  • A read-write workload on compressed InnoDB tables might have caused an assertion error. Bug fixed #1395543.
  • If HandlerSocket was enabled, the server would hang during shutdown. Bug fixed #1397859.
  • The default MySQL configuration file, my.cnf, was not installed during a new installation on CentOS. Bug fixed #1405667.
  • The query optimizer did not pick a covering index for some ORDER BY queries. Bug fixed #1394967 (upstream #57430).
  • SHOW ENGINE INNODB STATUS was displaying two identical TRANSACTIONS sections. Bug fixed #1404565.
  • A race condition in Multiple user level locks per connection implementation could cause a deadlock. Bug fixed #1405076.

Other bugs fixed: #1394357, #1337251, #1399174, #1396330 (upstream #74987), and #1401776 (upstream #75189).

Known Issues:
If you’re upgrading TokuDB package on CentOS 5/6 you’ll need to restart the MySQL service after the upgrade, otherwise TokuDB storage engine won’t be initialized.

Release notes for Percona Server 5.6.22-71.0 are available in the online documentation. Please report any bugs on the launchpad bug tracker

Share this post

Comments (2)

  • Ken Zalewski Reply

    Ever since Percona released version 5.6.16, your claim that Percona Server is a “drop-in replacement for MySQL” has not been accurate. When 5.6.16 was released, you changed the name of the MySQL client library from libmysqlclient to libperconaserverclient. Multiple users complained. We explored some workarounds, as can be seen in some of the following comments:

    https://www.percona.com/blog/2014/03/17/percona-server-5-6-16-64-1-now-available/#comment-5524150
    https://www.percona.com/blog/2014/03/25/percona-server-5-6-16-64-2-now-available/#comment-6228562
    https://www.percona.com/blog/2014/06/11/percona-server-5-6-17-66-0-now-available/#comment-7272279

    However, the issue at hand has never been resolved. There is no easy way to build Percona Server from source so that it truly is a drop-in replacement for MySQL. I requested that you provide a build-time option to specify the name of the client library, and Roel Van DePaar indicated that he logged the issue internally (BLD-169), but that was during the 5.6.17 release cycle in June 2014. I haven’t heard anything since then.

    Even the workaround no longer works properly, because mysql_config.sh has “-lperconaserverclient” hard-coded into it. It used to build with the library name as specified in the CMakeLists.txt file (which I had to edit to change “perconaserverclient” to “mysqlclient”).

    Now, I have to edit mysql_config.sh as well, to change “perconaserverclient” to “mysqlclient”.

    None of this is difficult or time-consuming, but it is certainly annoying.

    Will this issue ever be addressed appropriately?

    January 14, 2015 at 5:31 pm
  • Roel Van de Paar Reply

    @Ken Yes. Whilst I am no longer directly responsible for this area, I followed up on the same internal discussion. We may have some good news yet (no promises…). There is however more then one aspect here, for example the potential need for separate repo’s etc. I understand and share your frustration with this issue. Please stay tuned, and hopefully we will have something for you soon on this.

    January 15, 2015 at 5:22 pm

Leave a Reply