From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Availability Options in 7.5 - PITR & Replication |
Date: | 2004-06-29 21:29:00 |
Message-ID: | 1088544539.3266.7625.camel@stromboli |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I'm rounding up last bits of Archive Recovery work now...
One of these is to give my humble opinion of where Archive Recovery fits
into the mix of options for PostgreSQL. This is effectively a
"positioning" of the high availability options.
Firstly, my experience comes from larger enterprises that have up to now
used Oracle and Db2 almost exclusively, with many new SQL Server systems
springing up and possibly a Teradata data warehouse as well.
Looking at, say, Oracle, we have these options:
- Crash Recovery
- Archive Recovery (in 6)
- Automated Standby Database (hand-coded in 7, an option in 8+)
- Replication (worked in 8+)
- Shared-Cache Clustering (only really worked from 9i+)
PostgreSQL now also sports these options:
- Crash Recovery (in 7.x already)
- Archive Recovery (subject to approval, in 7.5)
- Automated Standby Database (now possible, subject to approval)
- Replication (Slony-I)
...and so PostgreSQL has an almost matching set of options now, with an
almost matching development path.
The PostgreSQL options: Where do they fit?
Taking the last two options:
- Replication (Slony-I, etc)
This, I regard, as the premier Active-Active High Availability solution,
when you-absolutely-gotta-have-high-availability and can spend the time
to make sure its all working. [I have nothing bad to say about this,
just that it is overkill for some]
- Automated Standby Database (now possible, subject to approval)
ASD provides Active-Passive support.
This is a simpler, very low overhead mechanism for systems with lower
availability requirements, but where recovery time would be an issue.
This is a frequent choice for sites that do not wish to invest in
complex backup software or tape units etc.. This clearly not required
when replication is in use.
...and then discussing...
- Archive Recovery
provides a safer environment for important data, since changes can be
rolled forward through all kinds of system change, and allows you to
re-coordinate integrated systems when one (maybe not even you..)
crashes. This is regarded by most enterprises as the bottom line entry
point for trustworthy data servers, whatever they spend on hardware
replication, RAID or other stuff. All sites I have worked with have used
log archiving as well as Replication, when replication is used.
My thinking is that the full spread of options is as important as any
one option. Jan and his teams work is an important flagship for us all.
I welcome your comments and insight, whilst I neaten up the code..
Best regards, Simon Riggs
From | Date | Subject | |
---|---|---|---|
Next Message | Jeroen T. Vermeulen | 2004-06-29 21:31:05 | Re: Default libpq service |
Previous Message | Alvaro Herrera | 2004-06-29 20:56:06 | Re: Accessing Specific Schemas |