Some disk array manufacturers had a problem with their writes in that
although the write the data was being stored in volatile memory instead
of on disk. The disk buffers were volatile in that if power suddenly
died all writes in memory that had not made it to disk were lost.
Lately most array manufacturers (at least those I have experience with
namely EMC & NetApp) have internal battery backup systems in place so
that in the event of a power failure the array will accept no new data,
but has sufficient battery power available to flush memory to a disk
drive cleanly before crashing. This makes the probability that you end
up with a corrupt database a whole lot lower. But there are still some
out there, names not to be mentioned, who do not provide this
functionality. Therefore buyer beware. Also with the advent of better
disk arrays I am not currently aware of any DBA's using Oracle's redo
mirroring. I've stopped using it in favor of EMC's disk mirrors or
Business Continuance Volumes (BCV's). Now when Oracle writes a redo log
file I really get three copies for the cost of one. Works just as well
on PostGreSQL WAL & database files. But of course having the ability to
force a wal file switch would be a real bennie. Hope it makes it into
8.1.
Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA
-----Original Message-----
From: Michael Kleiser [mailto:***@webde-ag.de]
Sent: Thursday, October 07, 2004 4:38 AM
To: ***@2ndquadrant.com
Cc: pgsql-***@postgresql.org
Subject: Re: [ADMIN] Multiple WALs for PITR ?
Post by Goulet, DickAs an Oracle DBA primarily, moving more towards PostGreSQL as time
passes, the "alter system switch logfile" command is very often used
at the end of a hot backup to force a logfile switch and consequently
provide a full archive log set. The command causes the database
engine to cease using the current online redo log and have it archived
to the archive log destination. This is the only way to be sure that
all required archive logs are present in a backup to reconstitute the
database at another location.
Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA
-----Original Message-----
Sent: Wednesday, October 06, 2004 5:36 PM
Subject: Re: [ADMIN] Multiple WALs for PITR ?
I wan`t to use Point in Time Recovery > I allread read >
http://developer.postgresql.org/docs/postgres/backup-online.html#BACKU
P-ARCHIVING-WAL
Good!
But I still wonder, if it is possible for PostgreSQL 8.0 to write
multiple, redundant WAL-Files like Oracles with its redo-log-groups
?
Post by Goulet, DickNot currently.
That was something I considered, though in the end lacked both
implementation time and justification for.
If you can explain why you think that might be necessary, I'd be happy
to consider it for v8.1.
RAID-10 seems a good solution for me...
I heared about some RAIDs saying "yes your data is on disk"
to the oracle-database, but it wasn't so.
So Oracle can't do a complete restore.
The solution was to store the redo-log-files (=WALS) to local attached
disk, but of course redundant on multiple disks.
But other oracle-dba use RAIDs to store the redo-logs with no problems.
Post by Goulet, DickIs threre an equivalent to Oracles "ALTER SYSTEM SWITCH LOGFILE" ?
Not currently.
Again, if you can say why we might want that, it can also be added -
other than "they have it, so we want it too" :-)
In the online-backup-strategie described in
http://developer.postgresql.org/docs/postgres/backup-online.html#BACKUP-
ARCHIVING-WAL
thre must be a special attention fir active WAL, if one want to backup
it also.
With "ALTER SYSTEM SWITCH LOGFILE" one could make it to a not active
WAL.
This would make it easier to backup it, especially if one want to use
backups-programms like amanda.
If there where multiple redundant WALs, one could compare them as a
consistency-check.
But this is only possible if nobody writes to the compared files.
Post by Goulet, DickThis is a likely addition for 8.1, since we will most likely want to
archive xlog files every N minutes, whatever the transaction rate,
allowing people to specify a maximum period of data loss - but this
seemed like an enhancement rather than a definite feature for 8.0
Great!
Regards
Michael Kleiser
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if
your
joining column's datatypes do not match
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ***@postgresql.org so that your
message can get through to the mailing list cleanly