List:Replication« Previous MessageNext Message »
From:Ed W Date:April 22 2008 10:27am
Subject:Re: innodb replication (flush tables leaves stuff in ram?)
View as plain text  
Mike Steele wrote:
> I have a very simple situation.  The backup occurs once a month in the middle of the
> night.  My partner-in-crime has a daemon(ish) job that crams in a bunch of insertions and
> then sleeps for a while and then crams some more.  Endlessly.  There's no way to plan
> around this thoughtless behavior, and it seems my backup happened during one of these
> cramification operations.
>
> So, to answer your question on how I knew how many transactions I needed to skip:  I
> tried --offset=1, got a dup key error;  tried --offset=2, got a dup key error (on the next
> key ... I checked);  tried 3, 4, 5 and then 6.  6 worked.  And I checked.  6 was an
> insertion transaction.
>
> As for how I checked what the transactions were, I just piped mysqlbinlog through
> head.
>  

Hmm, well this just smells like a reproducable bug?  What you seem to be 
saying is that you are not getting transaction level isolation, (or that 
there is a bug in mysql's locking which is meaning that it's locking the 
transaction log at a different point to the data tables?)

Sounds like an independent transaction is commiting rows to a table, 
these rows are showing up in the dump of the table data, but NOT showing 
up in the commited transaction in the log file?

Hmm

Ed W
Thread
Re: innodb replication (flush tables leaves stuff in ram?)Mike Steele19 Apr
  • Re: innodb replication (flush tables leaves stuff in ram?)Eric Bergen21 Apr
Re: innodb replication (flush tables leaves stuff in ram?)Mike Steele21 Apr
  • Re: innodb replication (flush tables leaves stuff in ram?)Eric Bergen22 Apr
Re: innodb replication (flush tables leaves stuff in ram?)Mike Steele22 Apr
  • Re: innodb replication (flush tables leaves stuff in ram?)Ed W22 Apr