On Sep 2, 2006, at 7:32 AM, Marc Evans wrote:
Hello -
I am curious as to people's opinion about best practices in
deployment of pgsql in a high-availablity (HA) situation. By HA I
mean that data loss must be as close to zero as possible, and that
web servers using the DB need to be deployed in multiple geographic
locations world-wide, to provide for network availability.
My best practice would be "Don't". If you're supporting arbitrary SQL
operations you can't get to zero data loss with asynchronous
replication, and you can't get good performance with synchronous
replication.
Replication at the application level (where that application code may
be embedded in the db, but may not) where you have an understanding
of what data changes your system supports is much saner than trying
to rely on a replication engine that has to support asynchronous
multi-master replication of arbitrary SQL (I'd probably argue that no
such thing exists, but that's another story).
In my mind, this suggests a need for a multi-master configuration,
such as that which can be achieved with pgcluster. I see redundency
both within a POP, as well as cross-POP. I am however concerned
about the latency implied by POP locations (let's assume a POP in
the EU, US and JP).
Multi-master is even worse. I've worked with big, international
master-master replicated database (under Oracle rather than PG) and
even though they were fairly low update traffic I hope to never, ever
do that again.
I am aware of bizgress, though am concerned that it doesn't really
address the wide-area replication issue. It does address the HA
aspect within a single POP quite nicely though.
How do you deal with this, commerical or OSS?
At the system architecture, or application levels. Not by layering a
non-replication aware application on top of a general purpose SQL
replication engine.
You can do it by using an off-the-shelf replication engine, of
course. There are a number of products out there that prove that. But
operationally you'll regret it.
Cheers,
Steve
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
