Below is the list of changes that have just been commited into a local
3.23. repository of sasha. When sasha does a push, they will be
propogaged to the main repository and within 24 hours after the push into
the public repository. For information on how to access
the public repository see
http://www.mysql.com/doc/I/n/Installing_source_tree.html
ChangeSet@stripped, 2001-07-18 14:26:43-06:00, sasha@stripped
fixed mysterious offset confusion bug
added a test case for it - took some creative work to figure out
how to make it happen at will
updated the manual
mysql-test/r/rpl_mystery22.result
1.1 01/07/18 14:26:43 sasha@stripped +4 -0
mysql-test/t/rpl_mystery22.test
1.1 01/07/18 14:26:43 sasha@stripped +43 -0
mysql-test/r/rpl_mystery22.result
1.0 01/07/18 14:26:43 sasha@stripped +0 -0
BitKeeper file /home/sasha/src/bk/mysql/mysql-test/r/rpl_mystery22.result
mysql-test/t/rpl_mystery22.test
1.0 01/07/18 14:26:43 sasha@stripped +0 -0
BitKeeper file /home/sasha/src/bk/mysql/mysql-test/t/rpl_mystery22.test
mysql-test/t/rpl_sporadic_master.test
1.3 01/07/18 14:26:43 sasha@stripped +9 -2
tried hard to get slave confused, but failed. nevertheless, a more
exhaustive test case does not hurt
sql/slave.cc
1.110 01/07/18 14:26:43 sasha@stripped +2 -0
fixed mysterious offset confusion bug
Docs/manual.texi
1.637 01/07/18 14:26:42 sasha@stripped +10 -4
fixed wrong info on SLAVE_SKIP_COUNTER
fixed wrong info in BitKeeper tree build instructions
updated change history about bug fix
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: sasha
# Host: mysql.sashanet.com
# Root: /home/sasha/src/bk/mysql
--- 1.636/Docs/manual.texi Wed Jul 18 02:31:17 2001
+++ 1.637/Docs/manual.texi Wed Jul 18 14:26:42 2001
@@ -6543,8 +6543,8 @@
A collection of our standard configure scripts is located in the
@file{BUILD/} subdirectory. If you are lazy, you can use
-@file{BUILD/compile-pentium-debug}. It will actually work on a lot of
-non-x86 machines despite its name.
+@file{BUILD/compile-pentium-debug}. To compile on a different architecture,
+modify the script removing flags that are Pentium-specific.
@item
When the build is done, run @code{make install}. Be careful with this
@@ -29828,8 +29828,11 @@
@item
If you have decided you can skip the next query, do
@code{SET SQL_SLAVE_SKIP_COUNTER=1; SLAVE START;} to skip a query that
-does not use auto_increment, last_insert_id or timestamp, or
-@code{SET SQL_SLAVE_SKIP_COUNTER=2; SLAVE START;} otherwise
+does not use auto_increment, or last_insert_id or
+@code{SET SQL_SLAVE_SKIP_COUNTER=2; SLAVE START;} otherwise. The reason
+auto_increment/last_insert_id queries are different is that they take
+two events in the binary log of the master.
+
@item
If you are sure the slave started out perfectly in sync with the master,
and no one has updated the tables involved outside of slave thread,
@@ -45727,6 +45730,9 @@
@node News-3.23.40, News-3.23.39, News-3.23.x, News-3.23.x
@appendixsubsec Changes in release 3.23.40
@itemize @bullet
+@item
+Fixed bug in slave thread when under some rare circumstances it could
+get 22 bytes ahead on the offset in the master
@item
Added @code{slave_wait_timeout} for replication.
@item
--- 1.109/sql/slave.cc Tue Jul 17 14:22:39 2001
+++ 1.110/sql/slave.cc Wed Jul 18 14:26:43 2001
@@ -1222,6 +1222,8 @@
thd->thread_stack = (char*)&thd; // remember where our stack is
thd->temporary_tables = save_temporary_tables; // restore temp tables
threads.append(thd);
+ glob_mi.pending = 0; //this should always be set to 0 when the slave thread
+ // is started
DBUG_PRINT("info",("master info: log_file_name=%s, position=%s",
glob_mi.log_file_name, llstr(glob_mi.pos,llbuff)));
--- New file ---
+++ mysql-test/r/rpl_mystery22.result 01/07/18 14:26:43
n
1
2
3
--- New file ---
+++ mysql-test/t/rpl_mystery22.test 01/07/18 14:26:43
# test case to make slave thread get ahead by 22 bytes
source include/master-slave.inc;
connection master;
# first, cause a duplicate key problem on the slave
create table t1(n int auto_increment primary key);
save_master_pos;
connection slave;
sync_with_master;
insert into t1 values (2);
connection master;
insert into t1 values(NULL);
insert into t1 values(NULL);
save_master_pos;
connection slave;
sleep 1; # there is no way around this sleep - we have to wait until
# the slave tries to run the query, fails and aborts slave thread
delete from t1 where n = 2;
slave start;
sync_with_master;
#now the buggy slave would be confused on the offset but it can replicate
#in order to make it break, we need to stop/start the slave one more time
slave stop;
connection master;
# to be able to really confuse the slave, we need some non-auto-increment
# events in the log
create table t2(n int);
drop table t2;
insert into t1 values(NULL);
save_master_pos;
connection slave;
slave start;
#now the truth comes out - if the slave is buggy, it will never sync because
#the slave thread is not able to read events
sync_with_master;
select * from t1;
#clean up
connection master;
drop table t1;
save_master_pos;
connection slave;
sync_with_master;
--- 1.2/mysql-test/t/rpl_sporadic_master.test Mon Jul 16 04:27:27 2001
+++ 1.3/mysql-test/t/rpl_sporadic_master.test Wed Jul 18 14:26:43 2001
@@ -3,12 +3,19 @@
source include/master-slave.inc;
connection master;
-drop table if exists t1;
+drop table if exists t1,t2;
+create table t2(n int);
create table t1(n int not null auto_increment primary key);
insert into t1 values (NULL),(NULL);
delete from t1;
# We have to use 4 in the following to make this test work with all table types
insert into t1 values (4),(NULL);
+save_master_pos;
+connection slave;
+sync_with_master;
+slave stop;
+slave start;
+connection master;
insert into t1 values (NULL),(NULL);
flush logs;
delete from t1;
@@ -20,7 +27,7 @@
sync_with_master;
select * from t1;
connection master;
-drop table t1;
+drop table t1,t2;
save_master_pos;
connection slave;
sync_with_master;
| Thread |
|---|
| • bk commit into 3.23 tree | sasha | 18 Jul |
