From 3a100805809eb2e614c6c28939a7ebbbb4c72d7c Mon Sep 17 00:00:00 2001 From: unknown Date: Tue, 2 Mar 2004 22:38:14 +0100 Subject: [PATCH 1/2] After hours of unsuccessful research on BUG#2826 "Seconds behind master weirdness" (sometimes this column of SHOW SLAVE STATUS shows a very big value, in fact a small negative number casted to ulonglong). This problem was reported by only one user, but which uses synchronized time between his servers. As suggested by the user, to hide this I display max(0, the value) so that it will be less confusing. For a user, seeing 0 is probably better than seeing -1 (both tell you that the slave is very close to the master). sql/slave.cc: Don't display a negative Seconds_Behind_Master in SHOW SLAVE STATUS. --- sql/slave.cc | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/sql/slave.cc b/sql/slave.cc index bbf1741183b..ed16c3361c6 100644 --- a/sql/slave.cc +++ b/sql/slave.cc @@ -2060,10 +2060,16 @@ int show_master_info(THD* thd, MASTER_INFO* mi) protocol->store(mi->ssl_key, &my_charset_bin); if (mi->rli.last_master_timestamp) - protocol->store((ulonglong) - (long)((time_t)time((time_t*) 0) - - mi->rli.last_master_timestamp) - - mi->clock_diff_with_master); + { + long tmp= (long)((time_t)time((time_t*) 0) + - mi->rli.last_master_timestamp) + - mi->clock_diff_with_master; + /* + Apparently on some systems tmp can be <0 (which is still a + mistery). This confuses users, so we don't go below 0. + */ + protocol->store((longlong)(max(0, tmp))); + } else protocol->store_null(); From f34c3fff49f48b6885749de6d5a0504c030f650f Mon Sep 17 00:00:00 2001 From: unknown Date: Tue, 2 Mar 2004 23:03:52 +0100 Subject: [PATCH 2/2] More comments on what could explain -1 in Seconds_Behind_Master in SHOW SLAVE STATUS. --- sql/slave.cc | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/sql/slave.cc b/sql/slave.cc index ed16c3361c6..e737febdd8a 100644 --- a/sql/slave.cc +++ b/sql/slave.cc @@ -2065,8 +2065,21 @@ int show_master_info(THD* thd, MASTER_INFO* mi) - mi->rli.last_master_timestamp) - mi->clock_diff_with_master; /* - Apparently on some systems tmp can be <0 (which is still a - mistery). This confuses users, so we don't go below 0. + Apparently on some systems tmp can be <0. Here are possible reasons + related to MySQL: + - the master is itself a slave of another master whose time is ahead. + - somebody used an explicit SET TIMESTAMP on the master. + Possible reason related to granularity-to-second of time functions + (nothing to do with MySQL), which can explain a value of -1: + assume the master's and slave's time are perfectly synchronized, and + that at slave's connection time, when the master's timestamp is read, + it is at the very end of second 1, and (a very short time later) when + the slave's timestamp is read it is at the very beginning of second + 2. Then the recorded value for master is 1 and the recorded value for + slave is 2. At SHOW SLAVE STATUS time, assume that the difference + between timestamp of slave and rli->last_master_timestamp is 0 + (i.e. they are in the same second), then we get 0-(2-1)=-1 as a result. + This confuses users, so we don't go below 0. */ protocol->store((longlong)(max(0, tmp))); }