MySQL has had years to evolve their approach and to fix bugs.
That sounds nice in theory, but completely ignores the reality of the respective code-bases. Features in MySQL have a tendency to rot rather than mature. It could hardly become more obvious than in the comparison between this version 1 of postgres replication against the "evolved" MySQL equivalent.
Postgres may have the smaller feature set, it may be the first version, yet I'm still inclined to trust it a lot more than what MySQL has to offer.
Simply because postgres has a track-record of being rock solid and MySQL, well, not so much.
Sure, in theory you can build fancy rings, cascades and even multi-master topologies in MySQL. But what is that worth when even the simplest master/slave mode still randomly and silently desyncs in various, undocumented situations?
Statement based replication has its faults, but complexity isn't one of them.
There's a nice quote from Alan Perlis:
Fools ignore complexity,
experts avoid it;
geniuses remove it.
Some complexity is inherent to replication. The question remains which parts, if any, they removed and which parts they ignored...
It's not a joke. There is more documentation.
Sorry, measuring documentation in terms of quantity sounds like yet another joke to me. As you can tell by my snarky comments I'm responsible for babysitting the odd MySQL cluster in my day-job (and postgres, too, so I have a frame of reference). It is indeed true that for most common problems I'll find the solution not in the official docs but rather on some more or less obscure forum, in broken english, linked from page >3 of the google search results (after 2 pages of outdated and plain wrong information).
So, in all fairness, yes, most common problems can eventually be solved that way. But good luck debugging a not so common ring, multi-master or otherwise non-standard scenario that way. Or encoding issues. Or silent truncation. Or hotbackups that are strangely much smaller than they should be. Or the dreaded 'mysql'-database being screwed after restoring a backup to a newer minor-version...
Anyways, the way postgres handles this seems more sensible to me. In postgres the overwhelming majority of the "common" MySQL-issues simply doesn't exist.
Do you have any experience with MySQL replication? I do, and mine aligns with what moe is describing. Nice in theory isn't worth much if it's crappy in reality.
Yes. Over the last five years I've supported replication on hundreds of servers, powering sites you've probably used. I've had to clean up after crashes with unsynched binlogs, writes that completed partially on master, corrupted relay logs, failed hubs, and endless inconsistencies for a myriad of reasons.
Guess what, things have gotten incrementally better and continue to improve. Bugs get found and fixed. MySQL replication is mature enough to power huge sites like Twitter, Facebook, and countless others. There has been exactly one PostgreSQL release that supports replication suitable for read scaling.
I measure stability by how well something works, not by how many releases it has had. MySQL replication is getting better, but it does still have major problems. Sure, it's good enough to power huge sites (we use it here as well), but it's frustrating to deal with. Fortunately it's being used by web 2.0 companies and not banks, so generally if a slave is corrupted and returns weird results, customers aren't going to be too upset and in a lot of cases might not even notice, but it's still an annoying problem to deal with. I wonder how many more releases it's going to take for them to get it solid.
That sounds nice in theory, but completely ignores the reality of the respective code-bases. Features in MySQL have a tendency to rot rather than mature. It could hardly become more obvious than in the comparison between this version 1 of postgres replication against the "evolved" MySQL equivalent.
Postgres may have the smaller feature set, it may be the first version, yet I'm still inclined to trust it a lot more than what MySQL has to offer. Simply because postgres has a track-record of being rock solid and MySQL, well, not so much.
Sure, in theory you can build fancy rings, cascades and even multi-master topologies in MySQL. But what is that worth when even the simplest master/slave mode still randomly and silently desyncs in various, undocumented situations?
Statement based replication has its faults, but complexity isn't one of them.
There's a nice quote from Alan Perlis:
Some complexity is inherent to replication. The question remains which parts, if any, they removed and which parts they ignored...It's not a joke. There is more documentation.
Sorry, measuring documentation in terms of quantity sounds like yet another joke to me. As you can tell by my snarky comments I'm responsible for babysitting the odd MySQL cluster in my day-job (and postgres, too, so I have a frame of reference). It is indeed true that for most common problems I'll find the solution not in the official docs but rather on some more or less obscure forum, in broken english, linked from page >3 of the google search results (after 2 pages of outdated and plain wrong information).
So, in all fairness, yes, most common problems can eventually be solved that way. But good luck debugging a not so common ring, multi-master or otherwise non-standard scenario that way. Or encoding issues. Or silent truncation. Or hotbackups that are strangely much smaller than they should be. Or the dreaded 'mysql'-database being screwed after restoring a backup to a newer minor-version...
Anyways, the way postgres handles this seems more sensible to me. In postgres the overwhelming majority of the "common" MySQL-issues simply doesn't exist.