Scott Marlowe wrote:
I don't know, but someone in your organization seems to be.
Not just my organisation. I'm afraid this is an opinion I've seen in
many places.
Let me present it as a simple devil's choice, which would you rather
have, proven replication, that works, but requires you to setup a
secondary bit of software / system scripts (like rsync) but is tested
and proven to work, or, an "out of the box" solution that is untested,
unreliable, and possible unsafe for your data?
Why does an "out of the box" solution have to be untested, unreliable
and possibly unsafe for my data?
How about a third choice: you can also use a proven, reliable and tested
replication solution that is included in the core system because the
core system basiclly provides it anyway. It's easy to set up, but (as
with all replication solutions) doesn't fit all purposes.
Depending on my requirements, I may well choose that one.
Chosing a database because it has "out of the box" replication without
paying attention to how it is implemented, how well it works, and what
are the ways it can break is a recipe for (data) disaster.
Absolutely, but you're preaching to the converted here. I'm not
discussing which database I would choose. I was simply asking whether
the WAL logs would be utilised to create a simple replication solution
"Out of the box" with very little additional work on the part of the
developers.
I've tested slony, and I know that for what we use it for, it's a good
fit and it works well. I've tested MySQL's replication, and it simply
can't do what I need from a replication system. It can't be setup on
the fly on a live system with no down time, and it has reliability
issues that make it a poor choice for a 24/7 enterprise replication
system.
Again, I'm not asking whether MySQL's solution is any good or not. I'm
asking whether the WAL log could be used to provide a simple replication
solution out of the box. I am fully aware that no single replication
solution will fit all circumstances, but if PostgreSQL's core
functionality can provide one such solution anyway, why not add a couple
of scripts to make it all work out of the box and advertise the fact?
That said, it's a great system for content management replication, where
downtime is fine while setting up replication.
Precicely: one situation where this solution will work well, but nobody
knows about it because it's not pushed as a feature.
But I wouldn't choose either because it was easier to implement. Being
easy to implement is just sauce on the turkey. I need the meat to be
good or the sauce doesn't matter.
Indeed. As said above, it has to be reliable, tested etc. I personally
fear a lot of the things our MySQL databases do to our data, and would
very much like to make the switch to PostgreSQL if allowed to do so.
There may be problems with MySQL's 'out of the box' replication
solution, but that doesn't mean that having one at all is a Bad Thing.
I can't help but think that had I just asked about the possibility of
using the WAL log idea for an 'out of the box' replication solution
without mentioning the word 'MySQL', the responses received would have
been very different.
--
Russ
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
