From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Greg Stark" <gsstark(at)mit(dot)edu>, <pgsql-hackers(at)postgresql(dot)org>, "J(dot) Andrew Rogers" <jrogers(at)neopolitan(dot)com> |
Subject: | Re: PITR for replication? |
Date: | 2004-04-02 18:57:41 |
Message-ID: | KGEFLMPJFBNNLNOOOPLGGEGACHAA.simon@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy pgsql-hackers pgsql-hackers-pitr |
> Greg Stark
> "J. Andrew Rogers" <jrogers(at)neopolitan(dot)com> 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 right...it 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
> requires.
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
> failure.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Payne | 2004-04-02 20:35:50 | Re: Aberdeen Study on OS RDBMS: exceprts and |
Previous Message | Tom Lane | 2004-04-02 17:47:56 | Re: [SQL] SQL Spec Compliance Questions |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-04-02 19:28:02 | Re: Better support for whole-row operations and composite types |
Previous Message | Alvaro Herrera | 2004-04-02 18:40:01 | Re: PITR for replication? |
From | Date | Subject | |
---|---|---|---|
Next Message | spock | 2004-06-30 15:26:16 | Ongoing activity/Status of this project |
Previous Message | Greg Stark | 2004-04-02 04:33:23 | Re: PITR for replication? |