List:Replication« Previous MessageNext Message »
From:Moon's Father Date:May 21 2008 8:50am
Subject:Re: innodb replication
View as plain text  
So exciting!

On Thu, Apr 24, 2008 at 11:25 AM, Eric Bergen <ebergen@stripped>
wrote:

> You won't lose a transaction because binlog positions are updated on
> commit and commit is blocked by the flush tables with read lock.
>
>
> On Wed, Apr 23, 2008 at 1:41 PM, Marcus Bointon
> <marcus@stripped> wrote:
> > On 23 Apr 2008, at 21:19, Rick James wrote:
> >
> >
> > > So, effectively the snapshot was at state #1.
> > >
> >
> >
> >  Yes. I would expect it to restart the transaction from the last
> committed
> > log position, which will be #1, not some unknown state. When it rolls
> back,
> > it rolls back the log position too - the uncommitted/failed transaction
> > effectively never happened at all. Because we're talking about a slave,
> it
> > can get what happened next from the master's logs. If it was a master
> that
> > we'd restored, I guess it's a different matter. OTOH, losing 1
> transaction
> > is much less bad than not having a workable backup :^)
> >
> >  At least that's my understanding of it.
> >
> >
> >  Marcus
> >  --
> >  Marcus Bointon
> >  Synchromedia Limited: Creators of http://www.smartmessages.net/
> >  UK resellers of info@hand CRM solutions
> >  marcus@stripped | http://www.synchromedia.co.uk/
> >
> >
> >
> >  --
> >  MySQL Replication Mailing List
> >  For list archives: http://lists.mysql.com/replication
> >  To unsubscribe:
> > http://lists.mysql.com/replication?unsub=1
> >
> >
>
>
>
> --
> Eric Bergen
> eric.bergen@stripped
> http://www.provenscaling.com
>
> --
> MySQL Replication Mailing List
> For list archives: http://lists.mysql.com/replication
> To unsubscribe:
> http://lists.mysql.com/replication?unsub=1
>
>


-- 
I'm a mysql DBA in china.
More about me just visit here:
http://yueliangdao0608.cublog.cn

Thread
innodb replicationEdson Noboru Yamada23 Mar
  • Re: innodb replicationMarcus Bointon24 Mar
  • Re: innodb replicationEd W18 Apr
    • Re: innodb replicationMarcus Bointon18 Apr
      • Re: innodb replicationEd W18 Apr
        • Re: innodb replicationMarcus Bointon18 Apr
      • RE: innodb replicationRick James19 Apr
        • Re: innodb replicationEric Bergen20 Apr
          • Re: innodb replicationAugusto Bott22 Apr
            • Re: innodb replicationMark Callaghan22 Apr
              • Re: innodb replicationAugusto Bott22 Apr
                • Re: innodb replicationEric Bergen22 Apr
              • Re: innodb replicationAugusto Bott23 Apr
                • Re: innodb replicationEric Bergen23 Apr
                  • RE: innodb replicationRick James23 Apr
                    • Re: innodb replicationMarcus Bointon23 Apr
                    • Re: innodb replicationJeremy Cole23 Apr
                      • RE: innodb replicationRick James23 Apr
                        • Re: innodb replicationJeremy Cole23 Apr
                          • RE: innodb replicationRick James23 Apr
                            • Re: innodb replicationMarcus Bointon23 Apr
                              • Re: innodb replicationEric Bergen24 Apr
                                • Re: innodb replicationMoon's Father21 May