On Sat, 3 Nov 2007, bob b wrote:
Good to hear that you found the problem.
The only remaining puzzle is why the replica reported that it was up to date
when it was several binlogs behind.
Possibly the replica was always caught up with the last entry from the very
slow link.
Perhaps you should report this as a bug? The replication mechanism should be
able to check the last binlog being written on the master and report that
difference?
Bob Bankay (from home)
The reporting confusion is due to the fact that the "seconds behind
master" figure is based on the relay logs and how long it will take to catch
up.
For example, I had replication shut down for 45 minutes wile feeding
millions of writes into the master. On slave restart the binlog dump
started, and it went fast. As the relay log grew so did seconds behind
master. One the relay log was up to date, the "seconds behind master" was
based on the execution rate and backlog. (Somthing like 12 minutes and
counting down)
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.
It would be nice if there was a way for the slave to find the actual
current master position and compare with the local state though.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
