1. MySQL 5.0 supports auto-increment variables for bi-directional replication to avoid auto-increment collisions.
2. MySQL 5.0 replicates character sets and time zones.
3. 5.0 now replicates stored procedures, triggers and views.
4. MySQL 5.1 introduces row-based logging and replication (RBR)
5. Dyanmic switching of binary log format between ROW, STATEMENT and MIXED.
6. 5.1 allows for cluster replication.
7. Replication method cannot be configured per table, but since it’s dynamic you can change it from the client before a transaction, etc.
8. With auto_increment_offset and auto_increment_increment you can change starting points and how many you step between. Works with most table types. Works with InnoDB and MyISAM. This is specifically for multi-master setups.
9. RBR allows clusters to replicate and also allows the server to replicate non-deterministic statements such as LOAD_FILE(). That being said you can’t have different table definitions on the slave as you can with SBR.

Wow, nothing super impressive here that makes me excited about new features in MySQL’s 5.0/5.1 replication. Their answer to the possible auto_increment collisions seems a bit simplistic and short-sighted, but then again I’m not a maintainer for MySQL’s replication code.

What annoys me greatly is MySQL’s refusal to simply add features to storage engines in favor of simply adding new storage engines. MyISAM doesn’t support transactions or foreign key constraints? Use InnoDB. InnoDB doesn’t support FULLTEXT? Use MyISAM. You need synchronous replication of data? Use NDB, but you need to denormalize and reduce your use of JOIN’s.

It’s enough to make me switch to PostgreSQL.