Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > If it's not too complex for a short answer, could you or someone else share
> > thoughts on how PITR would facilitate async replication?
>
> PITR archives WAL changes. You could pass those to another server and
> re-execute those changes.
To expand on this:
Oracle calls this a warm standby database. It's primary intent is for having a
very rapid response to a critical hardware failure. You can bring up the
standby database and swap ip addresses within minutes. No time needed to
perform the restore.
How you get async replication from that is a bit of a clever hack. Since
Oracle 8 you could open the warm standby *in read-only* mode as a query
database. This was great for doing large batch job queries on a live OLTP
database. You could also do logical (pg_dump style) backups from that
database, or data exports destined for full scale DSS systems or other batch
processing.
I seem to recall one of the features promised in Oracle 9 was to be able to
open this database in read-write mode. I haven't worked with Oracle 9 so I
don't know if they actually delivered this or not. I assume that means having
read-only tablespaces to which you apply logs coming from the source database
while being able to do write operations on tables in separate non-synced
tablespaces. Still that sounds much more complicated, it sounds like it
requires segregating the logs for tablespaces.
However, being able to mount the warm standby as a read-only query database is
a real tempting low-hanging fruit. It means being able to protect your OLTP
database from large batch jobs interfering, while at the same time providing
the instantaneous holy grail in backup restore times.
--
greg
