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" <victoria.reznichenko@stripped>
To: <mysql@stripped>
Sent: Friday, August 15, 2003 1:04 PM
Subject: Re: replication blues
> "Primaria Falticeni SDU" <prifalsdu@stripped> 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" <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.
>
>
> --
> 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
