I met the same problem and I noticed that you need, on the slave, set connect_retry to 2 (connect_retry is the time after which the slave retries to connect to master). It's a replication problem met by me on MySQL 4.0.14 on Linux Red Hat 9.
I manually managed the replication conflicts until then. I mean conflicts from the late of the update slave <- master. Iulian ----- Original Message ----- From: "Victoria Reznichenko" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 12, 2003 9:49 PM Subject: Re: replication blues > Bogdan TARU <[EMAIL PROTECTED]> wrote: > > And data is inserted into it with simple inserts, w/o specifing the id > > (it's autoincrementing). > > > > With a little debugging, I have located the problem. If I run 'alter > > table xxx auto_increment=1' on both the master and the slave (this table > > is empty at the time on both machines), and then I insert datas into the > > master, they look like: > > > > On master: > > > > +----+--------+------+------------+--------+----------+---------------+----- ---+ > > | 1 | 3 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 2 | 4 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 3 | 5 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 4 | 6 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 5 | 13 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 6 | 14 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 7 | 18 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 8 | 19 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 9 | 20 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 10 | 21 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > +----+--------+------+------------+--------+----------+------+--------+ > > > > But on slave it looks like: > > > > +----+--------+------+------------+--------+----------+------+--------+ > > | id | dialer | uid | action | acc_no | template | name | status | > > +----+--------+------+------------+--------+----------+------+--------+ > > | 10 | 3 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 11 | 4 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 12 | 5 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 13 | 6 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 14 | 13 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 15 | 14 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 16 | 18 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 17 | 19 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 18 | 20 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > | 19 | 21 | 1007 | REGENERATE | NULL | NULL | NULL | OKAY | > > +----+--------+------+------------+--------+----------+------+--------+ > > > > > > Why does it start on the id=10 on the slave? Of course, this is the > > cause for the replication failures later on, because datas are deleted on > > the master with 'delete from xxx where id=3', for example, action which > > doesn't delete anything on the slave (because there is no id=3 entry), > > thus inconsistency. > > > > I'm using 4.0.13 on both machines. > > I wasn't able to repeat it on 4.0.14. Could you provide a test case? What replication options do you use? > > > -- > For technical support contracts, goto https://order.mysql.com/?ref=ensita > This email is sponsored by Ensita.net http://www.ensita.net/ > __ ___ ___ ____ __ > / |/ /_ __/ __/ __ \/ / Victoria Reznichenko > / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] > /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.net > <___/ www.mysql.com > > > > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
