MySQL Forums
Forum List  »  Replication

Re: Unsafe statement advice
Posted by: Andrew Ling
Date: July 24, 2014 07:04AM

Rick James Wrote:
-------------------------------------------------------
> > it would be a lot slower in row mode than
> statement.
>
> It is slower because a lot more information flows
> through the binlog and relay log. However, with a
> high speed network, this slowdown may not be
> noticeable.
>

Presumably it's not just the network. The slave has to execute individual row statements rather than one statement that deletes all the rows.

> > I could also turn warnings off, but then I might
> miss something important.
>
> I think the warning is suggesting that a different
> set of rows might be deleted; this could lead to
> inconsistent data and other rude surprises.
>

I know it's "suggesting" that, but I can't see any way it could delete a different set of rows. The WHERE clause should be defining a complete set to delete that shouldn't be order depenent. If I'm wrong perhaps someone could say why.

I suppose it may delete the rows in a different order, but I don't think I care about that.

> Most binlog warnings are the result of someone
> finally, after many years, running into some
> obscure end case that caused data inconsistency.
>

Which is why I don't want to turn them off, but I think in this case it is being over cautious.

> I suggest going with MIXED; a thousand DELETEs in
> the binlog does not sound "a lot slower". (A
> million rows would be a different case. Sorry, I
> don't have a reformulation of the DELETE off
> hand.)

I am trying MIXED and hoping it won't be too much slower, but it would be nice to not have to. So if anyone has any idea how to change the query to avoid the warning I'd be interested.

Thanks

Options: ReplyQuote


Subject
Views
Written By
Posted
2070
July 22, 2014 07:11AM
837
July 23, 2014 08:58AM
Re: Unsafe statement advice
766
July 24, 2014 07:04AM


Sorry, you can't reply to this topic. It has been closed.

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.