5.3.1. Latency or Relative Latency Display

Tungsten Clustering can operate using either absolute or relative latency. The
two are distinguished according to how the difference between transaction
commit times are handled:

Absolute latency — (default) is
the difference between when a transaction was applied to a slave and
when the transaction was originally applied to the master.

Relative latency — is the
difference between now and when the last transaction was written to
the slave.

Absolute latency indicates the difference between transaction times, but,
may also provide a misleading impression of the cluster state if there are
large transactions being applied, or if the slave has stopped or become
'stuck' due to a transient failure. This is because absolute latency shows
the time difference between transactions. If a transaction takes 5 or 10
seconds to apply, the absolute latency will only display the difference
between when the transaction was written, and only after this has occurred
on both the master and the slave. The actual time difference between these
may be less than a second, even though the transaction took 10 seconds to
succeed.

Relative latency shows the time difference between the last transaction
committed and the current time, hence if the transaction takes a
considerable time to be applied, the relative latency will increase up
until the transaction has finally been committed. If the relative latency
increases and continues to increase, it may indicate a lagging or even
failed slave.

To enable relative latency, the cluster must have been deployed, or
updated, using the
--use-relative-latency=true option to
tpm. Once enabled, the following operational activities
change:

The output of show slave
status when connected to MySQL through a connector will be
updated so that the
Seconds_Behind_Master field
shows the relative, rather than absolute, latency. For example, in a
cluster where relative latency is enabled, but no transactions are
occurring, the output will show an increasing value: