Announcement of Percona XtraDB Cluster (alpha release)

I am happy to announce the availability of alpha release of our new product Percona XtraDB Cluster.

Percona XtraDB Cluster is High Availability and Scalability solution for MySQL Users and based on Percona Server 5.5.17

Percona XtraDB Cluster provides:

  • Synchronous replication. Transaction either commited on all nodes or none.
  • Multi-master replication. You can write to any node.
  • Parallel applying events on slave. Real “parallel replication”.
  • Automatic node provisioning.
  • Data consistency. No more unsyncronised slaves.

Percona XtraDB Cluster is fully compatible with MySQL or Percona Server in the following meaning:

  • Data compatibility. Percona XtraDB Cluster works with databases created in MySQL / Percona Server
  • Application compatibility. There is no or minimal application changes required to start work with Percona XtraDB Cluster

Percona XtraDB Cluster is based on Percona Server with XtraDB and includes Write Set REPlication patches. It uses the Galera library, version 2.x, a generic Synchronous Multi-Master replication plugin for transactional applications.

The Galera library is developed by Codership Oy company and
Galera 2.x supports such new features as:

  • Incremental State Transfer, especially useful for WAN deployments
  • RSU, Rolling Schema Update. Schema change does not block operations against table

Please note, this is an alpha release, not suitable for production yet. Bugs and some rough edges are expected. We are encouraging you to try and play with it in testing environment and report us your feedback and experience.


Previous posts on this topic:

Share this post

