On Fri, Sep 18, 2009 at 1:55 PM, Kristian Nielsen <kniel...@knielsen-hq.org> wrote: > There is a replication FAQ, which says this: > > http://dev.mysql.com/doc/refman/5.1/en/replication-faq.html > > 16.3.4.3: How do I know how late a slave is compared to the master? > > You can read the Seconds_Behind_Master column in SHOW SLAVE STATUS. See > Section 16.4.1,“Replication Implementation Details”. > > In the Time column in the output of SHOW PROCESSLIST, the number of > seconds displayed for the slave SQL thread is the number of seconds > between the timestamp of the last replicated event and the real time of > the slave machine. You can use this to determine the date of the last > replicated event. > > However, this does not take into account the possibility of time skew between > master and slave. The actual value displayed in SHOW PROCESSLIST is > > <current time> - <time of original event> + <time skew> > > To me, this is just too complex to be really useful. > > On the other hand, Seconds_Behind_Master _does_ take into account the time > skew, so it seems a much more useful metric to use to me. Frankly, to me this > last part of the documentation sounds to me like trying to spin a bug as a > feature.
FWIW, 12 months ago I could still spot negative values, well really high values as I think it reports an unsigned int) in Seconds_Behind_Master. Never manually, but indeed with a script that was busy selecting the value. (The script would break when the value suddenly became "really high value".) This was after such behavior had been "fixed" at least 2 times. (Can't find the bug number now.) A bit off topic, but maybe relevant as background info. > Now, the microsec_process patch adds a TIME_MS column, which works like TIME > is documented, except with microsecond precision. This leaves three options to > choose between: > > 1. Let TIME_MS also depend on @@TIMESTAMP. This is particularly ugly, as > TIMESTAMP has seconds granularity, so rounding effects will be > "interesting". I really don't like this idea. > > 2. Let TIME_MS be independent of @@TIMESTAMP; it will just be the time since > last state change, with microseconds resolution. But keep currently > implemented semantics of TIME. This means that TIME and TIME_MS will be > unrelated for threads that change @@TIMESTAMP (like the slave thread). This > will be confusing. > > 3. Change implementation of TIME so that both TIME and TIME_MS are independent > of @@TIMESTAMP. > > Of these, I tend to prefer option 3. > > Reason is that the semantics is much cleaner and simple to understand. > > The functionality to see how much slave is behind is in any case better > obtained using Seconds_Behind_Master. > > However, it does involve a change in behaviour, so I want to ask opinions if > anyone thinks the change in behaviour would cause too much breakage? I'm the wrong person to answer, but seems to me we should at this stage prefer being bug-for-bug compatible and changing semantics between MariaDB and MySQL may turn out to be more of a problem than being helpful. (If we could agree with the MySQL team to adopt the fix in a future version, it would be different.) Btw, Monty is back home but still not on email / IRC. Call him if you want his opinion. henrik -- email: henrik.i...@avoinelama.fi tel: +358-40-5697354 www: www.avoinelama.fi/~hingo book: www.openlife.cc _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
