Shahaf Abileah <shahaf at redfin.com> writes:
> I ended up using a different approach...
>
> 1. I created a table called replication_heartbeat that has two columns:
> id, last_modified
> 2. I added this table to the replication set
> 3. I pre-populated a single row into this table
> 4. I set up a cron job on the master that executes the following query
> once a minute: update replication_heartbeat set last_modified=now()
> 5. I created Nagios alerts on both the master and the slaves that checks
> this date.  On the master if the date goes stale then I know that
> something is wrong with the update command in cron.  On the slaves if
> the date is stale then I know something is wrong with replication.
>
> It's a poor man's approach and it's probably silly to do all this work
> when there's a built-in mechanism.  The main advantage is that it's dead
> simple to understand.

There's an advantage to each way:

a) With sl_status, you can easily hook up tools like MRTG to graph how
far behind replication tends to be.  Also, it adds NO extra
replication work.

b) The heartbeat actually tests an aspect of the end-to-end
functioning of the database as application platform.

They are both legitimate approaches.
-- 
select 'cbbrowne' || '@' || 'linuxfinances.info';
http://cbbrowne.com/info/lsf.html
Rules  of the  Evil Overlord  #145. "My  dungeon cell  decor  will not
feature exposed pipes.  While they add to the  gloomy atmosphere, they
are good  conductors of vibrations and  a lot of  prisoners know Morse
code." <http://www.eviloverlord.com/>