Comments (30)

  • Henrik Ingo

    Hi Vadim and team

    Congratulations to everyone for launching this! This will be a game changer in the MySQL world.

    January 9, 2012 at 1:23 pm
  • Steve Jackson

    Now this rox. Certainly gonna have a play…

    January 9, 2012 at 1:50 pm
  • marrtins

    Wow, cool! Will try this some day.

    January 9, 2012 at 1:59 pm
  • Andy

    This is huge. Congrats!

    Will this work with handlersocket? I’m using Percona Server 5.5 with handlersocket.

    January 9, 2012 at 2:36 pm
  • pcrews

    I’ll be writing more about the testing we’ve been doing soon, but it’s looking quite solid so far!

    January 9, 2012 at 2:52 pm
  • Louis

    Sounds terrific. Can’t wait to try that. Thanks!

    January 9, 2012 at 3:36 pm
  • nowgoo

    Great work, Congrats! I’ll test it soon.

    January 9, 2012 at 5:42 pm
  • jackbillow

    good job,congratulations. it become more and more for mysql with ha, replication issue and many node write nodes.

    January 9, 2012 at 6:29 pm
  • Shlomi Noach

    I agree with Henrik. This is a game changer. To have a MySQL server with synchronous replication built in resolves (most of) the need for an external HA solution, of slave promotion issues, slave lag issues etc. Am anxious to see how this goes.

    January 9, 2012 at 10:47 pm
  • vineet

    Great News, Looking forward for stable release soon.
    Especially i am looking for Galera with XtraDB storage engine as Galera with InnoDB have problems like increase in deadlock.

    January 10, 2012 at 2:12 am
  • Fraj

    Good News, i will try it

    January 10, 2012 at 2:39 am
  • Henrik Ingo

    Vineet: XtraDB will behave exactly the same wrt deadlocks. You should write your code so that deadlocked transactions are handled correctly (usually just re-start them). If you can’t do that, you can choose to write to a single master to get same behavior as with a standalone innodb. (Using other nodes for redundancy or as read-only nodes.)

    January 10, 2012 at 3:32 am
  • vineet

    Thanks Henrik for your input.

    I ran sysbench against Galera nodes and got huge no. of deadlocks. Figures are below (its a very small infrastructure based test)

    Galera with Single Node
    transactions: 133423 (148.13 per sec.)
    deadlocks: 0 (0.00 per sec.)
    total time: 900.7191s

    Galera with 2 Node
    transactions: 271778 (301.85 per sec.)
    deadlocks: 8544 (9.49 per sec.)
    total time: 900.3745s

    Galera with 3 Node
    transactions: 303919 (337.55 per sec.)
    deadlocks: 7084 (7.87 per sec.)
    total time: 900.3613s

    As Percona guys done lots of changes at storage engine level for performance so i was thinking of improvement in deadlock cases.

    January 10, 2012 at 3:52 am
  • Henrik Ingo

    Hi Vineet: interesting numbers. Maybe you had much smaller table than I used in my own sysbench tests (thus causing more collisions). See for same benchmark I did. Even in the worst case I have less than 0.25% of deadlocks and not at all under light load.

    It’s not the amount of deadlocks that worries me, but that they might happen at all. I’m not sure all code out there handles deadlocks properly, so unless people review their code they’ll start seeing spurious errors. But otoh the frequency of deadlocks is so small maybe they won’t notice that they have a problem. (Codership guys say that nobody has complained about this so far…)

    January 10, 2012 at 4:13 am
  • vineet

    Henrik, I already follow your blogs 🙂 .

    But i can’t compare my results with yours as i do tests on very small scale like 4~8 GB RAM.

    Might be right time for me to revisit my tests and update Codership guys for the same.

    January 10, 2012 at 4:31 am
  • Henrik Ingo

    Vineet: Actually, it is interesting information to see the amount of deadlocks increase when you have a smaller table. You said you have 4-8GB of RAM, but how many rows in your sysbench table, and how many tables?

    January 10, 2012 at 4:37 am
  • Peter Zaitsev


    What parameters did you use for Run ?

    Sysbench by default creates a pretty serious hotspot. Also note the cross node deadlock detection in Percona XtraDB Cluster is different from the one for single note – it is essentially optimistic locking as such no wait happens in case 2 transactions update the same row but on commit one of transactions will fail.

    In sysbench this can be easily exposed yet it is often less of the problem in the real world unless you’re having some very hot rows, such as counters etc.

    January 10, 2012 at 5:09 am
  • vineet

    @Henrik & Peter

    I used below parameters for my test.

    sysbench –num-threads=99 –max-time=900 –max-requests=1000000 –test=oltp –mysql-host=,, –mysql-user=root –mysql-password=rootpass –mysql-table-engine=InnoDB –mysql-engine-trx=yes –max-requests=0 –oltp-table-size=1000000 –oltp-auto-inc=off run

    And i have started my test with Single table (Which is default in SysBench).

    That will be other scenario for me to test Galera with different no. of tables.

    January 10, 2012 at 5:17 am
  • Henrik Ingo

    Ok, so you have 20x less rows than I had, and get roughly 60x more deadlocks. Interesting comparison 🙂

    January 10, 2012 at 5:56 am
  • Peter Zaitsev


    One thing you might want to try to change in addition to table size is –oltp-dist-type=uniform this will use uniform distribution touching all rows with same frequency.

    January 10, 2012 at 10:41 am
  • Alex


    Looking at how the deadlock rate actually _decreases_ with the number of nodes added and looking at the number of concurrent connections, I’d suggest that you have oversaturated benchmark. Transactions simply sit there too long waiting for CPU – hence have a higher chance of a conflict. I suspect that if you decrease -num-threads parameter, you’ll get better scores and less deadlocks.

    January 10, 2012 at 8:18 pm
  • vineet

    @Henrik: Thanks for your input.

    @Peter: Thanks for your suggestion, I’ll try this out.

    @Alex: My testing is in initial phase, I have many scenarios to test. Will try your suggestion and update you guys accordingly.

    January 10, 2012 at 9:57 pm
  • Mark Grennan

    So Flashcache is enabled. Cool.
    How can I turn this off. I’m getting:

    120111 14:10:39 [Note] Flashcache bypass: disabled
    120111 14:10:39 [Note] Flashcache setup error is : ioctl failed

    January 11, 2012 at 1:20 pm
  • Vadim


    It says it is disabled. You can just ignore these [Note]

    January 11, 2012 at 1:22 pm
  • Developer

    What is the difference (in features, limitations, etc…) between Xtradb cluster compared to MySQL cluster?

    And, if one is already deployed on MySQL cluster, does switching to Xtradb cluster at this point make sense or is it too immature?

    January 11, 2012 at 2:59 pm
  • Vadim Tkachenko


    MySQL Cluster is very different, so it is hard to make correct comparison.

    There is my opinion, which may be not full

    Percona XtraDB Cluster
    ● It is based on widely used XtraDB/InnoDB engine.
    ● It is almost drop-in replacement for existing installation of MySQL replication
    ● Minimal or NO application changes
    ● Less additional knowledge for DBA is required to run XtraDB Cluster than NDB Cluster.

    MySQL NDB Cluster is totally different engine than MySQL Replication
    ○ Requires changes in hardware
    ○ Requires application changes
    ○ Requires very knowledgeable DBA
    ○ Very hard for diagnostic and troubleshooting
    ○ expensive to deploy and maintain

    Percona XtraDB Cluster has:
    ○ Minimal entry barrier for one who switches from MySQL Replication or for new deployments.

    Also please see

    However I advise to make changes only if you need it.
    If you currently run MySQL Cluster and you happy with it, you should stay with it.

    January 11, 2012 at 5:34 pm
  • Developer

    Vadim, thanks for the info. To follow up, are there are features provided by mysql cluster that is NOT available in xtradb cluster?

    EG: MySQL cluster supports online DDL, whereas it seems that online DDL is not supported by xtradb cluster?
    DDL statements are problematic and may stall cluster. Later, the support of DDL will be improved, but will always require special treatment.

    EG: MySQL cluster 7.2 supports join-push down with adaptive query localization. Is that supported by xtradb cluster?

    Also, what is the maximum # of data nodes and sql nodes supported by xtradb cluster? The documentation does not mention an upper limit on the # of nodes, whereas ndb is limited to 48 data nodes and 256 total nodes.

    January 11, 2012 at 5:52 pm
  • Vadim Tkachenko


    Yes, there are features in MySQL Cluster that is not available in XtraDB Cluster. Again, it is totally different products.

    MySQL Cluster is designed for scale out, XtraDB Cluster is not.

    Online schema change is work in progress in XtraDB Cluster and some solution will be available later.

    join-push is not applicable to XtraDB Cluster, as all queries in XtraDB Cluster are executed locally on node where query was initialized.

    There is no software limitation for amount of nodes, but there will be logical limitation when sending transaction to all N nodes will be to expensive and will kill your performance. The number N is individual for each setup and depends on hardware, network connections, workload.

    January 11, 2012 at 6:08 pm
  • Henrik Ingo

    Pretty good discussion here on NDB vs XtraDB clusters.

    One point that didn’t come up is that NDB is a real-time database. You can be guaranteed that for some threshold of N, 99.9…% of your queries will have a response time less than N. For simple key value operations N is 1 or 2 ms. For InnoDB (ie XtraDB Cluster) you will not see as stable performance as this, although if your data fits in memory it will be pretty good in practice.

    Also, it is said that NDB is totally different and therefore very difficult to understand, and you will need application changes if migrating from a standard MySQL server to an NDB Cluster. This is all true. Otoh in your case if you are already running on MySQL Cluster, the same might be true the other way: you might be better of just staying where you are.

    January 12, 2012 at 2:00 am
  • Max

    What Vadim and Henrik are saying is very true, MySQL Cluster is a completely different animal. I guess the two main differences come from MySQL Cluster doing two things:

    1) Separation of MySQL Server and Storage Engine; meaning that the Storage Engine is run as a separate process which can then be on a different machine. This adds great flexibility as you can add MySQL Servers and data nodes independently but adds complexity

    2) Data partitioning; MySQL Cluster partitions the data automatically between the data nodes which means that it’s great for scale-out (as Vadim mentioned) as write queries scale as well (with more than 2 data nodes). This is a great benefit compared to most other solutions. The downside with this is again complexity, both for the administrators and internal complexity. The commit protocol for example has so many messages that cluster is pretty much useless on a geographical scale. What you can do of course is combine MySQL Cluster with replication, but then you’re back to asynch.

    So all in all, either you design your application for MySQL Cluster or you don’t. It is never (ok, hardly ever) a drop in replacement.

    January 13, 2012 at 11:44 am

Comments are closed.

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