Percona is glad to announce the release of Percona XtraDB Cluster 5.5.34-25.9 on December 4, 2013. Binaries are available from the downloads area or from our software repositories.

Based on Percona Server 5.5.34-32.0 including all the bug fixes in it, Galera Replicator and on Codership wsrep API 5.5.34-25.9, Percona XtraDB Cluster 5.5.34-25.9 is now the current stable release. All of Percona’s software is open-source and free. This is an General Availability release.

New Features:

  • Percona XtraDB Cluster is now based on wsrep API 25 and Galera 25.2.x.
  • RPM packages are now made relocatable which means they now support installation to custom prefixes.
  • XtraBackup SST now supports innodb_data_home_dir and innodb_log_home_dir in the configuration file.
  • The binaries are now statically linked with regard to Galera library which depended on OpenSSL library.

Bugs fixed:

  • Product suffix has been added to the Percona XtraDB Cluster rpm packages, which means that packages have been renamed from Percona-XtraDB-Cluster-server to Percona-XtraDB-Cluster-server-55. Bug fixed #1255616.
  • Fixed the dependency issue which caused Percona XtraDB Cluster 5.5 installation to fail on Ubuntu 12.04. Bug fixed #1247861.
  • 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.
  • 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 (in this case it was TRUNCATE), which would generates error messages on other nodes. Bug fixed #1194156.
  • 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 preallocated. Bug fixed #1207500.
  • CREATE TABLE AS SELECT would fail with explicit temporary tables, when binlogging was enabled and autocommit was set to 0. Bug fixed #1240098.
  • Write set flags defined in wsrep API are now exposed to application side appliers too. Bug fixed #1247402.
  • Local brute force aborts are counted accurately. Bug fixed #1247971.
  • Certain combinations of transaction rollbacks could leave stale transactional MDL locks and cause deadlocks. 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 Suggested dependencies for DEB packages. Bug fixed #1250326.
  • init stop script on CentOS didn’t wait for the server to be fully stopped. This would cause unsuccessful server restart because the start action would fail because the daemon would still be running. Bug fixed #1254153.
  • Memory leak in mem_root has been fixed. Bug fixed #1249753.
  • Galera is now packaged with garbd init script. Bug fixed #1256769.

Other bugs fixed: bug fixed #1247980, bug fixed #891476, bugs fixed #1250805, bug fixed #1253923.

Note: Because some package names have been changed, with the product suffix being added, please check the manual before starting new installations. Debian users are requested to use apt-get dist-upgrade or apt-get install for upgrade, for more refer to installation guide.

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. Release notes for Percona XtraDB Cluster 5.5.34-25.9 are available in our online documentation.

Percona XtraDB Cluster Errata can be found in our documentation.

16 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Dirk

To upgrade to the new cluster version, I have to use dist-upgrade (like mentioned above), but I have to downgrade the galera package. This is the 3rd proposal my apt gives me, the first being to de-install the cluster package, the second to do nothing. Everything works fine when I do this, but it is somewhat confusing.

Downgrade the following packages:
1) percona-xtradb-cluster-galera-2.x [162.precise (now) -> 158.precise ()]

0
Raghavendra

@Dirk,

The downgrade suggested by debian was normal since this galera package is from a different api/tree (galera-25). We had documented it here https://www.percona.com/doc/percona-xtradb-cluster/5.5/installation/apt_repo.html#percona-apt-experimental-repository as well (sometime back).

But, to avoid this confusion, we have pushed another package with version bumped manually, so the updated package should look percona-xtradb-cluster-galera-2.x 163.precise (it is exactly the same as 158.precise sans the version bump).

0
Dirk

@Raghavendra: Thank you for your clarification!

0
Aziz

Hi,

I have a big problem during the update.
The first node is starting without problem with the command line : /etc/init.d/mysql bootstrap-pxc
But the second and third node, I have this problem :
xbstream: Can’t create/write to file ‘././backup-my.cnf’ (Errcode: 17)
xbstream: failed to create file.
2013/12/16 14:30:49 socat[24987] E write(1, 0xa9f3e0, 1504): Broken pipe
WSREP_SST: [ERROR] Xbstream failed (20131216 14:30:49.124)
WSREP_SST: [ERROR] Data directory /datas/mysql/ may not be empty: lp:1193240 Manual intervention required in that case (20131216 14:30:49.127)
WSREP_SST: [ERROR] Cleanup after exit with status:32 (20131216 14:30:49.129)
WSREP_SST: [INFO] Removing the sst_in_progress file (20131216 14:30:49.131)
131216 14:30:49 [ERROR] WSREP: Process completed with error: wsrep_sst_xtrabackup –role ‘joiner’ –address ‘192.168.118.3’ –auth ‘sst:33tp@ssw0rd’ –datadir ‘/datas/mysql/’ –defaults-file ‘/etc/mysql/my.cnf’ –parent ‘24796’: 32 (Broken pipe)
131216 14:30:49 [ERROR] WSREP: Failed to read uuid:seqno from joiner script.
131216 14:30:49 [ERROR] WSREP: SST failed: 32 (Broken pipe)
131216 14:30:49 [ERROR] Aborting
131216 14:30:49 [Warning] WSREP: 1 (node_cluster_2): State transfer to 0 (node_cluster_3) failed: -1 (Operation not permitted)
131216 14:30:49 [ERROR] WSREP: gcs/src/gcs_group.c:gcs_group_handle_join_msg():719: Will never receive state. Need to abort.

