Fix for BUG#13023: "SQL Thread is up but doesn't move forward". Details in slave.cc;
in short we now record whenever the slave I/O thread ignores a master's event because of its server id,
and use this info in the slave SQL thread to advance Exec_master_log_pos. Because if we
do not, this variable stays at the position of the last executed event, i.e. the last *non-ignored*
executed one, which may not be the last of the master's binlog (and so the slave *looks* behind
the master though it's data-wise it's not).
mysql-test/t/rpl_dual_pos_advance-master.opt:
empty; its goal is just to trigger a server restart after running the test,
so that the master forgets that it was a slave (otherwise it affects the following tests).
sql/log.cc:
No more default arguments for Rotate_log_event constructor.
MYSQL_LOG::appendv() is now called without mutex.
sql/log_event.cc:
Moving one Rotate_log_event constructor from log_event.h. Support for on-demand choice of
duplicating the string argument of the constructor or not (because there now are needs for both
alternatives, see slave.cc).
sql/log_event.h:
We now have a case where a Rotate_log_event is executed by the slave SQL thread while
not being in the relay log, so it needs to pretend its length is 0: a ZERO_LEN flag for that;
a flag DUP_NAME (replaces "bool alloced") to be able to choose if we want the constructor
to duplicate the string argument or not.
sql/slave.cc:
A comment for BUG#13861 (to be fixed). llstr() instead of %ld as the number is ulonglong.
mi->rli becomes rli in some places.
Fix for BUG#13023:
- in the slave I/O thread, whenever we ignore an event because of its server id we update
a couple of coordinates in memory
- in the slave SQL thread, whenever we bump into the end of the latest relay log, we check
this couple of coordinates to see if we should advance our Exec_master_log_pos.
- when the slave I/O thread terminates it saves these in-memory coordinates into a Rotate event
in the relay log, so that they are durable.
sql/slave.h:
A couple of coordinates in RELAY_LOG_INFO to keep track of the last ignored events received
by the slave I/O thread (ignored because of the server id).
mysql-test/r/rpl_dual_pos_advance.result:
New BitKeeper file ``mysql-test/r/rpl_dual_pos_advance.result''
mysql-test/t/rpl_dual_pos_advance.test:
Test for BUG#13023 (with a part, disabled, to test BUG#13861 when I fix it).
Before the fix, this test used to hang.
2005-10-12 13:29:55 +02:00
|
|
|
# This test checks that in a dual-head setup
|
|
|
|
|
# A->B->A, where A has --log-slave-updates (why would it?
|
|
|
|
|
# assume that there is a C as slave of A),
|
|
|
|
|
# then the Exec_master_log_pos of SHOW SLAVE STATUS does
|
|
|
|
|
# not stay too low on B(BUG#13023 due to events ignored because
|
|
|
|
|
# of their server id).
|
|
|
|
|
# It also will test BUG#13861.
|
|
|
|
|
|
|
|
|
|
source include/master-slave.inc;
|
BUG#13861 - START SLAVE UNTIL may stop 1 evnt too late if
log-slave-updates and circul repl
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
mysql-test/r/rpl_dual_pos_advance.result:
A test case for BUG#13861.
mysql-test/t/rpl_dual_pos_advance.test:
A test case for BUG#13861.
sql/log_event.cc:
Store length of event. This is needed for further calculation of
the beginning of event.
sql/slave.cc:
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
sql/slave.h:
Added master_log_pos parametr to is_until_satisfied().
mysql-test/t/rpl_dual_pos_advance-slave.opt:
New BitKeeper file ``mysql-test/t/rpl_dual_pos_advance-slave.opt''
2008-02-22 19:07:07 +04:00
|
|
|
source include/have_innodb.inc;
|
Fix for BUG#13023: "SQL Thread is up but doesn't move forward". Details in slave.cc;
in short we now record whenever the slave I/O thread ignores a master's event because of its server id,
and use this info in the slave SQL thread to advance Exec_master_log_pos. Because if we
do not, this variable stays at the position of the last executed event, i.e. the last *non-ignored*
executed one, which may not be the last of the master's binlog (and so the slave *looks* behind
the master though it's data-wise it's not).
mysql-test/t/rpl_dual_pos_advance-master.opt:
empty; its goal is just to trigger a server restart after running the test,
so that the master forgets that it was a slave (otherwise it affects the following tests).
sql/log.cc:
No more default arguments for Rotate_log_event constructor.
MYSQL_LOG::appendv() is now called without mutex.
sql/log_event.cc:
Moving one Rotate_log_event constructor from log_event.h. Support for on-demand choice of
duplicating the string argument of the constructor or not (because there now are needs for both
alternatives, see slave.cc).
sql/log_event.h:
We now have a case where a Rotate_log_event is executed by the slave SQL thread while
not being in the relay log, so it needs to pretend its length is 0: a ZERO_LEN flag for that;
a flag DUP_NAME (replaces "bool alloced") to be able to choose if we want the constructor
to duplicate the string argument or not.
sql/slave.cc:
A comment for BUG#13861 (to be fixed). llstr() instead of %ld as the number is ulonglong.
mi->rli becomes rli in some places.
Fix for BUG#13023:
- in the slave I/O thread, whenever we ignore an event because of its server id we update
a couple of coordinates in memory
- in the slave SQL thread, whenever we bump into the end of the latest relay log, we check
this couple of coordinates to see if we should advance our Exec_master_log_pos.
- when the slave I/O thread terminates it saves these in-memory coordinates into a Rotate event
in the relay log, so that they are durable.
sql/slave.h:
A couple of coordinates in RELAY_LOG_INFO to keep track of the last ignored events received
by the slave I/O thread (ignored because of the server id).
mysql-test/r/rpl_dual_pos_advance.result:
New BitKeeper file ``mysql-test/r/rpl_dual_pos_advance.result''
mysql-test/t/rpl_dual_pos_advance.test:
Test for BUG#13023 (with a part, disabled, to test BUG#13861 when I fix it).
Before the fix, this test used to hang.
2005-10-12 13:29:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
# set up "dual head"
|
|
|
|
|
|
|
|
|
|
connection slave;
|
|
|
|
|
reset master;
|
|
|
|
|
|
|
|
|
|
connection master;
|
|
|
|
|
--replace_result $SLAVE_MYPORT SLAVE_PORT
|
|
|
|
|
eval change master to master_host="127.0.0.1",master_port=$SLAVE_MYPORT,master_user="root";
|
|
|
|
|
|
|
|
|
|
start slave;
|
|
|
|
|
|
|
|
|
|
# now we test it
|
|
|
|
|
|
|
|
|
|
connection slave;
|
|
|
|
|
|
|
|
|
|
create table t1 (n int);
|
|
|
|
|
|
|
|
|
|
save_master_pos;
|
|
|
|
|
connection master;
|
|
|
|
|
sync_with_master;
|
|
|
|
|
|
BUG#13861 - START SLAVE UNTIL may stop 1 evnt too late if
log-slave-updates and circul repl
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
mysql-test/r/rpl_dual_pos_advance.result:
A test case for BUG#13861.
mysql-test/t/rpl_dual_pos_advance.test:
A test case for BUG#13861.
sql/log_event.cc:
Store length of event. This is needed for further calculation of
the beginning of event.
sql/slave.cc:
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
sql/slave.h:
Added master_log_pos parametr to is_until_satisfied().
mysql-test/t/rpl_dual_pos_advance-slave.opt:
New BitKeeper file ``mysql-test/t/rpl_dual_pos_advance-slave.opt''
2008-02-22 19:07:07 +04:00
|
|
|
#
|
|
|
|
|
# BUG#13861 - START SLAVE UNTIL may stop 1 evnt too late if
|
|
|
|
|
# log-slave-updates and circul repl
|
|
|
|
|
#
|
|
|
|
|
stop slave;
|
Fix for BUG#13023: "SQL Thread is up but doesn't move forward". Details in slave.cc;
in short we now record whenever the slave I/O thread ignores a master's event because of its server id,
and use this info in the slave SQL thread to advance Exec_master_log_pos. Because if we
do not, this variable stays at the position of the last executed event, i.e. the last *non-ignored*
executed one, which may not be the last of the master's binlog (and so the slave *looks* behind
the master though it's data-wise it's not).
mysql-test/t/rpl_dual_pos_advance-master.opt:
empty; its goal is just to trigger a server restart after running the test,
so that the master forgets that it was a slave (otherwise it affects the following tests).
sql/log.cc:
No more default arguments for Rotate_log_event constructor.
MYSQL_LOG::appendv() is now called without mutex.
sql/log_event.cc:
Moving one Rotate_log_event constructor from log_event.h. Support for on-demand choice of
duplicating the string argument of the constructor or not (because there now are needs for both
alternatives, see slave.cc).
sql/log_event.h:
We now have a case where a Rotate_log_event is executed by the slave SQL thread while
not being in the relay log, so it needs to pretend its length is 0: a ZERO_LEN flag for that;
a flag DUP_NAME (replaces "bool alloced") to be able to choose if we want the constructor
to duplicate the string argument or not.
sql/slave.cc:
A comment for BUG#13861 (to be fixed). llstr() instead of %ld as the number is ulonglong.
mi->rli becomes rli in some places.
Fix for BUG#13023:
- in the slave I/O thread, whenever we ignore an event because of its server id we update
a couple of coordinates in memory
- in the slave SQL thread, whenever we bump into the end of the latest relay log, we check
this couple of coordinates to see if we should advance our Exec_master_log_pos.
- when the slave I/O thread terminates it saves these in-memory coordinates into a Rotate event
in the relay log, so that they are durable.
sql/slave.h:
A couple of coordinates in RELAY_LOG_INFO to keep track of the last ignored events received
by the slave I/O thread (ignored because of the server id).
mysql-test/r/rpl_dual_pos_advance.result:
New BitKeeper file ``mysql-test/r/rpl_dual_pos_advance.result''
mysql-test/t/rpl_dual_pos_advance.test:
Test for BUG#13023 (with a part, disabled, to test BUG#13861 when I fix it).
Before the fix, this test used to hang.
2005-10-12 13:29:55 +02:00
|
|
|
|
BUG#13861 - START SLAVE UNTIL may stop 1 evnt too late if
log-slave-updates and circul repl
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
mysql-test/r/rpl_dual_pos_advance.result:
A test case for BUG#13861.
mysql-test/t/rpl_dual_pos_advance.test:
A test case for BUG#13861.
sql/log_event.cc:
Store length of event. This is needed for further calculation of
the beginning of event.
sql/slave.cc:
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
sql/slave.h:
Added master_log_pos parametr to is_until_satisfied().
mysql-test/t/rpl_dual_pos_advance-slave.opt:
New BitKeeper file ``mysql-test/t/rpl_dual_pos_advance-slave.opt''
2008-02-22 19:07:07 +04:00
|
|
|
create table t2 (n int); # create one ignored event
|
Fix for BUG#13023: "SQL Thread is up but doesn't move forward". Details in slave.cc;
in short we now record whenever the slave I/O thread ignores a master's event because of its server id,
and use this info in the slave SQL thread to advance Exec_master_log_pos. Because if we
do not, this variable stays at the position of the last executed event, i.e. the last *non-ignored*
executed one, which may not be the last of the master's binlog (and so the slave *looks* behind
the master though it's data-wise it's not).
mysql-test/t/rpl_dual_pos_advance-master.opt:
empty; its goal is just to trigger a server restart after running the test,
so that the master forgets that it was a slave (otherwise it affects the following tests).
sql/log.cc:
No more default arguments for Rotate_log_event constructor.
MYSQL_LOG::appendv() is now called without mutex.
sql/log_event.cc:
Moving one Rotate_log_event constructor from log_event.h. Support for on-demand choice of
duplicating the string argument of the constructor or not (because there now are needs for both
alternatives, see slave.cc).
sql/log_event.h:
We now have a case where a Rotate_log_event is executed by the slave SQL thread while
not being in the relay log, so it needs to pretend its length is 0: a ZERO_LEN flag for that;
a flag DUP_NAME (replaces "bool alloced") to be able to choose if we want the constructor
to duplicate the string argument or not.
sql/slave.cc:
A comment for BUG#13861 (to be fixed). llstr() instead of %ld as the number is ulonglong.
mi->rli becomes rli in some places.
Fix for BUG#13023:
- in the slave I/O thread, whenever we ignore an event because of its server id we update
a couple of coordinates in memory
- in the slave SQL thread, whenever we bump into the end of the latest relay log, we check
this couple of coordinates to see if we should advance our Exec_master_log_pos.
- when the slave I/O thread terminates it saves these in-memory coordinates into a Rotate event
in the relay log, so that they are durable.
sql/slave.h:
A couple of coordinates in RELAY_LOG_INFO to keep track of the last ignored events received
by the slave I/O thread (ignored because of the server id).
mysql-test/r/rpl_dual_pos_advance.result:
New BitKeeper file ``mysql-test/r/rpl_dual_pos_advance.result''
mysql-test/t/rpl_dual_pos_advance.test:
Test for BUG#13023 (with a part, disabled, to test BUG#13861 when I fix it).
Before the fix, this test used to hang.
2005-10-12 13:29:55 +02:00
|
|
|
|
BUG#13861 - START SLAVE UNTIL may stop 1 evnt too late if
log-slave-updates and circul repl
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
mysql-test/r/rpl_dual_pos_advance.result:
A test case for BUG#13861.
mysql-test/t/rpl_dual_pos_advance.test:
A test case for BUG#13861.
sql/log_event.cc:
Store length of event. This is needed for further calculation of
the beginning of event.
sql/slave.cc:
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
sql/slave.h:
Added master_log_pos parametr to is_until_satisfied().
mysql-test/t/rpl_dual_pos_advance-slave.opt:
New BitKeeper file ``mysql-test/t/rpl_dual_pos_advance-slave.opt''
2008-02-22 19:07:07 +04:00
|
|
|
save_master_pos;
|
|
|
|
|
connection slave;
|
|
|
|
|
sync_with_master;
|
Fix for BUG#13023: "SQL Thread is up but doesn't move forward". Details in slave.cc;
in short we now record whenever the slave I/O thread ignores a master's event because of its server id,
and use this info in the slave SQL thread to advance Exec_master_log_pos. Because if we
do not, this variable stays at the position of the last executed event, i.e. the last *non-ignored*
executed one, which may not be the last of the master's binlog (and so the slave *looks* behind
the master though it's data-wise it's not).
mysql-test/t/rpl_dual_pos_advance-master.opt:
empty; its goal is just to trigger a server restart after running the test,
so that the master forgets that it was a slave (otherwise it affects the following tests).
sql/log.cc:
No more default arguments for Rotate_log_event constructor.
MYSQL_LOG::appendv() is now called without mutex.
sql/log_event.cc:
Moving one Rotate_log_event constructor from log_event.h. Support for on-demand choice of
duplicating the string argument of the constructor or not (because there now are needs for both
alternatives, see slave.cc).
sql/log_event.h:
We now have a case where a Rotate_log_event is executed by the slave SQL thread while
not being in the relay log, so it needs to pretend its length is 0: a ZERO_LEN flag for that;
a flag DUP_NAME (replaces "bool alloced") to be able to choose if we want the constructor
to duplicate the string argument or not.
sql/slave.cc:
A comment for BUG#13861 (to be fixed). llstr() instead of %ld as the number is ulonglong.
mi->rli becomes rli in some places.
Fix for BUG#13023:
- in the slave I/O thread, whenever we ignore an event because of its server id we update
a couple of coordinates in memory
- in the slave SQL thread, whenever we bump into the end of the latest relay log, we check
this couple of coordinates to see if we should advance our Exec_master_log_pos.
- when the slave I/O thread terminates it saves these in-memory coordinates into a Rotate event
in the relay log, so that they are durable.
sql/slave.h:
A couple of coordinates in RELAY_LOG_INFO to keep track of the last ignored events received
by the slave I/O thread (ignored because of the server id).
mysql-test/r/rpl_dual_pos_advance.result:
New BitKeeper file ``mysql-test/r/rpl_dual_pos_advance.result''
mysql-test/t/rpl_dual_pos_advance.test:
Test for BUG#13023 (with a part, disabled, to test BUG#13861 when I fix it).
Before the fix, this test used to hang.
2005-10-12 13:29:55 +02:00
|
|
|
|
BUG#13861 - START SLAVE UNTIL may stop 1 evnt too late if
log-slave-updates and circul repl
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
mysql-test/r/rpl_dual_pos_advance.result:
A test case for BUG#13861.
mysql-test/t/rpl_dual_pos_advance.test:
A test case for BUG#13861.
sql/log_event.cc:
Store length of event. This is needed for further calculation of
the beginning of event.
sql/slave.cc:
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
sql/slave.h:
Added master_log_pos parametr to is_until_satisfied().
mysql-test/t/rpl_dual_pos_advance-slave.opt:
New BitKeeper file ``mysql-test/t/rpl_dual_pos_advance-slave.opt''
2008-02-22 19:07:07 +04:00
|
|
|
connection slave;
|
Fix for BUG#13023: "SQL Thread is up but doesn't move forward". Details in slave.cc;
in short we now record whenever the slave I/O thread ignores a master's event because of its server id,
and use this info in the slave SQL thread to advance Exec_master_log_pos. Because if we
do not, this variable stays at the position of the last executed event, i.e. the last *non-ignored*
executed one, which may not be the last of the master's binlog (and so the slave *looks* behind
the master though it's data-wise it's not).
mysql-test/t/rpl_dual_pos_advance-master.opt:
empty; its goal is just to trigger a server restart after running the test,
so that the master forgets that it was a slave (otherwise it affects the following tests).
sql/log.cc:
No more default arguments for Rotate_log_event constructor.
MYSQL_LOG::appendv() is now called without mutex.
sql/log_event.cc:
Moving one Rotate_log_event constructor from log_event.h. Support for on-demand choice of
duplicating the string argument of the constructor or not (because there now are needs for both
alternatives, see slave.cc).
sql/log_event.h:
We now have a case where a Rotate_log_event is executed by the slave SQL thread while
not being in the relay log, so it needs to pretend its length is 0: a ZERO_LEN flag for that;
a flag DUP_NAME (replaces "bool alloced") to be able to choose if we want the constructor
to duplicate the string argument or not.
sql/slave.cc:
A comment for BUG#13861 (to be fixed). llstr() instead of %ld as the number is ulonglong.
mi->rli becomes rli in some places.
Fix for BUG#13023:
- in the slave I/O thread, whenever we ignore an event because of its server id we update
a couple of coordinates in memory
- in the slave SQL thread, whenever we bump into the end of the latest relay log, we check
this couple of coordinates to see if we should advance our Exec_master_log_pos.
- when the slave I/O thread terminates it saves these in-memory coordinates into a Rotate event
in the relay log, so that they are durable.
sql/slave.h:
A couple of coordinates in RELAY_LOG_INFO to keep track of the last ignored events received
by the slave I/O thread (ignored because of the server id).
mysql-test/r/rpl_dual_pos_advance.result:
New BitKeeper file ``mysql-test/r/rpl_dual_pos_advance.result''
mysql-test/t/rpl_dual_pos_advance.test:
Test for BUG#13023 (with a part, disabled, to test BUG#13861 when I fix it).
Before the fix, this test used to hang.
2005-10-12 13:29:55 +02:00
|
|
|
|
BUG#13861 - START SLAVE UNTIL may stop 1 evnt too late if
log-slave-updates and circul repl
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
mysql-test/r/rpl_dual_pos_advance.result:
A test case for BUG#13861.
mysql-test/t/rpl_dual_pos_advance.test:
A test case for BUG#13861.
sql/log_event.cc:
Store length of event. This is needed for further calculation of
the beginning of event.
sql/slave.cc:
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
sql/slave.h:
Added master_log_pos parametr to is_until_satisfied().
mysql-test/t/rpl_dual_pos_advance-slave.opt:
New BitKeeper file ``mysql-test/t/rpl_dual_pos_advance-slave.opt''
2008-02-22 19:07:07 +04:00
|
|
|
show tables;
|
Fix for BUG#13023: "SQL Thread is up but doesn't move forward". Details in slave.cc;
in short we now record whenever the slave I/O thread ignores a master's event because of its server id,
and use this info in the slave SQL thread to advance Exec_master_log_pos. Because if we
do not, this variable stays at the position of the last executed event, i.e. the last *non-ignored*
executed one, which may not be the last of the master's binlog (and so the slave *looks* behind
the master though it's data-wise it's not).
mysql-test/t/rpl_dual_pos_advance-master.opt:
empty; its goal is just to trigger a server restart after running the test,
so that the master forgets that it was a slave (otherwise it affects the following tests).
sql/log.cc:
No more default arguments for Rotate_log_event constructor.
MYSQL_LOG::appendv() is now called without mutex.
sql/log_event.cc:
Moving one Rotate_log_event constructor from log_event.h. Support for on-demand choice of
duplicating the string argument of the constructor or not (because there now are needs for both
alternatives, see slave.cc).
sql/log_event.h:
We now have a case where a Rotate_log_event is executed by the slave SQL thread while
not being in the relay log, so it needs to pretend its length is 0: a ZERO_LEN flag for that;
a flag DUP_NAME (replaces "bool alloced") to be able to choose if we want the constructor
to duplicate the string argument or not.
sql/slave.cc:
A comment for BUG#13861 (to be fixed). llstr() instead of %ld as the number is ulonglong.
mi->rli becomes rli in some places.
Fix for BUG#13023:
- in the slave I/O thread, whenever we ignore an event because of its server id we update
a couple of coordinates in memory
- in the slave SQL thread, whenever we bump into the end of the latest relay log, we check
this couple of coordinates to see if we should advance our Exec_master_log_pos.
- when the slave I/O thread terminates it saves these in-memory coordinates into a Rotate event
in the relay log, so that they are durable.
sql/slave.h:
A couple of coordinates in RELAY_LOG_INFO to keep track of the last ignored events received
by the slave I/O thread (ignored because of the server id).
mysql-test/r/rpl_dual_pos_advance.result:
New BitKeeper file ``mysql-test/r/rpl_dual_pos_advance.result''
mysql-test/t/rpl_dual_pos_advance.test:
Test for BUG#13023 (with a part, disabled, to test BUG#13861 when I fix it).
Before the fix, this test used to hang.
2005-10-12 13:29:55 +02:00
|
|
|
|
BUG#13861 - START SLAVE UNTIL may stop 1 evnt too late if
log-slave-updates and circul repl
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
mysql-test/r/rpl_dual_pos_advance.result:
A test case for BUG#13861.
mysql-test/t/rpl_dual_pos_advance.test:
A test case for BUG#13861.
sql/log_event.cc:
Store length of event. This is needed for further calculation of
the beginning of event.
sql/slave.cc:
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
sql/slave.h:
Added master_log_pos parametr to is_until_satisfied().
mysql-test/t/rpl_dual_pos_advance-slave.opt:
New BitKeeper file ``mysql-test/t/rpl_dual_pos_advance-slave.opt''
2008-02-22 19:07:07 +04:00
|
|
|
save_master_pos;
|
Fix for BUG#13023: "SQL Thread is up but doesn't move forward". Details in slave.cc;
in short we now record whenever the slave I/O thread ignores a master's event because of its server id,
and use this info in the slave SQL thread to advance Exec_master_log_pos. Because if we
do not, this variable stays at the position of the last executed event, i.e. the last *non-ignored*
executed one, which may not be the last of the master's binlog (and so the slave *looks* behind
the master though it's data-wise it's not).
mysql-test/t/rpl_dual_pos_advance-master.opt:
empty; its goal is just to trigger a server restart after running the test,
so that the master forgets that it was a slave (otherwise it affects the following tests).
sql/log.cc:
No more default arguments for Rotate_log_event constructor.
MYSQL_LOG::appendv() is now called without mutex.
sql/log_event.cc:
Moving one Rotate_log_event constructor from log_event.h. Support for on-demand choice of
duplicating the string argument of the constructor or not (because there now are needs for both
alternatives, see slave.cc).
sql/log_event.h:
We now have a case where a Rotate_log_event is executed by the slave SQL thread while
not being in the relay log, so it needs to pretend its length is 0: a ZERO_LEN flag for that;
a flag DUP_NAME (replaces "bool alloced") to be able to choose if we want the constructor
to duplicate the string argument or not.
sql/slave.cc:
A comment for BUG#13861 (to be fixed). llstr() instead of %ld as the number is ulonglong.
mi->rli becomes rli in some places.
Fix for BUG#13023:
- in the slave I/O thread, whenever we ignore an event because of its server id we update
a couple of coordinates in memory
- in the slave SQL thread, whenever we bump into the end of the latest relay log, we check
this couple of coordinates to see if we should advance our Exec_master_log_pos.
- when the slave I/O thread terminates it saves these in-memory coordinates into a Rotate event
in the relay log, so that they are durable.
sql/slave.h:
A couple of coordinates in RELAY_LOG_INFO to keep track of the last ignored events received
by the slave I/O thread (ignored because of the server id).
mysql-test/r/rpl_dual_pos_advance.result:
New BitKeeper file ``mysql-test/r/rpl_dual_pos_advance.result''
mysql-test/t/rpl_dual_pos_advance.test:
Test for BUG#13023 (with a part, disabled, to test BUG#13861 when I fix it).
Before the fix, this test used to hang.
2005-10-12 13:29:55 +02:00
|
|
|
|
BUG#13861 - START SLAVE UNTIL may stop 1 evnt too late if
log-slave-updates and circul repl
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
mysql-test/r/rpl_dual_pos_advance.result:
A test case for BUG#13861.
mysql-test/t/rpl_dual_pos_advance.test:
A test case for BUG#13861.
sql/log_event.cc:
Store length of event. This is needed for further calculation of
the beginning of event.
sql/slave.cc:
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
sql/slave.h:
Added master_log_pos parametr to is_until_satisfied().
mysql-test/t/rpl_dual_pos_advance-slave.opt:
New BitKeeper file ``mysql-test/t/rpl_dual_pos_advance-slave.opt''
2008-02-22 19:07:07 +04:00
|
|
|
create table t3 (n int) engine=innodb;
|
|
|
|
|
set @a=1;
|
|
|
|
|
insert into t3 values(@a);
|
|
|
|
|
begin;
|
|
|
|
|
insert into t3 values(2);
|
|
|
|
|
insert into t3 values(3);
|
|
|
|
|
commit;
|
|
|
|
|
insert into t3 values(4);
|
Fix for BUG#13023: "SQL Thread is up but doesn't move forward". Details in slave.cc;
in short we now record whenever the slave I/O thread ignores a master's event because of its server id,
and use this info in the slave SQL thread to advance Exec_master_log_pos. Because if we
do not, this variable stays at the position of the last executed event, i.e. the last *non-ignored*
executed one, which may not be the last of the master's binlog (and so the slave *looks* behind
the master though it's data-wise it's not).
mysql-test/t/rpl_dual_pos_advance-master.opt:
empty; its goal is just to trigger a server restart after running the test,
so that the master forgets that it was a slave (otherwise it affects the following tests).
sql/log.cc:
No more default arguments for Rotate_log_event constructor.
MYSQL_LOG::appendv() is now called without mutex.
sql/log_event.cc:
Moving one Rotate_log_event constructor from log_event.h. Support for on-demand choice of
duplicating the string argument of the constructor or not (because there now are needs for both
alternatives, see slave.cc).
sql/log_event.h:
We now have a case where a Rotate_log_event is executed by the slave SQL thread while
not being in the relay log, so it needs to pretend its length is 0: a ZERO_LEN flag for that;
a flag DUP_NAME (replaces "bool alloced") to be able to choose if we want the constructor
to duplicate the string argument or not.
sql/slave.cc:
A comment for BUG#13861 (to be fixed). llstr() instead of %ld as the number is ulonglong.
mi->rli becomes rli in some places.
Fix for BUG#13023:
- in the slave I/O thread, whenever we ignore an event because of its server id we update
a couple of coordinates in memory
- in the slave SQL thread, whenever we bump into the end of the latest relay log, we check
this couple of coordinates to see if we should advance our Exec_master_log_pos.
- when the slave I/O thread terminates it saves these in-memory coordinates into a Rotate event
in the relay log, so that they are durable.
sql/slave.h:
A couple of coordinates in RELAY_LOG_INFO to keep track of the last ignored events received
by the slave I/O thread (ignored because of the server id).
mysql-test/r/rpl_dual_pos_advance.result:
New BitKeeper file ``mysql-test/r/rpl_dual_pos_advance.result''
mysql-test/t/rpl_dual_pos_advance.test:
Test for BUG#13023 (with a part, disabled, to test BUG#13861 when I fix it).
Before the fix, this test used to hang.
2005-10-12 13:29:55 +02:00
|
|
|
|
|
|
|
|
|
BUG#13861 - START SLAVE UNTIL may stop 1 evnt too late if
log-slave-updates and circul repl
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
mysql-test/r/rpl_dual_pos_advance.result:
A test case for BUG#13861.
mysql-test/t/rpl_dual_pos_advance.test:
A test case for BUG#13861.
sql/log_event.cc:
Store length of event. This is needed for further calculation of
the beginning of event.
sql/slave.cc:
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
sql/slave.h:
Added master_log_pos parametr to is_until_satisfied().
mysql-test/t/rpl_dual_pos_advance-slave.opt:
New BitKeeper file ``mysql-test/t/rpl_dual_pos_advance-slave.opt''
2008-02-22 19:07:07 +04:00
|
|
|
connection master;
|
Fix for BUG#13023: "SQL Thread is up but doesn't move forward". Details in slave.cc;
in short we now record whenever the slave I/O thread ignores a master's event because of its server id,
and use this info in the slave SQL thread to advance Exec_master_log_pos. Because if we
do not, this variable stays at the position of the last executed event, i.e. the last *non-ignored*
executed one, which may not be the last of the master's binlog (and so the slave *looks* behind
the master though it's data-wise it's not).
mysql-test/t/rpl_dual_pos_advance-master.opt:
empty; its goal is just to trigger a server restart after running the test,
so that the master forgets that it was a slave (otherwise it affects the following tests).
sql/log.cc:
No more default arguments for Rotate_log_event constructor.
MYSQL_LOG::appendv() is now called without mutex.
sql/log_event.cc:
Moving one Rotate_log_event constructor from log_event.h. Support for on-demand choice of
duplicating the string argument of the constructor or not (because there now are needs for both
alternatives, see slave.cc).
sql/log_event.h:
We now have a case where a Rotate_log_event is executed by the slave SQL thread while
not being in the relay log, so it needs to pretend its length is 0: a ZERO_LEN flag for that;
a flag DUP_NAME (replaces "bool alloced") to be able to choose if we want the constructor
to duplicate the string argument or not.
sql/slave.cc:
A comment for BUG#13861 (to be fixed). llstr() instead of %ld as the number is ulonglong.
mi->rli becomes rli in some places.
Fix for BUG#13023:
- in the slave I/O thread, whenever we ignore an event because of its server id we update
a couple of coordinates in memory
- in the slave SQL thread, whenever we bump into the end of the latest relay log, we check
this couple of coordinates to see if we should advance our Exec_master_log_pos.
- when the slave I/O thread terminates it saves these in-memory coordinates into a Rotate event
in the relay log, so that they are durable.
sql/slave.h:
A couple of coordinates in RELAY_LOG_INFO to keep track of the last ignored events received
by the slave I/O thread (ignored because of the server id).
mysql-test/r/rpl_dual_pos_advance.result:
New BitKeeper file ``mysql-test/r/rpl_dual_pos_advance.result''
mysql-test/t/rpl_dual_pos_advance.test:
Test for BUG#13023 (with a part, disabled, to test BUG#13861 when I fix it).
Before the fix, this test used to hang.
2005-10-12 13:29:55 +02:00
|
|
|
|
|
|
|
|
# bug is that START SLAVE UNTIL may stop too late, we test that by
|
|
|
|
|
# asking it to stop before creation of t3.
|
|
|
|
|
|
BUG#13861 - START SLAVE UNTIL may stop 1 evnt too late if
log-slave-updates and circul repl
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
mysql-test/r/rpl_dual_pos_advance.result:
A test case for BUG#13861.
mysql-test/t/rpl_dual_pos_advance.test:
A test case for BUG#13861.
sql/log_event.cc:
Store length of event. This is needed for further calculation of
the beginning of event.
sql/slave.cc:
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
sql/slave.h:
Added master_log_pos parametr to is_until_satisfied().
mysql-test/t/rpl_dual_pos_advance-slave.opt:
New BitKeeper file ``mysql-test/t/rpl_dual_pos_advance-slave.opt''
2008-02-22 19:07:07 +04:00
|
|
|
start slave until master_log_file="slave-bin.000001",master_log_pos=195;
|
|
|
|
|
wait_for_slave_to_stop;
|
Fix for BUG#13023: "SQL Thread is up but doesn't move forward". Details in slave.cc;
in short we now record whenever the slave I/O thread ignores a master's event because of its server id,
and use this info in the slave SQL thread to advance Exec_master_log_pos. Because if we
do not, this variable stays at the position of the last executed event, i.e. the last *non-ignored*
executed one, which may not be the last of the master's binlog (and so the slave *looks* behind
the master though it's data-wise it's not).
mysql-test/t/rpl_dual_pos_advance-master.opt:
empty; its goal is just to trigger a server restart after running the test,
so that the master forgets that it was a slave (otherwise it affects the following tests).
sql/log.cc:
No more default arguments for Rotate_log_event constructor.
MYSQL_LOG::appendv() is now called without mutex.
sql/log_event.cc:
Moving one Rotate_log_event constructor from log_event.h. Support for on-demand choice of
duplicating the string argument of the constructor or not (because there now are needs for both
alternatives, see slave.cc).
sql/log_event.h:
We now have a case where a Rotate_log_event is executed by the slave SQL thread while
not being in the relay log, so it needs to pretend its length is 0: a ZERO_LEN flag for that;
a flag DUP_NAME (replaces "bool alloced") to be able to choose if we want the constructor
to duplicate the string argument or not.
sql/slave.cc:
A comment for BUG#13861 (to be fixed). llstr() instead of %ld as the number is ulonglong.
mi->rli becomes rli in some places.
Fix for BUG#13023:
- in the slave I/O thread, whenever we ignore an event because of its server id we update
a couple of coordinates in memory
- in the slave SQL thread, whenever we bump into the end of the latest relay log, we check
this couple of coordinates to see if we should advance our Exec_master_log_pos.
- when the slave I/O thread terminates it saves these in-memory coordinates into a Rotate event
in the relay log, so that they are durable.
sql/slave.h:
A couple of coordinates in RELAY_LOG_INFO to keep track of the last ignored events received
by the slave I/O thread (ignored because of the server id).
mysql-test/r/rpl_dual_pos_advance.result:
New BitKeeper file ``mysql-test/r/rpl_dual_pos_advance.result''
mysql-test/t/rpl_dual_pos_advance.test:
Test for BUG#13023 (with a part, disabled, to test BUG#13861 when I fix it).
Before the fix, this test used to hang.
2005-10-12 13:29:55 +02:00
|
|
|
|
|
|
|
|
# then BUG#13861 causes t3 to show up below (because stopped too
|
|
|
|
|
# late).
|
|
|
|
|
|
BUG#13861 - START SLAVE UNTIL may stop 1 evnt too late if
log-slave-updates and circul repl
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
mysql-test/r/rpl_dual_pos_advance.result:
A test case for BUG#13861.
mysql-test/t/rpl_dual_pos_advance.test:
A test case for BUG#13861.
sql/log_event.cc:
Store length of event. This is needed for further calculation of
the beginning of event.
sql/slave.cc:
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
sql/slave.h:
Added master_log_pos parametr to is_until_satisfied().
mysql-test/t/rpl_dual_pos_advance-slave.opt:
New BitKeeper file ``mysql-test/t/rpl_dual_pos_advance-slave.opt''
2008-02-22 19:07:07 +04:00
|
|
|
show tables;
|
|
|
|
|
|
|
|
|
|
# ensure that we do not break set @a=1; insert into t3 values(@a);
|
|
|
|
|
start slave until master_log_file="slave-bin.000001",master_log_pos=438;
|
|
|
|
|
wait_for_slave_to_stop;
|
|
|
|
|
select * from t3;
|
|
|
|
|
|
|
|
|
|
# ensure that we do not break transaction
|
|
|
|
|
start slave until master_log_file="slave-bin.000001",master_log_pos=663;
|
|
|
|
|
wait_for_slave_to_stop;
|
|
|
|
|
select * from t3;
|
Fix for BUG#13023: "SQL Thread is up but doesn't move forward". Details in slave.cc;
in short we now record whenever the slave I/O thread ignores a master's event because of its server id,
and use this info in the slave SQL thread to advance Exec_master_log_pos. Because if we
do not, this variable stays at the position of the last executed event, i.e. the last *non-ignored*
executed one, which may not be the last of the master's binlog (and so the slave *looks* behind
the master though it's data-wise it's not).
mysql-test/t/rpl_dual_pos_advance-master.opt:
empty; its goal is just to trigger a server restart after running the test,
so that the master forgets that it was a slave (otherwise it affects the following tests).
sql/log.cc:
No more default arguments for Rotate_log_event constructor.
MYSQL_LOG::appendv() is now called without mutex.
sql/log_event.cc:
Moving one Rotate_log_event constructor from log_event.h. Support for on-demand choice of
duplicating the string argument of the constructor or not (because there now are needs for both
alternatives, see slave.cc).
sql/log_event.h:
We now have a case where a Rotate_log_event is executed by the slave SQL thread while
not being in the relay log, so it needs to pretend its length is 0: a ZERO_LEN flag for that;
a flag DUP_NAME (replaces "bool alloced") to be able to choose if we want the constructor
to duplicate the string argument or not.
sql/slave.cc:
A comment for BUG#13861 (to be fixed). llstr() instead of %ld as the number is ulonglong.
mi->rli becomes rli in some places.
Fix for BUG#13023:
- in the slave I/O thread, whenever we ignore an event because of its server id we update
a couple of coordinates in memory
- in the slave SQL thread, whenever we bump into the end of the latest relay log, we check
this couple of coordinates to see if we should advance our Exec_master_log_pos.
- when the slave I/O thread terminates it saves these in-memory coordinates into a Rotate event
in the relay log, so that they are durable.
sql/slave.h:
A couple of coordinates in RELAY_LOG_INFO to keep track of the last ignored events received
by the slave I/O thread (ignored because of the server id).
mysql-test/r/rpl_dual_pos_advance.result:
New BitKeeper file ``mysql-test/r/rpl_dual_pos_advance.result''
mysql-test/t/rpl_dual_pos_advance.test:
Test for BUG#13023 (with a part, disabled, to test BUG#13861 when I fix it).
Before the fix, this test used to hang.
2005-10-12 13:29:55 +02:00
|
|
|
|
BUG#13861 - START SLAVE UNTIL may stop 1 evnt too late if
log-slave-updates and circul repl
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
mysql-test/r/rpl_dual_pos_advance.result:
A test case for BUG#13861.
mysql-test/t/rpl_dual_pos_advance.test:
A test case for BUG#13861.
sql/log_event.cc:
Store length of event. This is needed for further calculation of
the beginning of event.
sql/slave.cc:
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
sql/slave.h:
Added master_log_pos parametr to is_until_satisfied().
mysql-test/t/rpl_dual_pos_advance-slave.opt:
New BitKeeper file ``mysql-test/t/rpl_dual_pos_advance-slave.opt''
2008-02-22 19:07:07 +04:00
|
|
|
start slave;
|
Fix for BUG#13023: "SQL Thread is up but doesn't move forward". Details in slave.cc;
in short we now record whenever the slave I/O thread ignores a master's event because of its server id,
and use this info in the slave SQL thread to advance Exec_master_log_pos. Because if we
do not, this variable stays at the position of the last executed event, i.e. the last *non-ignored*
executed one, which may not be the last of the master's binlog (and so the slave *looks* behind
the master though it's data-wise it's not).
mysql-test/t/rpl_dual_pos_advance-master.opt:
empty; its goal is just to trigger a server restart after running the test,
so that the master forgets that it was a slave (otherwise it affects the following tests).
sql/log.cc:
No more default arguments for Rotate_log_event constructor.
MYSQL_LOG::appendv() is now called without mutex.
sql/log_event.cc:
Moving one Rotate_log_event constructor from log_event.h. Support for on-demand choice of
duplicating the string argument of the constructor or not (because there now are needs for both
alternatives, see slave.cc).
sql/log_event.h:
We now have a case where a Rotate_log_event is executed by the slave SQL thread while
not being in the relay log, so it needs to pretend its length is 0: a ZERO_LEN flag for that;
a flag DUP_NAME (replaces "bool alloced") to be able to choose if we want the constructor
to duplicate the string argument or not.
sql/slave.cc:
A comment for BUG#13861 (to be fixed). llstr() instead of %ld as the number is ulonglong.
mi->rli becomes rli in some places.
Fix for BUG#13023:
- in the slave I/O thread, whenever we ignore an event because of its server id we update
a couple of coordinates in memory
- in the slave SQL thread, whenever we bump into the end of the latest relay log, we check
this couple of coordinates to see if we should advance our Exec_master_log_pos.
- when the slave I/O thread terminates it saves these in-memory coordinates into a Rotate event
in the relay log, so that they are durable.
sql/slave.h:
A couple of coordinates in RELAY_LOG_INFO to keep track of the last ignored events received
by the slave I/O thread (ignored because of the server id).
mysql-test/r/rpl_dual_pos_advance.result:
New BitKeeper file ``mysql-test/r/rpl_dual_pos_advance.result''
mysql-test/t/rpl_dual_pos_advance.test:
Test for BUG#13023 (with a part, disabled, to test BUG#13861 when I fix it).
Before the fix, this test used to hang.
2005-10-12 13:29:55 +02:00
|
|
|
|
|
|
|
|
# BUG#13023 is that Exec_master_log_pos may stay too low "forever":
|
|
|
|
|
|
|
|
|
|
connection master;
|
|
|
|
|
|
|
|
|
|
create table t4 (n int); # create 3 ignored events
|
|
|
|
|
create table t5 (n int);
|
|
|
|
|
create table t6 (n int);
|
|
|
|
|
|
|
|
|
|
save_master_pos;
|
|
|
|
|
connection slave;
|
|
|
|
|
sync_with_master;
|
|
|
|
|
|
|
|
|
|
connection slave;
|
|
|
|
|
|
|
|
|
|
save_master_pos;
|
|
|
|
|
|
|
|
|
|
connection master;
|
|
|
|
|
|
|
|
|
|
# then BUG#13023 caused hang below ("master" looks behind, while it's
|
|
|
|
|
# not in terms of updates done).
|
|
|
|
|
|
|
|
|
|
sync_with_master;
|
|
|
|
|
|
|
|
|
|
show tables;
|
|
|
|
|
|
|
|
|
|
# cleanup
|
|
|
|
|
|
|
|
|
|
stop slave;
|
|
|
|
|
reset slave;
|
BUG#13861 - START SLAVE UNTIL may stop 1 evnt too late if
log-slave-updates and circul repl
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
mysql-test/r/rpl_dual_pos_advance.result:
A test case for BUG#13861.
mysql-test/t/rpl_dual_pos_advance.test:
A test case for BUG#13861.
sql/log_event.cc:
Store length of event. This is needed for further calculation of
the beginning of event.
sql/slave.cc:
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
sql/slave.h:
Added master_log_pos parametr to is_until_satisfied().
mysql-test/t/rpl_dual_pos_advance-slave.opt:
New BitKeeper file ``mysql-test/t/rpl_dual_pos_advance-slave.opt''
2008-02-22 19:07:07 +04:00
|
|
|
drop table t1,t2,t3,t4,t5,t6;
|
Fix for BUG#13023: "SQL Thread is up but doesn't move forward". Details in slave.cc;
in short we now record whenever the slave I/O thread ignores a master's event because of its server id,
and use this info in the slave SQL thread to advance Exec_master_log_pos. Because if we
do not, this variable stays at the position of the last executed event, i.e. the last *non-ignored*
executed one, which may not be the last of the master's binlog (and so the slave *looks* behind
the master though it's data-wise it's not).
mysql-test/t/rpl_dual_pos_advance-master.opt:
empty; its goal is just to trigger a server restart after running the test,
so that the master forgets that it was a slave (otherwise it affects the following tests).
sql/log.cc:
No more default arguments for Rotate_log_event constructor.
MYSQL_LOG::appendv() is now called without mutex.
sql/log_event.cc:
Moving one Rotate_log_event constructor from log_event.h. Support for on-demand choice of
duplicating the string argument of the constructor or not (because there now are needs for both
alternatives, see slave.cc).
sql/log_event.h:
We now have a case where a Rotate_log_event is executed by the slave SQL thread while
not being in the relay log, so it needs to pretend its length is 0: a ZERO_LEN flag for that;
a flag DUP_NAME (replaces "bool alloced") to be able to choose if we want the constructor
to duplicate the string argument or not.
sql/slave.cc:
A comment for BUG#13861 (to be fixed). llstr() instead of %ld as the number is ulonglong.
mi->rli becomes rli in some places.
Fix for BUG#13023:
- in the slave I/O thread, whenever we ignore an event because of its server id we update
a couple of coordinates in memory
- in the slave SQL thread, whenever we bump into the end of the latest relay log, we check
this couple of coordinates to see if we should advance our Exec_master_log_pos.
- when the slave I/O thread terminates it saves these in-memory coordinates into a Rotate event
in the relay log, so that they are durable.
sql/slave.h:
A couple of coordinates in RELAY_LOG_INFO to keep track of the last ignored events received
by the slave I/O thread (ignored because of the server id).
mysql-test/r/rpl_dual_pos_advance.result:
New BitKeeper file ``mysql-test/r/rpl_dual_pos_advance.result''
mysql-test/t/rpl_dual_pos_advance.test:
Test for BUG#13023 (with a part, disabled, to test BUG#13861 when I fix it).
Before the fix, this test used to hang.
2005-10-12 13:29:55 +02:00
|
|
|
|
|
|
|
|
save_master_pos;
|
|
|
|
|
connection slave;
|
|
|
|
|
sync_with_master;
|
|
|
|
|
|
|
|
|
|
# End of 4.1 tests
|