List:Replication« Previous MessageNext Message »
From:周振兴 Date:September 21 2011 2:10pm
Subject:Re: A feature patch for semi-sync
View as plain text  
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.


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


-- 
此致
    敬礼
-----------------------------------------------------
周振兴  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