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" <victoria.reznichenko@stripped>
To: <mysql@stripped>
Sent: Tuesday, August 12, 2003 9:49 PM
Subject: Re: replication blues
> Bogdan TARU <bgd@stripped> 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
> / /|_/ / // /\ \/ /_/ / /__ Victoria.Reznichenko@stripped
> /_/ /_/\_, /___/\___\_\___/ 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/mysql?unsub=1
