I was suspicious I was missing something basic here. Well, that’s quite interesting and thanks for the quick reply!

-joe
PS You’re book should be here in two more days!

That works on many database servers, but not MySQL, because the current timestamp at the time of execution is stored in the binary log, and functions such as NOW() will thus return the same result on the slave as they do on the master. See also mk-heartbeat from Maatkit.

I’m new to MySQL, so forgive me if I show some blatant lack of understanding here, but I have been replicating databases and using heart beat tables to calculate latency for many years. Typically, I’ll have a job periodically insert or update a row on the source/master with an ID and the source’s current time. When this hits the slave/target, the target current time is stored in another column. The delta is the lag.

Thanks for a very useful website!

Cheers,
-joe

update account set balance = balance + 5 where id = 10;

I think you ultimately have to build your application to tolerate slave lag. The more robust you make that, the better off you’ll be.

If you’re having trouble making this work right, a few hours of consulting help might be a good investment. Check out the companies I listed in this post.

Regarding the slave not having caught up to it’s master – and wanting to select from the slave…

Do you think it an okay idea to make a database link to the master – update the master close the connection, make a connection to the slave and also update the slave (from which you are just about to select from) (with the same data that just got inserted into the master) and then select from the slave.

Sounds messy and you have to make sure you are updating and selecting from the same slave in order to make use of it. Or would that be a bad idea?

Thanks again :)