List:Replication« Previous MessageNext Message »
From:MARK CALLAGHAN Date:September 15 2011 12:54am
Subject:Re: A feature patch for semi-sync
View as plain text  
2011/9/13 周振兴 <orczhou@stripped>:
> Hi all
>    Thanks, Mark. Here are more details and my test data.
> 2011/9/14 MARK CALLAGHAN <mdcallag@stripped>
>>
>> I think you should describe this in more detail for others to be
>> interested. What you have done is very interesting, but also not
>> trivial for us to understand.
>
> In MySQL-5.5 the semi-sync code is something like this:
> original semi-sync
>     binlog_prepare (do nothing)
>     innodb_prepare
>     ...
>     binlog_commit
>     innobase_commit
>     WAITING FOR THE SLAVE
> Now rpl_semi_sync_master_wait_before_commit=1
>     binlog_prepare (do nothing)
>     innodb_prepare
>     ...
>     binlog_commit
>     WAITING FOR THE SLAVE
>     innobase_commit

Without looking at 5.5 code "WAITING FOR THE SLAVE" is done while that
connection holds prepare_commit_mutex so all commits are blocked until
the wait ends. From looking at your performance number I assume you
have tested this on a system with a real (5 milliseconds or greater)
fsync latency. Assuming that the binlog fsync takes 10ms and the
average wait time for a slave to ack is 1ms, then your change won't do
much to limit throughput. But on a system with HW RAID or SSD/flash
then fsync latency is much lower and your change will reduce
performance by much more. The overhead from this will be also much
larger on versions of MySQL that use group commit for InnoDB+binlog
(which is in MariaDB, Percona and the Facebook patch).

I am not trying to criticize your work. I think is great work and hope
you present this at one of the community conferences. But can you make
the overhead of this low for systems with a fast fsync?  When fsync is
fast and the workload has few concurrent transactions there isn't much
that can be done to avoid the overhead. But for workloads with a lot
of concurrency and on a MySQL variant that supports group commit it
might be possible to minimize the overhead from this.

-- 
Mark Callaghan
mdcallag@stripped
Thread
A feature patch for semi-sync周振兴14 Sep
  • Re: A feature patch for semi-syncMARK CALLAGHAN14 Sep
    • Re: A feature patch for semi-sync周振兴14 Sep
      • Re: A feature patch for semi-syncMARK CALLAGHAN15 Sep
        • Re: A feature patch for semi-sync周振兴15 Sep
        • Re: A feature patch for semi-syncKristian Nielsen15 Sep
          • Re: A feature patch for semi-sync周振兴23 Sep
            • Re: A feature patch for semi-syncMARK CALLAGHAN23 Sep
              • Re: A feature patch for semi-sync周振兴23 Sep
  • Re: A feature patch for semi-sync周振兴20 Sep
    • Re: A feature patch for semi-syncMats Kindahl20 Sep
      • Re: A feature patch for semi-sync周振兴21 Sep
        • Re: A feature patch for semi-syncMats Kindahl21 Sep