Percona XtraDB Cluster 5.6.14-25.1 Beta is now available

Percona is glad to announce the first Beta release of Percona XtraDB Cluster 5.6 on November 21st, 2013. Binaries are available from downloads area or from our software repositories.

Based on Percona Server 5.6.14-62.0 including all the bug fixes in it, Galera Replicator 3.1 and on Codership wsrep API 5.6.14-25.1 is now the first BETA release. All of Percona’s software is open-source and free, all the details of the release can be found in the 5.6.14-25.1 milestone at Launchpad.

This release contains all of the features and bug fixes in Percona XtraDB Cluster 5.5.34-23.7.6, plus the following:

New Features:

  • Percona XtraDB Cluster is now using Galera Replicator 3.1 and wsrep API 5.6.14-25.1.
  • Percona XtraDB Cluster has implemented a number of XtraDB performance improvements for I/O-bound high-concurrency workloads.
  • Percona XtraDB Cluster has implemented a number of performance improvements for Page cleaner thread tuning.
  • ALL_O_DIRECT method for innodb_flush_method has been ported from 5.5 version.
  • Statement Timeout feature has been ported from the Twitter branch.
  • Percona XtraDB Cluster has extended the SELECT INTO ... OUTFILE and SELECT INTO DUMPFILE to add the support for UNIX sockets and named pipes.
  • Percona XtraDB Cluster has implemented more efficient log block checksums with new innodb_log_checksum_algorithm variable.
  • Percona XtraDB Cluster now supports Per-query variable statements.
  • Limited support for Query Cache has been implemented. Query cache cannot still be fully enabled during the startup. To enable query cache, mysqld should be started with query_cache_type=1 and query_cache_size=0 and then query_cache_size should be changed to desired value during runtime.
  • RPM packages are now made relocatable which means they now support installation to custom prefixes.

Bugs Fixed:

  • Some wsrep variables (wsrep_provider, wsrep_provider_options, wsrep_cluster_address…) could be “doubly” allocated which caused memory leaks. Bug fixed #1072839.
  • If SELECT FOR UPDATE... query was aborted due to multi-master conflict, the client wouldn’t get back the deadlock error. From client perspective the transaction would be successful. Bug fixed #1187739.
  • Temporary tables are not replicated, but any DDL on those tables were, which would generates error messages on other nodes. Bugs fixed #1194156, #1084702, #1212247.
  • When setting the gcache.size to a larger value than the default 128M, the mysql service command did not allow enough time for the file to be pre-allocated. Bug fixed #1207500.
  • When installing first Percona-XtraDB-Cluster-client and then Percona-XtraDB-Cluster-server on two single statements or a single statement with both packages , yum would install percona-xtrabackup-20 instead percona-xtrabackup package as dependency of Percona-XtraDB-Cluster-server. Bug fixed #1226185.
  • Different mutex implementation in the 5.6 could lead to server assertion error. Bug fixed #1233383.
  • Enabling wsrep_log_conflicts variable could cause issues with lock_mutex. Bug fixed #1234382.
  • Server could freeze with mixed DML/DDL load because TOI brute force aborts were not properly propagated. Bug fixed #1239571.
  • CREATE TABLE AS SELECT would fail with explicit temporary tables, when binlogging was enabled and autocommit was set to 0. Bug fixed #1240098.
  • Transaction cleanup function did not get called for autocommit statements after rollback, it would stay in LOCAL_COMMIT even after rollback finished which caused problems when the next transaction started. Bug fixed #1240567.
  • DDL statements like CREATE TEMPORARY TABLE LIKE would be replicated and applied in all cluster nodes. This caused temporary table definitions to pile up in slave threads. Bug fixed #1246257.
  • CREATE TABLE AS SELECT was not replicated, if the select result set was empty. Bug fixed #1246921.
  • Write set flags defined in wsrep API are now exposed to application side appliers too. Bug fixed #1247402.
  • Local brute force aborts are now counted accurately. Bug fixed #1247971.
  • Certain combinations of transaction rollbacks could leave stale transactional MDL locks. Bug fixed #1247978.
  • After turning UNIV_SYNC_DEBUG on, node that was started from clean state would crash immediately at startup. Bug fixed #1248908.
  • Server built with UNIV_SYNC_DEBUG would assert if SQL load has DELETE statements on tables with foreign key constraints with ON DELETE CASCADE option. Bug fixed #1248921.
  • Xtrabackup SST dependencies have been added as Optional/Recommended/Suggested dependencies. Bug fixed #1250326.

