List:Replication« Previous MessageNext Message »
From:Mats Kindahl Date:September 21 2011 5:35pm
Subject:Re: A feature patch for semi-sync
View as plain text  
On 09/21/2011 04:10 PM, 周振兴 wrote:
> 2011/9/20 Mats Kindahl <mats.kindahl@stripped>
>
>> On 09/20/2011 05:20 AM, 周振兴 wrote:
>>> Hi  MySQL/Oracle Replication Team
>>>
>>> The semi-sync “phantom read” problem is critical in our
> application
>>> architecture. So we have run this patch in our product base on 5.5.15.  I
>>> thinks the patch is also important to other semi-sync users.
>>>
>>> Have any one check the patch i submit before.
>>>
>>> I wanna know how to propose for merging? Are there a "gatekeeper" for
>>> mysql-server? How it works ?
>> Hi!
>>
>> We don't currently have a "gatekeeper" (even though I think we should
>> have one).
>>
>> I looked briefly at the code and it seems like an interesting patch. I
>> will send the patch to some reviewer internally.
>>
> Thanks a lot, mats.
>
> Actually i think this may be critical to some semi-sync user.

Agree on that.

We get a lot of questions and comments on the current behavior for
semi-sync on presentations and conferences. The current implementation
is to avoid blocking the master longer than necessary, which is
partially because of the prepare_commit_mutex that Mark mentioned.

Best wishes,
Mats Kindahl

>> Best wishes,
>> Mats Kindahl
>>
>>> Thanks.
>>>
>>> 2011/9/14 周振兴 <orczhou@stripped>
>>>
>>>> Hi all
>>>>
>>>> The patch for semi-sync has been commit to Launchpad.net:
>>>> lp:~orczhou/mysql-server/ESR<
>> https://code.launchpad.net/~orczhou/mysql-server/ESR>
>>>> .
>>>>
>>>> A feature request on bug system has been report :
>>>> http://bugs.mysql.com/62174
>>>>
>>>> Semi-sync is cool. But in the semi-sync solution, there are
> “phantom
>>>> read”: When InnoDB commit a transaction and no slave have accept
> the
>>>> binary log, at the time another “new thread” still can read
> the
>>>> data generated by this transaction. If database crash and gone(can't
>>>> startup anymore) at this right time, although we have ever read these
>>>> data, it's not exist in any slave and we think this transaction is
>>>> never happened.
>>>>
>>>> In our application architecture, if our ”new thread“ read
>>>> “phantom data”, we will try to do some work about user's
> critical
>>>> information. So we must not read the “phantom data”.
>>>>
>>>> So,we add a new variables for semi-sync
>>>> "rpl_semi_sync_master_wait_before_commit".Once you set this variables
>>>>  ***WILL NOT COMMIT***  ON, MySQL(InnoDB)  the transaction until at
>> least
>>>> one
>>>> slave get the binary log. By default, it is OFF and semi-sync act as the
>>>> original way.
>>>>
>>>> Set this variable ON, make semi-sync act like this :
>>>>   "Once you ***can read*** the data from the master, at least one slave
>> has
>>>> got the binary log"
>>>> as the original semi-sync act like this :
>>>>   "Once you ***get reponse*** from the master, at least on slave has got
>>>> the binary log".
>>>>
>>>> The patch for semi-sync has been commit to Launchpad.net:
>>>> lp:~orczhou/mysql-server/ESR<
>> https://code.launchpad.net/~orczhou/mysql-server/ESR>
>>>> .
>>>>
>>>> A feature request on bug system has been report :
>>>> http://bugs.mysql.com/62174
>>>>
>>>> Anders.song has been reviewed the code.
>>>>
>>>> *Some question:*
>>>>
>>>> How do i make the branch from "Development" to "Experimental" or
>> "Mature" ?
>>>> When should i Propose for merging?
>>>>
>>>> Are there a "gatekeeper" for mysql-server? How it works ?
>>>>
>>>> *Test case*
>>>>
>>>> I have run all test-case of suite=rpl with
>>>> --mysqld=--loose-rpl_semi_sync_master_wait_before_commit=1.
>>>> All test-cases act like exactly as the original way, except the
>>>> rpl_semi_sync.test. What make rpl_semi_sync.test
>>>> different is :
>>>>     In the patch,any DDL statement(trans_commit_implicit) is an
>> exception,
>>>> which will NOT wait the reply of slave.
>>>>     The reason is : the patch add a new HOOK in binlog_commit. When
>>>> binlog_commit return, we wait the slave reply.
>>>> So every before transaction commit, it will wait the slave reply.But,
>> the
>>>> DDL statement will NEVER invoke binlog_commit.
>>>> And we think it's OK that only DDL is the special case.
>>>>
>>>> A new test-case is writing to verify this patch is always act as the
>> expect
>>>> way.
>>>>
>>>> You can get all the details from the code
> :lp:~orczhou/mysql-server/ESR<
>> https://code.launchpad.net/~orczhou/mysql-server/ESR>
>>>> .
>>>>
>>>>
>>>>
>>>> --
>>>> 此致
>>>>     敬礼
>>>> -----------------------------------------------------
>>>> 周振兴  159-9004-0105 Taobao.com
>>>> http://orczhou.com
>>>>
>>>
>>
>

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