Hannu Krosing
Josh Berkus kirjutas T, 09.03.2004 kell 19:46:
In my personal experience, the *primary* use of PITR is recovery
from
User
Error. For example, with one SQL Server 7.0 installation for a law
firm,
I've made use of PITR 4 times over the last 4 years: once was
because
and HDD
On Tuesday 09 March 2004 17:38, Simon Riggs wrote:
Richard Huxton
On Monday 08 March 2004 23:28, Simon Riggs wrote:
PITR Functional Design v2 for 7.5
Review of current Crash Recovery
Is there any value in putting this section on techdocs or similar? We
do
get a
small but
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
When I'm doing a file level hot backup, I can't be sure about the backup
order. To be sure the cluster is in a consistent state regarding
checkpoints, pg_clog must be the first directory backed up.
You are going off in the wrong
Andreas Pflug [EMAIL PROTECTED] writes:
To clarify:
I'd expect a cluster to be workable, if I
- disable VACUUM until backup completed
- issue CHECKPOINT
- backup clog (CHECKPOINT and backup clog are the backup checkpoint)
- backup all datafiles (which include at least all completed
Josh Berkus [mailto:[EMAIL PROTECTED]
wal_archive_policy and enable/disable archiving accordingly. This
parameter can only be changed at server start. (This is required
because
the initial step of archiving each xlog is performed by the backend;
if
this were changeable after boot, then it
From: Josh Berkus [mailto:[EMAIL PROTECTED]
SIGHUP - seems to allow different parameter settings in each backend
Nope. SIGHUP means that you need to send a HUP to the postmaster,
such
as
you would with changes to pg_hba.conf.
SUSET - maybe what you're looking for???
Yes.
The only way we can support file-level hot backup is in conjunction with
PITR-style WAL log archiving. It is okay for the data area dump to be
inconsistent, so long as your recovery process includes replay of WAL
starting at some checkpoint before the filesystem dump started, and
extending
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
Why is that a useful approach? You might as well shut down the
postmaster and do a cold filesystem backup,
We're talking about *hot* backup, aren't we?
Exactly. The approach you're sketching can't work for hot backup,
because it
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
Why is that a useful approach? You might as well shut down the
postmaster and do a cold filesystem backup,
We're talking about *hot* backup, aren't we?
Exactly. The approach you're sketching can't work
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
To clarify:
I'd expect a cluster to be workable, if I
- disable VACUUM until backup completed
- issue CHECKPOINT
- backup clog (CHECKPOINT and backup clog are the backup checkpoint)
- backup all datafiles (which include at least all
To clarify:
I'd expect a cluster to be workable, if I
- disable VACUUM until backup completed
- issue CHECKPOINT
- backup clog (CHECKPOINT and backup clog are the backup checkpoint)
- backup all datafiles (which include at least all completed transaction
data at checkpoint time)
Josh Berkus kirjutas T, 09.03.2004 kell 19:46:
In my personal experience, the *primary* use of PITR is recovery from User
Error. For example, with one SQL Server 7.0 installation for a law firm,
I've made use of PITR 4 times over the last 4 years: once was because and HDD
failed, the
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
What I think is possible is the following (continuous backup of WAL assumed):
- disable VACUUM
- issue CHECKPOINT C1
- backup all files
- reenable VACUUM
- restore files
- adapt pg_control (checkpoint C1)
- recover WAL until at least end
On Monday 08 March 2004 23:28, Simon Riggs wrote:
PITR Functional Design v2 for 7.5
Blimey - that's a long post :-) Thanks for explaining things simply enough
that a non-hacker like me can understand. Well - almost understand ;-)
Review of current Crash Recovery
Is there any value in putting
Simon,
First off, let me compliment you on such a thourough proposal. I'm feeling
very enthusiastic about 7.5 PITR based on the amount of thought you've given
the project.
Based on throuroughness, I wanted to make a few comments and suggestions.
All of the below are in the category of
Josh Berkus wrote:
5) Full back-up
Related to the above, what I don't see in your paper or the proposed API is a
way to coordinate full back-ups and WAL archiving. Obviously, the PITR
Archive is only useful in reference to an existing full backup, so it is
important to be able to associate
Andreas Pflug
Josh Berkus wrote:
Related to the above, what I don't see in your paper or the proposed
API
is a
way to coordinate full back-ups and WAL archiving. Obviously, the
PITR
Archive is only useful in reference to an existing full backup, so it
is
important to be able to associate a
Simon,
SIGHUP - seems to allow different parameter settings in each backend
Nope. SIGHUP means that you need to send a HUP to the postmaster, such as
you would with changes to pg_hba.conf.
SUSET - maybe what you're looking for???
Yes. This means that it can be changed, at runtime,
Richard Huxton
On Monday 08 March 2004 23:28, Simon Riggs wrote:
PITR Functional Design v2 for 7.5
Review of current Crash Recovery
Is there any value in putting this section on techdocs or similar? We
do
get a
small but steady trickle of people asking for details on internals,
and I
Josh Berkus [mailto:[EMAIL PROTECTED]
First off, let me compliment you on such a thorough proposal. I'm
feeling very enthusiastic about 7.5 PITR
Thank you, though please realise that I am in many ways summarising a
wide range of suggestions and earlier work into a coherent whole.
Me too! I'm
PITR Functional Design v2 for 7.5
[EMAIL PROTECTED]
Currently, PostgreSQL provides Crash Recovery but not yet full Point In
Time
Recovery (PITR). The following document provides a design which enhances
the existing robustness features to include full PITR. Since one of the
primary objectives for
21 matches
Mail list logo
