"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
