← Back to team overview

maria-developers team mailing list archive

Re: MariaDB Galera replication

 

On Sat, Nov 16, 2013 at 6:05 PM, Alex Yurchenko
<alexey.yurchenko@xxxxxxxxxxxxx> wrote:
>> 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


Follow ups

References