Here’s a typical graph:

Download: mysql_slave (1 Kb)

EDIT: I wrote this so I could better understand the recovery time of a slave which had 13 hours of updates to catch up on. While it was good for that, it’s less useful for the day-to-day lag as munin will only be polling it every 5 minutes. A better way would be to use mk-heartbeat to get a more accurate moving average.

Suddenly, the web application we were working on stopped working. It wasn’t possible to log in.

We quickly narrowed it down to a clause in query which checked a users subscription was valid by checking its start and end dates. It looked bit like this:

SELECT foo FROM bar WHERE NOW() BETWEEN start AND end;

MySQL 5.0.22 returned rows, but 5.0.24 didn’t. After scratching our heads, I checked the manual:

For best results when using BETWEEN with date or time values, you should use CAST() to explicitly convert the values to the desired data type. Examples: If you compare a DATETIME to two DATE values, convert the DATE values to DATETIME values. If you use a string constant such as ‘2001-1-1′ in a comparison to a DATE, cast the string to a DATE.

The phrase “best results” make it sound like we’re baking a cake, and that your query results will be fluffier and more flavoursome if you use CAST! What they actually mean is, if you’re comparing different date types, you’re screwed if you don’t cast. You might get nothing.

Sure enough, our start and end columns were dates, and using cast in the query worked just fine:

SELECT foo FROM bar WHERE CAST(NOW() AS DATE)  BETWEEN start AND end;

I couldn’t find anything directly related to this change in behaviour in the changelogs, but hopefully this will help someone out there…