Perhaps slave-skip-errors can help you to get the slaves running again.
After changes to the my.cnf you have to restart mysqld.
You can use a script like this:
to permanently have an overview of the replication status. You can put
it in as a cron job, for example.
The problem left is, that you are currently having a database inconsistency.
So it would be better to have a new clean setup with a clean database.
In your setup, all the statements have to be replicated in both
directions. You can fix the problems by changing existing records in the
corresponding tables manually. But depending on the amount of errors
this can take a lot of time, I could imagine.
Mit freundlichen Grüßen / Kind regards
> "It would be interesting to know what kind of setup exactly you have?
> Can you send your config files?"
> We were running master-master replication between two servers (basically
> master-slave set up in both directions). This was running fine. However
> when replication broke (as a result of duplicate entries in the db) we
> didn't immediately notice, as each server continued to write to it's own
> master. So we ended up with the databases working independantly of each
> other and helpdesk tickets with the same number being created with different
> information. We have decided to roll back to a master-slave setup to avoid
> this happening again but obviously can't address that config change until we
> sort out the error in the db. I might give 'slave-skip-errors' a try if
> only to see if that would work but I am still confused as to how we can be
> seeing an error that happened two days after the restore date. Re: changes
> to my.cnf, I got the impression from some reading I did that this file only
> gets read the first time you get replication going and that subsequently you
> need to use commands to make any changes to this file. If this is the case,
> how can I ensure that 'slave-skip-errors' (or any other changes to my.cnf)
> is applied. Is there a way to force a read of my.cnf?
> Christian Schramm-5 wrote:
>> It would be interesting to know what kind of setup exactly you have?
>> Can you send your config files?
>> Assuming you have a master-slave-configuration with 1 master and 1
>> slave, It is very likely, that if you put in your dump on both servers,
>> you cause errors.
>> Because if you write on the master, it will automatically replicate the
>> date to the slave.
>> If you then insert the same data on the slave again, this may cause
>> duplicate entries.
>> What you can temporarily do is to set the option
>> in your /etc/mysql/my.cnf.
>> This will make the server ignore duplicate entries.
>> But be aware that this may not be a good solution for production systems.
>> Then you have to restart mysqld and the slave.
>> Mit freundlichen Grüßen / Kind regards
>> Christian Schramm
>> FMGreen schrieb:
>>> Hi there,
>>> I have inherited two Redhat replicated servers running a helpdesk app
>>> person who set them up has left the company) and replication has broken.
>>> know next to nothing about mysql/replication so am in need of help. The
>>> problem seemed to originate with a crash which caused a duplicate entry
>>> the db. Anyway, I have restored the db on each server (using the same
>>> mysqldump) so they should be identical. The restore is from Nov 14th.
>>> is confusing me is that when I do 'show slave status' it gives an error
>>> the database with a 'ticket create date' (as I said, it's a helpdesk
>>> of Nov 16th - 2 days later than my restore. It's as if replication is
>>> picking up a cached version of the original database rather than using
>>> restored version. I'm a newbie so if anyone could shed some light on
>>> is happening it would be much appreciated. Many thanks!
> http://www.nabble.com/file/p13893903/my_cnf_whd1.txt my_cnf_whd1.txt
> http://www.nabble.com/file/p13893903/my_cnf_whd2.txt my_cnf_whd2.txt