Is it possible to do a full file system level backup of the data
directory, say once a week, and differentials or incrementals daily?
I'd love to be able to do this, but you can't do it usefully at a
file-system level. There's too much churn in the data files for even a
binary diff to be
Any movement on this? There is considerable interest in any known
issues resolving reproducible issues with postgres replication. Do
you happen to remember if set up the standby when the master was under
high load conditions? Any interesting/unexplained messages in the
standby logs?
I'm
have you had any power events? hard shutdowns, etc? I wonder if the problem
is in the clog files, and not the heap itself.
Nothing unusual for as long as I can tell. Reminder that as long as I
don't restart the primary's pg process, everything works fine
(secondary's data is intact).
It's
If you drop or truncate a table between the full and the incremental backup,
will that file be resurrected?
Such resurrected files will not disturb PostgreSQL, but if you keep them
around, you might end up with a lot of dead files if you have to restore a
couple of times.
That makes
Should replication cause corruption on the secondary when stopping/starting
the primary?
I wasn't aware 8.3 had any built in replication? what sort of replication
add-ons are you using?
Continuous archiving / WAL shipping as described in:
Is it possible to do a full file system level backup of the data
directory, say once a week, and differentials or incrementals daily?
I'm wondering if there are files that would normally be removed that a
restore: Full then diff/inc would not remove and perhaps
corrupt/confuse things.
Process:
Should replication cause corruption on the secondary when stopping/starting
the primary?
I wasn't aware 8.3 had any built in replication? what sort of replication
add-ons are you using?
Continuous archiving / WAL shipping as described in:
Should replication cause corruption on the secondary when stopping/starting
the primary? (pg 8.3.12, windows 2008 R2 on both servers)
No, it shouldn't. Any duplicate keys would represent a serious error.
It sounds like you're using warm standby, but when you say run
pg_start_backup() AFTER
Anyway, a better way for you would be to do a regular backup (with
pg_start_backup, copy and pg_stop_backup) and then use wal archive_command to
keep the xlogs between 2 full backups.
Thanks Julien. Can pg_start/stop_backup() be used for regular full
file system backups? All of the
Something about your setup is suspect. Disks perhaps.
Disk: Fusion IOdrive (1.2TB NAND drive)
I've read that one should set wal_sync_method=fsync_writethrough for
Windows servers. It's currently set to open_datasync, I have no idea
what effect that will have other than I've read less
The base backup necessary to initialize a warm standby server is a full file
system backup of the database, which can also be used for restores to any
point in time after the base backup is completed, assuming you also have all
the archived WAL files.
Thanks to both of you. I currently
nightly backup.
I'm doing something wrong Thanks for any help/pointers!
*-Bob Hatfield*
Reindex of triggered (slave) database showing errors.
We have replication working in 8.3.12 on two identical Windows 2008 R2
servers. Anytime I trigger the slave, it comes up fine and doing a reindex
of the slave database results in no errors. However, when I do this *after*
our nightly backup
13 matches
Mail list logo