Last week I read two books on Nagios. I found one easy to use and the other difficult.

Pro MySQL, by Mike Kruckenberg and Jay Pipes, covers advanced MySQL topics, especially focusing on optimization and internals. I give it a solid 4 stars.

By reader request, this article explains ways to remove duplicate rows when they are completely identical, and you don't have a primary key or other criterion to identify which rows to "save."

innotop 1.3.5 is the latest release of the increasingly popular MySQL and InnoDB monitor. I recommend everyone upgrade to this release. Aside from incomplete documentation, it's close to a stable 1.4 release (I'm counting on you to find the bugs!). There are many significant new features since version 1.3, which make it more powerful and easier to use.

In part 1 of this series I examined the behavior of MySQL's FEDERATED storage engine by running a bunch of queries with the general query log enabled on the remote server. In this article I take a higher-level view. I summarize my findings from the first article, then give my thoughts on the engine's strengths and weaknesses.

MySQL's FEDERATED storage engine is a fascinating example of the flexibility gained by abstracting the storage engine layer away from the rest of the server. FEDERATED tables allow you to access a table on another server as though it exists on the local server. However, the manual doesn't say much about how it really works. This article peeks under the hood of the FEDERATED storage engine.

MySQL has no built-in functionality to calculate a table's checksum in any storage engine but MyISAM. Table checksums can confirm that two tables are identical -- useful to verify a slave server is in sync with its master. Fortunately, it's easy to calculate a checksum on non-MyISAM tables with user variables. This technique works on any storage engine with any version of MySQL, doesn't require the BLACKHOLE storage engine, and avoids locks caused by INSERT... SELECT on InnoDB tables.

Late in 2006 MySQL decided to move to a split distribution model, Community and Enterprise. A lot has (apparently) changed since then, yet nothing has really changed since then.

MySQL statement-based replication is widely discussed, but I haven't seen much about how to design a replication setup for low downtime and easy administration. Statement-based replication has inherent shortcomings experienced MySQL users know to avoid, but rarely write about. This article explains how to avoid problems, help your slaves stay in sync with the master, and recover from disasters more quickly.

The amount of data out there via API's is increadible these days. For instance you can take an address, and get the latitude and longitude using Google's GeoCoding API.

I am using this API along with some others to build a pretty some interesting stuff (more on that when its public).

Today I needed to calculate the distance between two points, I found a bunch of formulas here to convert two lats and longs into miles. They had some more complicated formulas, but I went with an easier one because approximate accuracy was sufficent. Here's how the formula translated into SQL (tested on MySQL):

SELECT id, place_name,
ROUND( SQRT( POW((69.1 * (#Val(arguments.latitude)# - latitude)), 2) + POW((53 * (#Val(arguments.longitude)# - …