List:Replication« Previous MessageNext Message »
From:周振兴 Date:September 26 2011 7:37am
Subject:Re: More trouble about semi-sync
View as plain text  
2011/9/23 MARK CALLAGHAN <mdcallag@stripped>

> cond_broadcast should wake all waiters. With your change does dump
>

Yep i have check the code again. I found my worry is unnecessary.

Here is detail:  mysql_cond_broadcast  can wake all waiters, but all the
waiters only run ***serially***.
However, every waiter only hold the lock for a short time (about a few cpu
cycle), so all the waiters seem almost the same time to start to read the
binlog.

thread that sends binlog events to a slave hold LOCK_log while waiting
> for an ACK?
>
> 2011/9/23 周振兴 <orczhou@stripped>:
> > Hi all
> > First time I read the feature about semi-sync, i found this in the
> > Introduction
> > "it blocks return from commit until either ***at least one semi-sync
> > slave*** acknowledges receipt of all replication events for the
> transaction
> > or until a configurable timeout expires"
> > So i though if multi semi-sync slaves can help the master get ack more
> > quickly. But when i have try, I found that once two or more
> > slaves config-ed, for every Binlog Event, only one slave can get at the
> > first time( first time means just after binlog flushed ).
> > I check the code(MySQL5.5.16  &&  5.1.48), after master flushed the
> binlog,
> > a cond_broadcast was sent. Since this is a condition variables, ***only
> one
> > thread*** of "mysql_binlog_send" can got the signal, so only one slave
> can
> > response the ACK at the first time.
> > It's something like this :
> > what "mysql_binlog_send" thread do on the master: ( one slave got one
> > "mysql_binlog_send" thread on master )
> > 1. got slave connected && request
> > 2. send the binlog they need
> > 3. wait for new binlog flushed:  mysql_cond_wait(&update_cond,
> &LOCK_log);
> > ...... wait ......
> > ...... wait ......
> > ...... wait ......
> > 4. ok, gotcha, let's send the new log
> > when another thread flushed the new binlog
> > 1. write && flush the new binlog
> > 2. send a signal:  mysql_cond_broadcast(&update_cond);
> > ...
> > So here are two slave connected to master, and one of the slave's network
> is
> > good but another one's network is very bad. If the bad
> > guy's "mysql_binlog_send" thread always get the lucky: always get signal
> (
> > and get the mutex of it ). The master must wait for the bad slave's ACK.
> > My Trouble :
> > (1) Never config a bad slave on the master. Is this right? or it's just
> ok
> > if there is a good one.
> > (2) Is necessary to change the condition variable?  Try to make an
> implement
> > that all the "mysql_binlog_send" thread realize the new binlog flushed.
> Is
> > this necessary?
> >
> > --
> > 此致
> >     敬礼
> > -----------------------------------------------------
> > 周振兴  159-9004-0105 Taobao.com
> > http://orczhou.com
> >
>
>
>
> --
> Mark Callaghan
> mdcallag@stripped
>



-- 
此致
    敬礼
-----------------------------------------------------
周振兴  159-9004-0105 Taobao.com
http://orczhou.com

Thread
More trouble about semi-sync周振兴23 Sep
  • Re: More trouble about semi-syncMARK CALLAGHAN23 Sep
    • Re: More trouble about semi-sync周振兴23 Sep
    • Re: More trouble about semi-sync周振兴26 Sep