Having dealt with many MySQL installations and, finally, a nice, internet-scale Postgres site, I can quite comfortably challenge the notion that MySQL has "grea

Having dealt with many MySQL installations and, finally, a nice, internet-scale Postgres site, I can quite comfortably challenge the notion that MySQL has "great" replication. It's certainly tough to beat for trivial topology or trivial database size, but, beyond that, MySQL statement-based replication is remarkably fragile. What's worse is, if a slave is far enough behind, it's possible that it will never catch up (hint: think about I/O contention with replication and whether it's possible to separate logs adequately). Once that happens, it's full dump time. Anything remotely fancy, like filtering out certain schemas (which MySQL calls "database," but it's really just a namespace), and a single developer discovering cross-schema UPDATEs, and That's All She Wrote. With Slony, after learning the admittedly bizarre administrative interface, everything was a dream. Swapping master and slave is fast and easy, even if there are other slaves out there. Full dump? Never heard of it! Certainly, slony does do the equivalent when bringing up a new slave, but the locking requirement is nowhere near as onerous, nor is the overall performance hit. Replication happens at the table level, not the whole database. The amount of time I've spent fixing broken MySQL replication easily dwarfs the amount of time I've spent learning and experimenting and fixing (after breaking on purpose, usually) Slony.