On Sun, Dec 06, 2009 at 08:27:28AM -0800, MARK CALLAGHAN wrote:
> On Sun, Dec 6, 2009 at 7:15 AM, Simon J Mudd <sjmudd@stripped> wrote:
> > song.voong@stripped (Song Voong) writes:
> >> I been getting this error and my replication stoppped.
> >> ERROR 1062: Duplicate entry
> >> Last_Error: Error 'Duplicate entry '1010769-50-65% Cttn, 35% Rayon'
> for key
> >> 2' on query. Default database: 'm3'. Query: 'Update item_attribute SET
> >> lupdateby='TINAA',item_id='1010769',value='65% Cttn, 35%
> >> Rayon',source=3,attribute_definition_id='50' WHERE item_attribute_ID =
> >> 118838555'
> >> I know I can do a slave-skip-errors 1062 and by pass it, I been
> reading the
> >> forum and it is a common issues with replication, But what is causing this?
> >> I mean it is updating stuff on the master, and slave should get updated too
> >> . NO?
> Simon listed many good things to check. There are two other things to check:
> 1) confirm the slave did not crash/restart (either mysqld restart or
> server reboot). Slave replication state is not crashproof and on a
> crash transactions can get replayed. This is easy to check.
Note: I think even with the 5.0 version being used if you don't configure the
binlogs to be synced with the commits you can find them up to 30 seconds
behind, as mysql won't force them to disk. If the host crashes these changes
will be lost and on restart mysql will try to replay these statements.
Depending on what they are this can make the content of the different
from what it should be. So watch this. Default MySQL behaviour is NOT safe.