On Wednesday 14 February 2001 12:58, Matt Hahnfeld wrote:
>Wow, that was fast! Thanks!!!!!!
We mean what we say - the better the bug report, the quicker the fix :-)
>
>--Matt
>
>On Wed, 14 Feb 2001, Sasha Pachev wrote:
>
>> On Wednesday 14 February 2001 09:19, Matt Hahnfeld wrote:
>> >After downgrading to 3.23.30, replication worked fine without the problem
>> >posted below. This appears to be a bug in the newest version (3.23.33)
>> >only.
>> >
>> >The failed tests were run under mysql-3.23.33-pc-linux-gnu-i686 (binary
>> >distribution).
>> >
>> >The same tests succeeded under mysql-3.23.30-gamma-pc-linux-gnu-i686
>> >(binary distribution) with no problems.
>> >
>> >---------- Forwarded message ----------
>> >Date: Tue, 13 Feb 2001 14:33:47 -0500 (EST)
>> >From: Matt Hahnfeld <[EMAIL PROTECTED]>
>> >To: [EMAIL PROTECTED]
>> >Subject: Strange Replication Problem in 3.23.33 (bug?)
>> >
>> >I set up two MySQL servers to run in a failover configuration. Because
>> >queries will only ever be submitted to one server at a time, I decided to
>> >use a makeshift two-way replication scheme under MySQL as descibed in
>> >the MySQL manual.
>> >
>> >First server (wallace) has this:
>> >--------------------------------
>> >server-id=1
>> >log-bin
>> >master-host=gromit
>> >master-user=repl
>> >master-password=<password>
>> >log-slave-updates
>> >--------------------------------
>> >
>> >Second server (gromit) has this:
>> >--------------------------------
>> >server-id=2
>> >log-bin
>> >master-host=wallace
>> >master-user=repl
>> >master-password=<password>
>> >log-slave-updates
>> >--------------------------------
>> >
>> >I started by mirroring both data directories. Then I started both servers
>> >and all looked fine. Logs indicate no errors. When I inserted some
>> >data on wallace, gromit replicated them just fine. But when I tried to
>> >insert data on gromit, wallace never got the changes. The weird thing is,
>> >no real errors appeared in the logs.
>> >
>> >Then I did a "SHOW SLAVE STATUS" on wallace and saw "Skip_counter" was
>> >set to 4294967295!!! Strange, I thought, so I ran "STOP SLAVE", "SET
>> >SQL_SLAVE_SKIP_COUNTER=0", and "START SLAVE" on wallace. Suddenly
>> >changes made on gromit were reflected on wallace.
>> >
>> >But then I tried to insert data on wallace again and the same thing
>> >happened. This time gromit never got the changes. When I ran "SHOW SLAVE
>> >STATUS" on gromit, it indicated 4294967293. To get it to work, I had to
>> >run "SET SQL_SLAVE_SKIP_COUNTER=0" on gromit.
>> >
>> >I just don't get it... Why are the skip counters being reset to thse
>> >crazy high numbers?
>>
>> Thanks for the bug report. The problem is a bug in the code that skips
events
>> when it sees a log entry with the same server id - something that can only
>> happen in the bi-directional replicaiton setup. Fix:
>>
>> --- 1.85/sql/slave.cc Sat Jan 27 15:33:30 2001
>> +++ edited/slave.cc Wed Feb 14 12:35:34 2001
>> @@ -849,7 +849,8 @@
>>
>> mi->inc_pos(event_len);
>> flush_master_info(mi);
>> - --slave_skip_counter;
>> + if(slave_skip_counter)
>> + --slave_skip_counter;
>> delete ev;
>> return 0; // avoid infinite
>> update loops
>> }
>>
>>
>>
>> --
>> MySQL Development Team
>> __ ___ ___ ____ __
>> / |/ /_ __/ __/ __ \/ / Sasha Pachev <[EMAIL PROTECTED]>
>> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
>> /_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA
>> <___/
>>
>>
--
MySQL Development Team
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sasha Pachev <[EMAIL PROTECTED]>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
/_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA
<___/
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
