Other good use for slaves:
1. Testing MySQL version upgrade:
Upgrading the MySQL version on the slave is relatively safe. It may (though not necessarily) reflect any incompatibilities between your application and the new version. So if the slave upgraded, and replication continues without issues, it’s relatively safe to upgrade the master.

2. Testing index impact and performance:
To verify schema improvements, one can add/change indexing on tables on the slave, testing previous slow queries on the new schema. If successful, these changes can be propagated to the master as described.

3. I usually require more than one slave. In such cases where it is possible, a particular slave is marked as “a replacement for the master” in case of disaster. This particular slave has the exact same design and settings as the master.
The other slave, however, can be utilized for backups, may have more relaxed settings, etc.
This second slave may also be forced to lag behind the master (e.g. using maatkit’s mk-slave-delay) to also provide recovery in case of a “drop database” statement.

Using existing data in DML is also bad as you point out — but row-based replication has changed that problem.

As you point out, using the “replicate-do” and “replicate-ignore” statements have their problems. I think it’s particularly important to note that using “binlog-do” and “binlog-ignore” mean that you don’t log information that you may be required to (or you may want to).

In my opinion it’s better to log everything and just apply what you want, than to log selectively and apply everything.

There’s a lot to replication; this post was just meant to be a warning if people are using slaves for more than one purpose, they should make sure they’re not going to get stuck if they haven’t thought everything through.

For instance, filtering databases can cause problems when using cross-database updates (or updates without first running the “USE ” command). “INSERT|UPDATE … SELECT” can also cause problems.

For multi-master’s, it’s important to note that using auto_increment offsets won’t always save you if you send writes to both servers, such as when you might be using UNIQUE keys.

These limitations can generally be overcome, and, when they are, replication tends to work very well. Thought I’d put my $0.02 about them though since not everyone who might read this post might be thinking about them.