I meant that the solution is to put master_connect_retry=2. When I met this problem, to solve it, I did : 1.stop the slave thread; 2.save the table from the master; 3.drop the table on master; 4.drop the table on slave; 5.reset the master and slave; 6.set master_connect_retry=2; 7.start the slave thread; 8. create the table on master from the saved one.
In this way the master and the slave will communicate in better way, so the changes from the master will be instantly replicated. ----- Original Message ----- From: "Victoria Reznichenko" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 15, 2003 1:04 PM Subject: Re: replication blues > "Primaria Falticeni SDU" <[EMAIL PROTECTED]> wrote: > > I met the same problem > > Problem with auto_increment column? > If so I wasn't able to repeat it with master_connect_retry=2. > > >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. > > > -- > 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]
