Running on our systems, we have had the replica load data and then
started. The longest delta was about 28 hours behind the master. The
slave status faithfully reported how far behind the master it was, when
the slave was started, even as it was loading its relay-logs from the
master which if I remember correctly took a couple of hours that first
time. During that first part when the relay logs were loading, the
seconds behind would increase and when the relay log caught up the delta
started decreasing rapidly to zero.
We are running x86-64bit hardware with RH Linux and a 1Gbit ethernet
link between master and slave (nothing exotic). The load on the link
never seems to an issue, so we have never monitored it closely.
So, if you are happy with the situation then it is solved.
Cheers,
Bob Bankay
Baron Schwartz wrote:
Christopher E. Brown wrote:
On Sat, 3 Nov 2007, bob b wrote:
So, a slave is down for 8hrs. It comes online and pulls the binlog
in 120 seconds. The "seconds behind master" does not reflect 8hrs,
but how many seconds (at current processing rate) before the slave
finishes the relay logs.
The "seconds behind master" value is really "seconds until currency
with the relay logs" and should prolly be documented as such.
This is incorrect. In most circumstances, it's basically the
difference between the timestamp of the binlog event the SQL thread is
currently processing, and the master's current timestamp (as fetched
by the I/O thread). So it really is what it sounds like: the seconds
behind the master. If it says 100, it means the slave is processing
an event that took place 100 seconds ago on the master.
You can read the source code in show_master_info() in sql/slave.cc.
Baron
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
