diff options
author | unknown <aelkin/elkin@koti.dsl.inet.fi> | 2007-10-04 18:46:31 +0300 |
---|---|---|
committer | unknown <aelkin/elkin@koti.dsl.inet.fi> | 2007-10-04 18:46:31 +0300 |
commit | bf8a85aa56fe755a1712a08b45667734765d45c8 (patch) | |
tree | 7bea0c44c6bb17183e0c153e64747c11b97e9902 /sql/slave.cc | |
parent | 69604f4db10f125651ab0620320dbd91253c5bc6 (diff) | |
download | mariadb-git-bf8a85aa56fe755a1712a08b45667734765d45c8.tar.gz |
Bug #29309 Incorrect "Seconds_Behind_Master" value in SHOW SLAVE STATUS after FLUSH LOGS
Report claims that Seconds_behind_master behaves unexpectedly.
Code analysis shows that there is an evident flaw in that treating of FormatDescription event is wrong
so that after FLUSH LOGS on slave the Seconds_behind_master's calculation slips and incorrect
value can be reported to SHOW SLAVE STATUS.
Even worse is that the gap between the correct and incorrect deltas grows with time.
Fixed with prohibiting changes to rpl->last_master_timestamp by artifical events (any kind of).
suggestion as comments is added how to fight with lack of info on the slave side by means of
new heartbeat feature coming.
The test can not be done ealily fully determistic.
sql/log_event.cc:
changing timestamp is affirmed only by non-artificial events. Artifical FD won't change it anymore.
The simulation code is off unless server is started with the args from the opt-file.
The simulation code assumes that it will execute specific schedule generated by rpl_replication_delay.test.
sql/slave.cc:
Comments are changed to announce a new possibility to cope with
Seconds_behind_master jumping due to EOF special treatment (reset of the timestamp)
mysql-test/suite/manual/r/rpl_replication_delay.result:
result are not deterministic though there are comments saying the most probable expected
value for Seconds_behind_master
mysql-test/suite/manual/t/rpl_replication_delay-slave.opt:
bug emulation
mysql-test/suite/manual/t/rpl_replication_delay.test:
specic test for bug#29309. It's hard to make it reliable as it deals with timestamps.
(a way to automate the test like this is to have I_S table for show slave status' fields)
A possible way to check results is to run
grep -i 'show\|seconds' < suite/manual/r/rpl_replication_delay.reject and to get the lines like these:
show slave status /* Second_behind reports 0 */;;
Seconds_Behind_Master 0
show slave status /* bug emulated: reports slave threads starting time about 3*3 not 3 secs */;;
Seconds_Behind_Master 9
show slave status /* reports the correct diff with master query time about 3+3 secs */;;
Seconds_Behind_Master 6
Due to time discreteness of time the reported numbers may slightly vary. That's why the test is not reliable.
Diffstat (limited to 'sql/slave.cc')
-rw-r--r-- | sql/slave.cc | 11 |
1 files changed, 10 insertions, 1 deletions
diff --git a/sql/slave.cc b/sql/slave.cc index 57f6e64ce03..0bc4bf7b32f 100644 --- a/sql/slave.cc +++ b/sql/slave.cc @@ -4931,7 +4931,16 @@ Log_event* next_event(RELAY_LOG_INFO* rli) a new event and is queuing it; the false "0" will exist until SQL finishes executing the new event; it will be look abnormal only if the events have old timestamps (then you get "many", 0, "many"). - Transient phases like this can't really be fixed. + + Transient phases like this can be fixed with implemeting + Heartbeat event which provides the slave the status of the + master at time the master does not have any new update to send. + Seconds_Behind_Master would be zero only when master has no + more updates in binlog for slave. The heartbeat can be sent + in a (small) fraction of slave_net_timeout. Until it's done + rli->last_master_timestamp is temporarely (for time of + waiting for the following event) reset whenever EOF is + reached. */ time_t save_timestamp= rli->last_master_timestamp; rli->last_master_timestamp= 0; |