Can't backup Slave with mysqldump -- "Duplicated key, damaged tables"

[René Fournier]

Hi,

I've spent the last few days trying to set up basic Master > Slave  
replication with auto-backup on the Slave:

Xserve G5 (10.4.11 Server)  -->  PowerMac G5 (10.5.8 Client)
-- Both running MySQL 5.1.39 64-bit PowerPC

I've followed the docs and several online articles meticulously, and  
got replication seemingly working -- with one problem: I can't get a  
valid mysqldump of the database from the Slave.

1. If I run mysqldump on the slave immediately after loading it with a  
snapshot of the Master (but before running "start slave;"), the  
mysqldump exports the database OK.

2. If I run mysqldump on the slave after having started  
synchronization (start slave;) and then stopping slave -- mysqldump  
doesn't work. It reports errors of duplicate keys and sometimes  
damaged tables.

3. If I run mysqldump on the Master, in any case, at any time,  
mysqldump successfully exports the database with no problems.

So... The slave data is okay, until replication is started, then it's  
screwed up. If I run "mysqlcheck -ao --auto-repair" on the Slave, I  
get all kinds of duplicate keys and reports of damaged tables.  
Mysqlcheck run on the Master returns no errors.

I've been reading everything I can and racking my brains, and can't  
figure out what I'm missing. To be clear: Before running mysqldump on  
the slave, I run "slave stop;". And in the beginning, to get both  
Master and Slave in sync, I've tried both LOAD DATA FROM MASTER and  
running mysqldump on the master, then loading the .sql file into the  
Slave (having noted the binary log and position, etc. of the master  
already, and doing flush tables with read lock; etc., etc.)

Any ideas? I would really love to be able to run replication (which I  
know a zillion people are all over the world, in configurations far  
more complex than mine) and do mysqldumps on the slave, thereby  
sparing a big spike on the master. I feel like the solutions is  
close... but still out of reach.

...Rene