Re: WAL logs multiplexing? - Mailing list pgsql-general

From Dmitry Panov
Subject Re: WAL logs multiplexing?
Date
Msg-id 1135775218.6858.22.camel@ip6-localhost
Whole thread Raw
In response to Re: WAL logs multiplexing?  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: WAL logs multiplexing?
List pgsql-general
On Wed, 2005-12-28 at 13:38 +0100, Martijn van Oosterhout wrote:
> On Wed, Dec 28, 2005 at 03:17:40PM +0300, Dmitry Panov wrote:
> > I'm currently considering setting up online backup procedure and I
> > thought maybe it would be a useful feature if the online logs could be
> > written into more than one place (something like oracle redo logs
> > multiplexing).
> >
> > If I got it right if the server's filesystem crashes completely then the
> > changes that haven't gone into an archived log will be lost. If the logs
> > are written into more than one place the loss could be minimal.
>
> So you think PostgreSQL should reimplement something that RAID
> controllers already do better?
>
> These are reasons you have backups and PITR and other such things. I
> don't think having the server log to multiple places really gains you
> anything...
>

As long as the other location is at the same machine, I agree, RAID does
a better job. However it can be an NFS mounted directory and then it's a
totally different story.

I can think of at least to major advantages it provides:

1. There are situations when the filesystem is totally lost even if it's
RAID (broken power supply unit damages all the hard drives, plane hits
the building and so on...)

2. Even if the data can be recovered consider the time it takes: it's
usually much easier to switch to a hot standby instance than replacing
the broken RAID controller or other hardware).

In overall I think the feature could give significant improvement at
relatively low cost.

Best regards,
--
Dmitry O Panov          | mailto:dmitry@tsu.tula.ru
Tula State University   | Fidonet: Dmitry Panov, 2:5022/5.13
Dept. of CS & NIT       | http://www.tsu.tula.ru/



pgsql-general by date:

Previous
From: Vilen Tambovtsev
Date:
Subject: DB crash after disk full
Next
From: Grzegorz Tańczyk
Date:
Subject: Re: Automatic recovery process