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