Greg Stark
"J. Andrew Rogers" <> writes:
I may be completely missing the point here, but it looks to
me as though
the PITR archival mechanism is also most of a native replication
facility. Is there anyone reason this couldn't be extended to
replication, and if so, is anyone planning on using it as such?

My memory is fuzzy on this point, but I seem to recall that this is
(was?) how replication is more-or-less done for many of the big
commercial RDBMS.
You're is the basis of a log shipping replication facility.
I'm keen no to get too far ahead of ourselves. Let's eat the mammoth one
bite at a time....or one patch at a time.
Well "replication" is one of those things that means
different things to
different people. IMHO, this is one of the simpler, more
reliable, mechanisms
and would be nice to have. And you're right that it shouldn't
require much
more work, in fact it's probably easier than a lot of other
cases that PITR
I agree. PITR is intended initially as a recovery mechanism. Replication
has other purposes as well, such as locating data close to where it is
required (in master-multi-slave replication scenarios), which is
certainly not an objective or even a likely end point of the PITR work.
The PostgreSQL community is lucky enough to have some very competent
people working on those other approaches and I would recommend everybody
checks out that work.
For a long time Oracle has supported this mechanism for
running warm standby
databases. Basically you maintain a second database and every
time an archived
log is finished you ship it over and immediately "restore" it
on the standby
machine. Whenever you have a failure you can quickly fail
over to the standby
database which is all ready to go and up-to-date within
minutes of your
This facility is one of the intended features, if all goes well. But it
is an advanced feature, not the bread and butter.
Since 8i Oracle has also supported a more advanced version
where you can open
the standby database in read-only mode.
This mode requires more thought, but is certainly possible, in time.

Best Regards

Simon Riggs

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 20 of 20 | next ›
Discussion Overview
grouppgsql-hackers @
postedMar 30, '04 at 9:18p
activeApr 2, '04 at 6:56p



site design / logo © 2021 Grokbase