On Fri, Jan 18, 2008 at 04:09:45PM +0000, gordan@bobich.net wrote:
>
> That's just it - I don't think any user-land libraries would actually be
> required. One of supposed big advantages of MySQL is it's straightforward
> replication support. It's quite painful to see PostgreSQL suffer purely
> for the sake of lack of marketting in this department. :-(
The "straigtforward" replication support in MySQL is seriously broken. We
(by which I really mean "Jan") spent a great deal of time on the design of
Slony (and it's add-on nature is a feature, not a bug -- one thing it can do
is cross-version upgrades on PostgreSQL versions that were out before Slony
was finished being dfesigned) to avoid several nasty corner cases that are
sort of waved aside in the MySQL documentation. Designing a replication
system that works well 80% of the time is a waste of effort, because the
times when you really need it are all already in that 20% of cases that you
won't cover with the simple-minded solution.
Specifically,
> 1) That's what MySQL does (it either ignores errors or stops replication
> on encountering an error, which of those two it does is selectable, but
> that's about it).
That's got to be _the_ most brain-dead approach to replication I've ever
heard. It chooses the two least good of all possible worlds, and when you
get into your particular version of hell at 0-dark:30, you have to spend
some time first figuring out which hell you happen to be in.
In any case,
> fire and forget asynchronous replication a-la MySQL. Having a choice
> between transactions and speed is good. :-)
if this is what you believe, then you don't need a database to store your
data anyway. I can make your data system faster by storing all your data on
/dev/null. Writes will be very fast indeed.
A
