MySQL Forums
Forum List  »  Replication

row-based replication (RBR) don't work
Posted by: Eric Jensen
Date: June 28, 2008 12:35PM

I'm attempting to switch to row-based replication but cannot get it
(either default MIXED mode or forced ROW) to work. I'm having two
show-stopper problems when RBR is active that I don't have at all in statement-based replication with exactly the same setup:

1. Replication is heinously slow because it seems to be CPU bound.
It's constantly in the "invalidating query cache entries (table)"
thread state even though I have query_cache_type = 0 (i.e., OFF). I
see mysql cranking away with 99% CPU usage, whereas when I use
statement-based replication it is decidely IO bound, with barely any
CPU usage that isn't IO wait. I had hoped for the opposite, and this
seems like buggy behavior...

2. I can't stop and start the replication at all without breaking the
replication. If I do "stop slave" and then "start slave" again it
immediately has an error like this, seemingly for random tables that
have been written to (not one in particular):

Could not execute Write_rows event on table
XXX; Duplicate entry
'YYY' for key 'ZZZ',
Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's
master log binlog.000003, end_log_pos 704849

I have scoured the bug reports and found nothing to explain either of
these. Does anyone have any ideas? I'm running the Linux (AMD64 /
Intel EM64T) build of 5.1.25 on a xeon box...nothing that unusual
about my environment or database. Only thing I could think of is that
my app does some large insert delayed ... values ... statements. If
nobody has ideas I suppose I will file bug reports, but these are such
general failures I don't know what to say in them other than "it don't


Options: ReplyQuote

Written By
row-based replication (RBR) don't work
June 28, 2008 12:35PM

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.