"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!
View this message in context:
Sent from the MySQL - Replication mailing list archive at Nabble.com.