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@strippedhttp://www.provenscaling.com

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.