"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]
