September 16, 2014

2 new features added to Percona XtraDB Cluster (PXC) since 5.5.31

With the last Percona XtraDB Cluster (PXC) release, two major features were added:

* a new command to bootstrap the cluster was added to the init script
* SST via Xtrabackup now supports Xtrabackup 2.1 features

In this post, I want to explain the benefits of these added features and how to use them.

If you follow the mysqlperformanceblog regularly, you’ve already noticed that there are several ways to start a node and that it’s not always easy to start the node that is supposed to bootstrap the entire cluster.

See :
- http://www.percona.com/blog/2013/01/29/how-to-start-a-percona-xtradb-cluster/
- http://www.percona.com/doc/percona-xtradb-cluster/manual/bootstrap.html
- http://www.lefred.be/node/167
- new undocumented option –wsrep-new-cluster

With the new option, bootstrap-pxc, there is no need to modify my.cnf or add parameters (when supported) to the init script. Now you can simply bootstrap (start the first node that will initiate the cluster) using one of these commands :

or

Much easier, isn’t it ?

Now the second added feature is the support of xbstream from Xtrabackup 2.1.

This is useful as it will help to speed up SST operations as the backup could be performed in parallel, compressed and compacted (without copying the secondary indexes).

To configure this, you just need to add two sections to my.cnf: [sst] and [xtrabackup] like this:

Some example to compare the effect of these parameters.

We have one database with 4 InnoDB tables of 480M, and we test Xtrabackup SST with the following settings:

Blue:Xtrabackup with tar (default)
Red: Xtrabackup with xbstream and 2 threads (like the configuration above)
Yellow: Xtrabackup with xbstream and 4 threads

SST_XBSTREAM

This quick benchmark was realized on a small dataset with tables not having secondary indexes (no benefits from compact). I will prepare a more detailed benchmark for a future blog post.

But we can see that the new settings helps to “free” the donor faster, but the process on the joiner takes more time.
So it depends on what are your constraints to choose the best options that fit your workload’s requirements.

Remember: to be able to use Xtrabackup as SST you need to add in my.cnf:
wsrep_sst_method=xtrabackup
wsrep_sst_auth=user:password

Important: to be able to use xbstream with compression, you need to have qpress installed on the system and in the mysql user’s path (like /usr/bin for example).

Also the MySQL datadir must be empty before starting the SST process (see lp:1193240)

If you want to get familiar with these new options, I’ve updated my puppet recipes available on github.

Note:
For rebuild-threads, the default is $(grep -c processor /proc/cpuinfo) and for qpress, the decompression is also done in parallel (with number of qpress instances == $(grep -c processor /proc/cpuinfo)).

About Frederic Descamps

Frédéric joined Percona in June 2011, he is an experienced Open Source consultant with expertise in infrastructure projects as well in development tracks and database administration.

Frédéric is a believer of devops culture.

Comments

  1. Alex says:

    Hi Fred,
    It also would be very interesting to see the results for multiple threads but without compact and compress options. The best donor result shows about ~50 seconds – for 480Mb data it is ~10Mb/sec, if compressed, then even less. This is far from saturation of 1Gb network. This suggests that the bottleneck is CPU – as it normally is in SST, even with rsync. What I’m insinuating is that all you need is parallel threads, and without compact option you’re likely to get far better results on joiner, and without compress – on both donor and joiner.

    Regards.

  2. Hi Alex,

    Yes sure, I’m planning to benchmark all options on decent machines with a realistic database (multiple secondary indexes, …)

    Cheers,

  3. Fred,

    Why would you use “compact” for state transfer ? I can understand compressed and multi thread which can be helpful when transferring over slow network. Compact may make sense in theory for even slower network but I doubt someone would run cluster with extremely poor network speed.

  4. Regarding compact, compacting the backups, especially when there
    are multiple large secondary indexes (which is common), should
    really reduce the size of payload transferred among nodes during
    SST. For a table with only the primary key it won’t have any
    visible impact.

Speak Your Mind

*