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
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?