Other bugs fixed: bug fixed #1020457, bug fixed #1250865, bug fixed #1249753, bug fixed #1248396, bug fixed #1247980, bug fixed #1238278, bug fixed #1234421, bug fixed #1228341, bug fixed #1228333, bug fixed #1225236, bug fixed #1221354, bug fixed #1217138, bug fixed #1206648, bug fixed #1200647, bug fixed #1180792, bug fixed #1163283, bug fixed #1234229, bugs fixed #1250805, bug fixed #1233301, and bug fixed #1210509.

Release notes for Percona XtraDB Cluster 5.6.14-25.1 are available in our online documentation along with the installation and upgrade instructions. We did our best to eliminate bugs and problems during the testing release, but this is a software, so bugs are expected. If you encounter them, please report them to our bug tracking system.

Share this post

Comments (13)

  • lolomin

    Hi Hrvoje,

    Could you please tell if upgrade is possible from 5.5 to 5.6 or not ? I know this is a beta and not production ready but this is interesting to know.
    I saw on codership’s google group that it seems upgrade from 5.5 was not possible for codership’s release :!topic/codership-team/0N-ySkM6deM



    November 21, 2013 at 8:29 am
  • Hrvoje Matijakovic

    As Seppo commented on the , by setting up those options “simple” 5.6 -> 5.5 replication will work and you should be able to upgrade cluster without downtime (depending on your load and settings). You can enable writes on 5.5 nodes and upgrade them one by one, switching them to read-only as they become upgraded to 5.6, then switch the writes to one of them and upgrade the last node. This still isn’t recommended for production as it require more testing. If you test and run into any issues please report them on Launchpad.

    November 21, 2013 at 11:10 am
  • Raghavendra


    To elaborate on what Hrvoje mentioned already, upgrade of a node
    from 5.5 to 5.6 is certainly possible. However, at a cluster
    level, 5.6 –> 5.5 replication has issues, hence, during upgrade,
    5.6 nodes have to be read-only (as far as this release is
    concerned) while non-upgraded 5.5 nodes take writes (5.5 –> 5.6 replications works fine with parallell applying OFF (wsrep-slave-thread=1)). Once all the nodes in cluster are 5.6 (and/or when last 5.5 node has been taken from the cluster for upgrade), then writes can be enabled on 5.6 nodes. You can refer to linked upgrade documentation here –

    November 21, 2013 at 11:30 am
  • Mark Willis

    Does this 5.6 version contain the FULLTEXT index type for INNODB tables?

    November 21, 2013 at 11:37 am
  • Jay Janssen

    Mark: PXC 5.6 has all the features of Percona Server 5.6, which in turn has all the features of MySQL Community 5.6

    November 21, 2013 at 11:47 am
  • Mark Willis

    Awesome 🙂 can’t wait to try it out. Typically how long is the Beta period?

    November 21, 2013 at 11:49 am
  • Jay Janssen

    @Mark: However long it takes 🙂

    November 21, 2013 at 11:50 am
  • Marc Castrovinci

    Any chance the galera replicator accidently got pushed into the 5.5 apt repo?

    Yesterday all installs worked and today 5.5 was breaking. The percona apt repo was installing percona-xtradb-cluster-galera-3.x instead of percona-xtradb-cluster-galera-2.x. After I manually switched packages, the server started fine.

    November 21, 2013 at 12:40 pm
  • Roel Van de Paar

    @Marc, thanks for letting us know & submitting a proper bug report. We’re on it.

    November 21, 2013 at 5:38 pm
  • Raghavendra


    Updated the bug (and documentation), can you check that and let us know if thats fine.

    November 21, 2013 at 11:30 pm
  • Raghavendra

    The galera-2/3 conflict has been fixed. The interchangeability of packages moved to next release –

    November 22, 2013 at 2:15 am
  • lolomin

    @Hrvoje @Raghavendra,

    Thanks for these informations ! Will try this release soon.

    November 22, 2013 at 3:44 am
  • Marc Castrovinci


    Works again. Thanks for the quick fix!

    November 22, 2013 at 10:00 am

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.