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