Can you help me, please

0
Dirk

Hi Aziz,

I had the same problems with the update. Empty the data dir on your second and third node (one by one) and let them do a SST. Things should work after that…

Cheers,

Dirk

0
Raghavendra

@Dirk, @Aziz,

Usage of xtrabackup-v2 is recommended, otherwise if you are using wsrep-sst-method=xtrabackup, you need to either use streamfmt=tar or cleanup the data dir manually.

Please check https://www.percona.com/doc/percona-xtradb-cluster/5.5/wsrep-system-index.html#wsrep_sst_method and https://www.percona.com/doc/percona-xtradb-cluster/5.5/manual/xtrabackup_sst.html (for compatibility with older versions (< 33), sst method =xtrabackup is recommended).

0
Aziz

Ok, thx Dirk for your quickly response. I test this.
Why I haven’t got this problem in my VM nodes, only in phisical servers

0
Aziz

@Raghavendra,

Thx for your response, I use the xtrabackup sst method and xtrabackup-v2.
Concerning streamfmt, I use xbstream, is it a problem ?

Best regards

0
Aziz

Hi,

I followed your recommendations, so I emptied the mysql directory.
When I start mysql in the second node, the first is out of sync (I use clustercheck). Why?
Can I restart the first node while the second node has not completed its sync ?

0
Aziz

The starting is so long in the second and third node.
Is it normal ?
I have this error in the first node :
2013/12/16 15:49:55 socat[22332] E write(3, 0x179b200, 8192): Broken pipe
WSREP_SST: [ERROR] socat -u stdio TCP:192.168.118.1:4444 finished with error: 1 (20131216 15:49:55.467)
WSREP_SST: [ERROR] Cleanup after exit with status:22 (20131216 15:49:55.470)

Thx for your help

0
Aziz

I forgot, my datadir is in the other disk. It’s in the SSD

0
Aziz

Hi everybody,

I have systematically, this error :
xbstream: Can’t create/write to file ‘././backup-my.cnf’ (Errcode: 17)
xbstream: failed to create file.
when I start and stop my node. I have already empty the data dir many times.
I think there is a bug with the update PXC.

Best regards

Aziz

0
Aziz

I forgot the suit of message :
2014/01/28 15:37:23 socat[12159] E write(1, 0x1f533e0, 44): Broken pipe
WSREP_SST: [ERROR] Xbstream failed (20140128 15:37:23.803)
WSREP_SST: [ERROR] Data directory /var/lib/mysql/ may not be empty: lp:1193240 Manual intervention required in that case (20140128 15:37:23.804)
WSREP_SST: [ERROR] Cleanup after exit with status:32 (20140128 15:37:23.806)
WSREP_SST: [INFO] Removing the sst_in_progress file (20140128 15:37:23.807)
140128 15:37:23 [ERROR] WSREP: Process completed with error: wsrep_sst_xtrabackup –role ‘joiner’ –address ‘192.168.60.11’ –auth ‘sst:33tp@ssw0rd’ –datadir ‘/var/lib/mysql/’ –defaults-file ‘/etc/mysql/my.cnf’ –parent ‘11984’: 32 (Broken pipe)
140128 15:37:23 [ERROR] WSREP: Failed to read uuid:seqno from joiner script.
140128 15:37:23 [ERROR] WSREP: SST failed: 32 (Broken pipe)
140128 15:37:23 [ERROR] Aborting

0
Raghavendra

@Aziz,

You have to use xtrabackup-v2 as the SST method or manually clean the datadir (or use tar as the stream method) prior to SST.

0
Aziz

@Raghavendra,

Thx very much for your help, it’s working.

0
Palash

I am using xtrabackup-v2 but still one of my node was failing to start. Then I cleaned up the datadir manually then it worked. Those who are having problem even after cleaning up the datadir, if you cd to that directory and ls then you will not see a directory named .sst which has some files. so cd to that directory and cleanup everything. It worked for me. Thanks. Just to know, even I am using “xtrabackup-v2” why it was failing? any idea?

0