maria-developers team mailing list archive

[Pavel Ivanov <pivanof@xxxxxxxxxx>]

On Sun, Nov 17, 2013 at 4:06 AM, Alex Yurchenko
<alexey.yurchenko@xxxxxxxxxxxxx> wrote:
>>>>> 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.

It looks like during the conversation both of us have got completely
confused with terminology and talked about different meanings of
performance in different places. So let me try to bring that to a more
sensible description. To be short I'll consider only three different
aspects of performance:

1. Maximum steady rate of completely independent transactions measured
long after the beginning of testing. For semi-sync this is limited to
1 per RTT to the closest node. The safe limit (the one when farthest
nodes won't fall behind in replication) could be lower, but it depends
mostly on network throughput to the farthest node (not on RTT). I
don't know what are limiting factors in Galera for this situation, but
I'm sure that with the right implementation of inter-node
communication Galera can outperform semi-sync by a big margin here.

2. Maximum steady rate of dependent transactions (e.g. updates to a
single row) measured long after the beginning of testing. For
semi-sync this is the same as for previous one -- limited to 1 per RTT
to the closest node. For Galera this is limited to 1 per RTT to the
farthest node, so definitely worse than with semi-sync.

3. Sudden burst of parallel dependent transactions, i.e. what maximum
number of updates to a single row can one perform in parallel in say
15 seconds (probably from hundreds of connections) if he didn't
perform any transactions before that and won't perform any
transactions after those 15 seconds. For semi-sync with
rpl_semi_sync_master_wait_point = AFTER_COMMIT this is limited only to
performance of a single node as if there was no replication at all
(just writing of binlogs). For semi-sync with
rpl_semi_sync_master_wait_point = AFTER_SYNC this is still limited to
1 per RTT to the closest node. For Galera this is still limited to 1
per RTT to the farthest node.

So anyone who's reading this can make his own conclusions what
tradeoffs he prefers to make for his production systems.


Pavel