Regards

The release that we tout for production is 0.7 and it is for MySQL 5.1.39. It’s been released Dec. 1st and we provide support for it (you can check out the patch and binary demos at no-url). 0.7.1 is coming out soon and will be for MySQL 5.1.41. In general, each MySQL/Galera release targets particular MySQL version (since it is a patch). In future we will continue to follow official MySQL GA releases with our own.

BR

The release that we tout for production is 0.7 and it is for MySQL 5.1.39. It’s been released Dec. 1st and we provide support for it (you can check out the patch and binary demos at https://launchpad.net/codership-mysql). 0.7.1 is coming out soon and will be for MySQL 5.1.41. In general, each MySQL/Galera release targets particular MySQL version (since it is a patch). In future we will continue to follow official MySQL GA releases with our own.

BR

Thanks for the reply. Which version (major+minor) of mysql should we use with it and can it be reliably used in a production environment. I was searching for such a solution and your answer will decide whether I can recommend to my client.

Thanks.

No. MySQL must be patched to make use of Galera replication, and the patch exists only for 5.1. There are no principal obstacles to port it to 5.0 (there is nothing special about 5.1 in this regard), however there is significant code divergence between 5.0 and 5.1, so it won’t be trivial.

Does Galera work with MySQL 5.0?

This is a rather interesting question, but the answer is not so straightforward. Galera cluster performance overhead comes not only from group communication latencies, but from a number of other factors and strongly depends on the load profile, number of CPU cores, IO subsystem and network configuration.

You’re absolutely right suggesting that more nodes mean more overhead, but even with TCP transport adding new node results in disproportionally low additional latency. You may want to check http://www.codership.com/en/content/sysbench-ec2-size-matters which is about the only case where it could be reliably measured. With multicast transport communication latencies should depend on the number of nodes even less.

That said, Galera replication overhead may be significant regardless of the number of nodes. You can see this effect taken to extreme in a very synthetic mysqlslap benchmark here: http://www.codership.com/en/content/benchmarking-write-scalability. Curiously, one way to make for additional communication overhead is to increase the number of concurrent server connections. Rule of thumb is to double the amount of connections per node compared to what gives the best performance on a standalone server.

Much bigger overhead comes from certification conflicts and resulting transaction rollbacks. The conflict rate grows roughly as N^2 and is the major limiting factor for multi-master scalability.

As for comparison with async master-slave – we don’t have any numbers yet. We don’t know of any benchmarks which can be used to benchmark performance of async master-slave cluster as a whole. Comparing just master performance is not so informative as standalone server.

Vadim,

I would not call that a “drawback” – it is a limitation . Galera replication is just a tool suitable for some tasks and unsuitable for others. As they say, YMMV.

I did not run benchmarks myself yet, but you can find some results on Codership’s website: http://www.codership.com/en/content/benchmarking-write-scalability . I have no reason to not believe them.

As you see for short transactions the penalty may be significant (compare numbers for 1 node), and it decreases with size of transaction, which is understandable.

For sure it’s drawback of technology, but it’s price for consistent data.

In an N nodes cluster, an update will only commit after it’s been propagated to all N nodes, right? That sounds like it could introduce significant performance drop.

“Donor” node is not “shut down”, it is just blocked for the duration of state snapshot transfer. This first implementation is using mysqldump which is slow, but at least as reliable as mysqldump itself and “just works”. Later we plan to add state transfer modes which would block donor for much shorter time, but may require some special setup (like LVM). Incremental state transfer is also in the works.

But for now you could just keep a special reserved “donor” node for such purposes, and it does not have to be as powerful as “working” nodes: applying writesets requires much less resources than serving clients.