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
