[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-performance
Subject:    Re: [PERFORM] Write performance
From:       Scott Carey <scott () richrelevance ! com>
Date:       2010-06-25 17:30:06
Message-ID: 590C5896-DA69-451C-8138-831422140F59 () richrelevance ! com
[Download RAW message or body]


On Jun 24, 2010, at 6:16 AM, Janning wrote:

> On Thursday 24 June 2010 14:53:57 Matthew Wakeling wrote:
> > On Thu, 24 Jun 2010, Janning wrote:
> > > We have a 12 GB RAM machine with intel i7-975 and using
> > > 3 disks "Seagate Barracuda 7200.11, ST31500341AS (1.5 GB)"
> > 
> > Those discs are 1.5TB, not 1.5GB.
> 
> sorry, my fault.
> 
> > > One disk for the system and WAL etc. and one SW RAID-0 with two disks for
> > > postgresql data. Our database is about 24GB.
> > 
> > Beware of RAID-0 - make sure you can recover the data when (not if) a disc
> > fails.
> 
> oh sorry again, its a raid-1 of course. shame on me.

If your WAL is not on RAID but your data is, you will lose data if the WAL log drive \
dies.  You will then have a difficult time recovering data from the data drives even \
though they are RAID protected.  Most likely indexes and some data will be corrupted \
since the last checkpoint.   I have lost a WAL before, and the result was a lot of \
corrupted system indexes that had to be rebuilt in single user mode, and one system \
table (stats related) that had to be purged and regenerated from scratch.  This was \
not fun.  Most of the data was fine, but the cleanup is messy if you lose WAL, and \
there is no guarantee that your data is safe if you don't have the WAL available.



-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


[prev in list] [next in list] [prev in thread] [next in thread]