Re: Multiple WALs for PITR ?

 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:mkl@webde-ag.de]
Sent: Thursday, October 07, 2004 4:38 AM
To: simon@2ndquadrant.com
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Multiple WALs for PITR ?



Goulet, Dick wrote:
> As 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-----
> From: simon@2ndquadrant.com [mailto:simon@2ndquadrant.com]
> Sent: Wednesday, October 06, 2004 5:36 PM
> To: mkl@webde-ag.de
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Multiple WALs for PITR ?
>
>
> Michael Kleiser <mkl@webde-ag.de> wrote on 06.10.2004, 16:29:08:
>  > 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
?
>
> Not 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.

>
>  >
>  > Is 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.

>
> This 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