On Friday 19 May 2006 17:49, sheeri kritzer wrote:
> I suggest writing a very simple shell script to run "SHOW SLAVE
> STATUS" and output it to a file every 15 seconds, to verify your
> script is working. I have never seen MySQL give a bad lag time for
> replication -- it's always been accurate fo
replicated command _started_ on the _master_.
Granted, 21 sounds excessive.
> -Original Message-
> From: Martijn van den Burg [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 19, 2006 8:35 AM
> To: sheeri kritzer
> Cc: mysql@lists.mysql.com; [EMAIL PROTECTED]
> Subject:
Or check out a very nice Perl snippet on the Forge:
http://forge.mysql.com/snippets/view.php?id=5
sheeri kritzer wrote:
I suggest writing a very simple shell script to run "SHOW SLAVE
STATUS" and output it to a file every 15 seconds, to verify your
script is working. I have never seen MySQL gi
I suggest writing a very simple shell script to run "SHOW SLAVE
STATUS" and output it to a file every 15 seconds, to verify your
script is working. I have never seen MySQL give a bad lag time for
replication -- it's always been accurate for lag time, or 0, or NULL.
As a bonus you could then use
> That is weird. If it only lasts a couple of seconds, how are you
> monitoring it to find out what the lag time is?
I've written a replication monitor script using Perl::POE, which checks
replication lag every 15 seconds or so (can't check the exact interval now -
weekend has begun here).
--
On 5/19/06, Martijn van den Burg <[EMAIL PROTECTED]> wrote:
Nothing special, just some updates on a single database. No flushing of
logs... The strange thing is that the condition of extremely high lag lasts
only a couple of seconds, and then tapers back very quickly to zero.
That is weird. I
Hi,
On Friday 19 May 2006 17:12, sheeri kritzer wrote:
> I've found that queries that take a long time cause lag time.
Yes, I know, especially on a busy server. The master handles multiple
statements (connections) in parallel, but the slave processes them serially.
My 4.1.10 setup does about 17
I've found that queries that take a long time cause lag time.
Replication on a slave has 2 threads -- one to retrieve stuff from the
logs, and another to actually run the DML queries. Therefore, while
one thread is stuck on a loggg query, the other thread is
still gathering stuff from th
Hi,
Recently I created a new replication set up with 5.0.18-standard-log on Solaris
8 (one master, one slave).
Replication is running, but periodically (after a bunch of INSERT/UPDATE
statements) there is a very large replication lag, with Seconds_Behind_Master
values of 21 and more. This
