maria-developers team mailing list archive

[Alex Yurchenko <alexey.yurchenko@xxxxxxxxxxxxx>]

On 2013-11-17 04:44, Pavel Ivanov wrote:
> 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 so how does disabling XA and/or binlog imply throwing away the 
database? I kinda more than hinted a number of times that Galera nodes 
can do missing transactions replay...

> > > 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).

That's very curious. And semi-sync can do so while at the same time 
satisfying your requirement that the client finds the data even in the 
event of immediate master crash following OK?

What you are saying also implies that semi-sync can do more than 1/RTT 
transactions per second (if by "accept" we shall understand actual row 
modification, not mere queueing for lock). That refutes the findings of 
the tests I referred to, which to my knowledge so far have not been 
disputed by anybody. That makes it even more curious.

However your remark about 5.7.2 seems to smear this whole claim, and 
Oracle press release confirms that:

"MySQL 5.7.2 DMR also delivers lossless semi-synchronous replication, 
enabling transactions to only be committed to the storage engine and 
externalized on the master after the slave has acknowledged receipt."

This sounds like prior to 5.7.2 semi-sync isn't even that "semi-sync" as 
one would expect. So I'm not exactly sure how it can fit your 
requirements.

It would be really great if you could clear my confusion displayed 
above.

> > > > 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...

It caches replication events. It is as big as you configure it - and 
even bigger when necessary. And it works like a memory mapped ring 
buffer?

> > 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/.

If you choose so. But that really narrows your options...

> Pavel

--
Alexey Yurchenko,
Codership Oy, www.codership.com
Skype: alexey.yurchenko, Phone: +358-400-516-011