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.
Answering to myself: indeed this can be done if transactions are
committed on master asynchronously and only OK is sent to client after
ACK from slave. But then semi-sync should be capable of more than 1/RTT
transactions per second, yet somehow it is not what was found in any
benchmark that I know of. So this is still a controversy I'm begging you
to resolve.
--
Alexey Yurchenko,
Codership Oy, www.codership.com
Skype: alexey.yurchenko, Phone: +358-400-516-011
_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
