![](https://secure.gravatar.com/avatar/4c4b3ab90f978bc3864acb2bd873b611.jpg?s=120&d=mm&r=g)
On Sat, Nov 16, 2013 at 6:05 PM, Alex Yurchenko
Disabling log_bin and innodb_support_xa on Percona Cluster is also very nice -- how will you recover from server crashes?
And what other nodes are for? Don't you yourself want to employ semi-sync to avoid extra flushes? And how would you recover from crashes then? Here's the quote from your original post which prompted me to ask you about Galera:
"Semi-sync replication for us is a DBA tool that helps to achieve durability of transactions in the world where MySQL doesn't do any flushes to disk. As you may guess by removing disk flushes we can achieve a very high transaction throughput. Plus if we accept the reality that disks can fail and repairing information from it is time-consuming and expensive (if at all possible), with such reality you can realize that flush or no flush there's no durability if disk fails, and thus disk flushes don't make much sense."
This is exactly what we stand for with Galera: durability through redundancy. Or am I missing something?
For me "durability through redundancy" means if I said OK to client then client will always find the new data later even if immediately after the OK I pull the plug on the machine where master runs, or mysqld crashes. But that doesn't mean that every time mysqld crashed I want to throw away my database and start copying it from another node again.
And how about another killer case: what is the maximum number of parallel updates per second that you can make to a single row?
But of course, it is now well known, 1/RTT.
I guess this is true for Galera Cluster. MySQL with semi-sync can accept much more than that (not with the new default semi-sync mode from 5.7.2 though).
Yes, but it does not specify the sort of synchronization - whether it is a full state snapshot transfer or merely a catch up with missing transactions. But, depending on the circumstances any of those can occur.
It would be nice to see what algorithm is used to choose which kind of synchronization is necessary to do.
It is rather simple: if possible (required transactions are present in donor cache) - replay missing transactions, if not - copy a full snapshot. But yes, this area is not totally without gotchas yet...
I see one more new term here -- "donor cache". I have no idea what it is, how big it is and how it works...
This is not to say that our documentation doesn't suck, but how are these blog posts worse than something I would have written? Why should not I refer to 3rd party knowledge?
I think references to 3rd party knowledge is good as long as they can be easily discovered starting from here https://mariadb.com/kb/en/galera/. Pavel