pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedHow to allocate 8 disks
14+ messages / 8 participants
[nested] [flat]
* How to allocate 8 disks
@ 2008-03-01 18:06 Craig James <craig_james@emolecules.com>
0 siblings, 2 replies; 14+ messages in thread
From: Craig James @ 2008-03-01 18:06 UTC (permalink / raw)
To: pgsql-performance
We're upgrading to a medium-sized server, a Dell PowerEdge 2950, dual-quad CPU's and 8 GB memory. This box can hold at most 8 disks (10K SCSI 2.5" 146 GB drives) and has Dell's Perc 6/i RAID controller.
I'm thinking of this:
6 disks RAID 1+0 Postgres data
1 disk WAL
1 disk Linux
I've often seen RAID 1 recommended for the WAL. Is that strictly for reliability, or is there a performance advantage to RAID 1 for the WAL?
It seems to me separating the OS and WAL on two disks is better than making a single RAID 1 and sharing it, from a performance point of view.
Thanks,
Craig
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: How to allocate 8 disks
@ 2008-03-01 18:47 Scott Marlowe <scott.marlowe@gmail.com>
parent: Craig James <craig_james@emolecules.com>
1 sibling, 0 replies; 14+ messages in thread
From: Scott Marlowe @ 2008-03-01 18:47 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: pgsql-performance
On Sat, Mar 1, 2008 at 12:06 PM, Craig James <craig_james@emolecules.com> wrote:
> We're upgrading to a medium-sized server, a Dell PowerEdge 2950, dual-quad CPU's and 8 GB memory. This box can hold at most 8 disks (10K SCSI 2.5" 146 GB drives) and has Dell's Perc 6/i RAID controller.
>
> I'm thinking of this:
>
> 6 disks RAID 1+0 Postgres data
> 1 disk WAL
> 1 disk Linux
>
> I've often seen RAID 1 recommended for the WAL. Is that strictly for reliability, or is there a performance advantage to RAID 1 for the WAL?
>
> It seems to me separating the OS and WAL on two disks is better than making a single RAID 1 and sharing it, from a performance point of view.
It's a trade off. Remember that if the single disk hold xlog fails
you've just quite possubly lost your database. I'd be inclined to
either using a RAID-1 of two disks for the OS and xlog, and having
pgsql log to the 6 disk RAID-10 instead of the OS / xlog disk set.
More important, do you have battery backed cache on the controller? A
good controller with a battery backed cache can usually outrun a
larger array with no write cache when it comes to transactions /
writing to the disks.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: How to allocate 8 disks
@ 2008-03-01 21:03 Joshua D. Drake <jd@commandprompt.com>
parent: Craig James <craig_james@emolecules.com>
1 sibling, 2 replies; 14+ messages in thread
From: Joshua D. Drake @ 2008-03-01 21:03 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: pgsql-performance
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 01 Mar 2008 10:06:54 -0800
Craig James <craig_james@emolecules.com> wrote:
> We're upgrading to a medium-sized server, a Dell PowerEdge 2950,
> dual-quad CPU's and 8 GB memory. This box can hold at most 8 disks
> (10K SCSI 2.5" 146 GB drives) and has Dell's Perc 6/i RAID controller.
>
> I'm thinking of this:
>
> 6 disks RAID 1+0 Postgres data
> 1 disk WAL
> 1 disk Linux
>
> I've often seen RAID 1 recommended for the WAL. Is that strictly for
> reliability, or is there a performance advantage to RAID 1 for the
> WAL?
>
> It seems to me separating the OS and WAL on two disks is better than
> making a single RAID 1 and sharing it, from a performance point of
> view.
This scares me... You lose WAL you are a goner. Combine your OS and
WAL into a RAID 1.
Sincerely,
Joshua D. Drake
- --
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHycSzATb/zqfZUUQRAs14AJ9pm3huW+z1j7jUIY7FbIZMzz2IxgCgnOhD
yWiDabTYAG+x12JEqrf4q8E=
=gBPs
-----END PGP SIGNATURE-----
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: How to allocate 8 disks
@ 2008-03-01 21:53 Craig James <craig_james@emolecules.com>
parent: Joshua D. Drake <jd@commandprompt.com>
1 sibling, 3 replies; 14+ messages in thread
From: Craig James @ 2008-03-01 21:53 UTC (permalink / raw)
To: Joshua D. Drake <jd@commandprompt.com>; +Cc: pgsql-performance
Joshua D. Drake wrote:
> On Sat, 01 Mar 2008 10:06:54 -0800
> Craig James <craig_james@emolecules.com> wrote:
>
>> We're upgrading to a medium-sized server, a Dell PowerEdge 2950,
>> dual-quad CPU's and 8 GB memory. This box can hold at most 8 disks
>> (10K SCSI 2.5" 146 GB drives) and has Dell's Perc 6/i RAID controller.
>>
>> I'm thinking of this:
>>
>> 6 disks RAID 1+0 Postgres data
>> 1 disk WAL
>> 1 disk Linux
>>
>> I've often seen RAID 1 recommended for the WAL. Is that strictly for
>> reliability, or is there a performance advantage to RAID 1 for the
>> WAL?
>>
>> It seems to me separating the OS and WAL on two disks is better than
>> making a single RAID 1 and sharing it, from a performance point of
>> view.
>
> This scares me... You lose WAL you are a goner. Combine your OS and
> WAL into a RAID 1.
Right, I do understand that, but reliability is not a top priority in this system. The database will be replicated, and can be reproduced from the raw data. It's not an accounting system, it finds scientific results. That's not to say I *won't* take your advice, we may in fact combine the OS and WAL on one disk. Reliability is a good thing, but I need to know all of the tradeoffs, so that I can weigh performance, reliability, and cost and make the right choice.
So my question still stands: From a strictly performance point of view, would it be better to separate the OS and the WAL onto two disks? Is there any performance advantage to RAID 1? My understanding is that RAID 1 can give 2x seek performance during read, but no advantage during write. For the WAL, it seems to me that RAID 1 has no performance benefits, so separating the WAL and OS seems like a peformance advantage.
Another option would be:
4 disks RAID 1+0 Postgres data
2 disks RAID 1 WAL
1 disk Linux
1 disk spare
This would give us reliability, but I think the performance would be considerably worse, since the primary Postgres data would come from 4 disks instead of six.
I guess we could also consider:
4 disks RAID 1+0 Postgres data
4 disks RAID 1+0 WAL and Linux
Or even
8 disks RAID 1+0 Everything
This is a dedicated system and does nothing but Apache/Postgres, so the OS should get very little traffic. But if that's the case, I guess you could argue that your suggestion of combining OS and WAL on a 2-disk RAID 1 would be the way to go, since the OS activity wouldn't affect the WAL very much.
I suppose the thing to do is get the system, and run bonnie on various configurations. I've never run bonnie before -- can I get some useful results without a huge learning curve?
Thanks,
Craig
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: How to allocate 8 disks
@ 2008-03-01 22:30 Scott Marlowe <scott.marlowe@gmail.com>
parent: Craig James <craig_james@emolecules.com>
2 siblings, 0 replies; 14+ messages in thread
From: Scott Marlowe @ 2008-03-01 22:30 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: Joshua D. Drake <jd@commandprompt.com>; pgsql-performance
On Sat, Mar 1, 2008 at 3:53 PM, Craig James <craig_james@emolecules.com> wrote:
> Joshua D. Drake wrote:
> > On Sat, 01 Mar 2008 10:06:54 -0800
> > Craig James <craig_james@emolecules.com> wrote:
> >
> >> We're upgrading to a medium-sized server, a Dell PowerEdge 2950,
> >> dual-quad CPU's and 8 GB memory. This box can hold at most 8 disks
> >> (10K SCSI 2.5" 146 GB drives) and has Dell's Perc 6/i RAID controller.
> >>
> >> I'm thinking of this:
> >>
> >> 6 disks RAID 1+0 Postgres data
> >> 1 disk WAL
> >> 1 disk Linux
> >>
> >> I've often seen RAID 1 recommended for the WAL. Is that strictly for
> >> reliability, or is there a performance advantage to RAID 1 for the
> >> WAL?
> >>
> >> It seems to me separating the OS and WAL on two disks is better than
> >> making a single RAID 1 and sharing it, from a performance point of
> >> view.
> >
> > This scares me... You lose WAL you are a goner. Combine your OS and
> > WAL into a RAID 1.
>
> Right, I do understand that, but reliability is not a top priority in this system. The database will be replicated, and can be reproduced from the raw data. It's not an accounting system, it finds scientific results. That's not to say I *won't* take your advice, we may in fact combine the OS and WAL on one disk. Reliability is a good thing, but I need to know all of the tradeoffs, so that I can weigh performance, reliability, and cost and make the right choice.
In that case you could always make the data partition a 6 disk RAID-0.
> So my question still stands: From a strictly performance point of view, would it be better to separate the OS and the WAL onto two disks? Is there any performance advantage to RAID 1? My understanding is that RAID 1 can give 2x seek performance during read, but no advantage during write. For the WAL, it seems to me that RAID 1 has no performance benefits, so separating the WAL and OS seems like a peformance advantage.
Yes, Only on Reads. Correct.
> Another option would be:
>
>
> 4 disks RAID 1+0 Postgres data
> 2 disks RAID 1 WAL
> 1 disk Linux
> 1 disk spare
>
> This would give us reliability, but I think the performance would be considerably worse, since the primary Postgres data would come from 4 disks instead of six.
Performance-wise, RAID-10 with n disks is about the same as RAID-0
with n/2 disks. So, you're losing abot 1/3 of your peak performance,
assuming 100% efficient controllers and you aren't bottlenecking I/O
with > 4 disks.
> I guess we could also consider:
>
>
> 4 disks RAID 1+0 Postgres data
> 4 disks RAID 1+0 WAL and Linux
>
> Or even
>
> 8 disks RAID 1+0 Everything
It really depends on the controller. Battery backed write cache?
Then the one big everything is often faster than any other method. No
BB cache? Then splitting them up will help.
> I suppose the thing to do is get the system, and run bonnie on various configurations. I've never run bonnie before -- can I get some useful results without a huge learning curve?
Yes, it's fairly easy to drive. It'll tell you more about your
controller than anything else, which is very useful information. The
way a different controllers behaves with different configurations can
be very very different from one controller to the next.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: How to allocate 8 disks
@ 2008-03-02 04:51 Greg Smith <gsmith@gregsmith.com>
parent: Craig James <craig_james@emolecules.com>
2 siblings, 0 replies; 14+ messages in thread
From: Greg Smith @ 2008-03-02 04:51 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: pgsql-performance
On Sat, 1 Mar 2008, Craig James wrote:
> So my question still stands: From a strictly performance point of view, would
> it be better to separate the OS and the WAL onto two disks?
You're not getting a more useful answer here because you haven't mentioned
yet a) what the disk controller is or b) how much writing activity is
going on here. If you can cache writes, most of the advantages to having
a seperate WAL disk aren't important unless you've got an extremely high
write throughput (higher you can likely sustain with only 8 disks) so you
can put the WAL data just about anywhere.
> This is a dedicated system and does nothing but Apache/Postgres, so the OS
> should get very little traffic. But if that's the case, I guess you could
> argue that your suggestion of combining OS and WAL on a 2-disk RAID 1 would
> be the way to go, since the OS activity wouldn't affect the WAL very much.
The main thing to watch out for if the OS and WAL are on the same disk is
that some random process spewing logs files could fill the disk and now
the database is stalled.
I think there are two configurations that make sense for your situation:
> 8 disks RAID 1+0 Everything
This maximizes potential sequential and seek throughput for the database,
which is probably going to be your bottleneck unless you're writing lots
of simple data, while still allowing survival of any one disk. The crazy
log situation I mentioned above is less likely to be a problem because
having so much more disk space available to everything means it's more
likely you'll notice it before the disk actually fills.
6 disks RAID 0 Postgres data+WAL
2 disks RAID 1 Linux
This puts some redundancy on the base OS, so no single disk loss can
actually take down the system altogether. You get maximum throughput on
the database. If you lose a database disk, you replace it and rebuild the
whole database at that point.
> I suppose the thing to do is get the system, and run bonnie on various
> configurations. I've never run bonnie before -- can I get some useful
> results without a huge learning curve?
I've collected some bonnie++ examples at
http://www.westnet.com/~gsmith/content/postgresql/pg-disktesting.htm you
may find useful. With only 8 disks you should be able to get useful
results without a learning curve; with significantly more it can be
necessary to run more than one bonnie at once to really saturate the disks
and that's trickier.
I don't think you're going to learn anything useful from that though
(other than figuring out if your disk+controller combination is
fundamentally fast or not). As you put more disks into the array,
sequential throughput and seeks/second will go up. This doesn't tell you
anything useful about whether the WAL is going to get enough traffic to be
a bottleneck such that it needs to be on a seperate disk. To figure that
out, you need to run some simulations of the real database and its
application, and doing that fairly is a more serious benchmarking project.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: How to allocate 8 disks
@ 2008-03-03 12:11 Matthew <matthew@flymine.org>
parent: Craig James <craig_james@emolecules.com>
2 siblings, 2 replies; 14+ messages in thread
From: Matthew @ 2008-03-03 12:11 UTC (permalink / raw)
To: pgsql-performance
On Sat, 1 Mar 2008, Craig James wrote:
> Right, I do understand that, but reliability is not a top priority in this
> system. The database will be replicated, and can be reproduced from the raw
> data.
So what you're saying is:
1. Reliability is not important.
2. There's zero write traffic once the database is set up.
If this is true, then RAID-0 is the way to go. I think Greg's options are
good. Either:
2 discs RAID 1: OS
6 discs RAID 0: database + WAL
which is what we're using here (except with more discs), or:
8 discs RAID 10: everything
However, if reliability *really* isn't an issue, and you can accept
reinstalling the system if you lose a disc, then there's a third option:
8 discs RAID 0: Everything
Matthew
--
Heat is work, and work's a curse. All the heat in the universe, it's
going to cool down, because it can't increase, then there'll be no
more work, and there'll be perfect peace. -- Michael Flanders
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: How to allocate 8 disks
@ 2008-03-03 14:48 Mark Mielke <mark@mark.mielke.cc>
parent: Matthew <matthew@flymine.org>
1 sibling, 2 replies; 14+ messages in thread
From: Mark Mielke @ 2008-03-03 14:48 UTC (permalink / raw)
To: Matthew <matthew@flymine.org>; +Cc: pgsql-performance
Matthew wrote:
> On Sat, 1 Mar 2008, Craig James wrote:
>> Right, I do understand that, but reliability is not a top priority in
>> this system. The database will be replicated, and can be reproduced
>> from the raw data.
>
> So what you're saying is:
>
> 1. Reliability is not important.
> 2. There's zero write traffic once the database is set up.
>
> If this is true, then RAID-0 is the way to go. I think Greg's options
> are good. Either:
>
> 2 discs RAID 1: OS
> 6 discs RAID 0: database + WAL
>
> which is what we're using here (except with more discs), or:
>
> 8 discs RAID 10: everything
Has anybody been able to prove to themselves that RAID 0 vs RAID 1+0 is
faster for these sorts of loads? My understanding is that RAID 1+0 *can*
reduce latency for reads, but that it relies on random access, whereas
RAID 0 performs best for sequential scans? Does PostgreSQL ever do
enough random access to make RAID 1+0 shine?
Curious.
Thanks,
mark
--
Mark Mielke <mark@mielke.cc>
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: How to allocate 8 disks
@ 2008-03-03 14:53 Craig James <craig_james@emolecules.com>
parent: Matthew <matthew@flymine.org>
1 sibling, 0 replies; 14+ messages in thread
From: Craig James @ 2008-03-03 14:53 UTC (permalink / raw)
To: Matthew <matthew@flymine.org>; +Cc: pgsql-performance
Matthew wrote:
> On Sat, 1 Mar 2008, Craig James wrote:
>> Right, I do understand that, but reliability is not a top priority in
>> this system. The database will be replicated, and can be reproduced
>> from the raw data.
>
> So what you're saying is:
>
> 1. Reliability is not important.
> 2. There's zero write traffic once the database is set up.
Well, I actually didn't say either of those things, but I appreciate the feedback. RAID 0 is an interesting suggestion, but given our constraints, it's not an option. Reliability is important, but not as important as, say, a banking system.
And as far as zero write traffic, I don't know where that came from. It's a "hitlist" based system, where complex search results are saved for the user in tables, and the write traffic can be quite high.
> If this is true, then RAID-0 is the way to go. I think Greg's options
> are good. Either:
>
> 2 discs RAID 1: OS
> 6 discs RAID 0: database + WAL
>
> which is what we're using here (except with more discs), or:
>
> 8 discs RAID 10: everything
Right now, an 8-disk RAID 10 is looking like the best choice. The Dell Perc 6i has configurations that include a battery-backed cache, so performance should be quite good.
> However, if reliability *really* isn't an issue, and you can accept
> reinstalling the system if you lose a disc, then there's a third option:
>
> 8 discs RAID 0: Everything
I imagine the MTBF on a system like this would be < 1 year, which is out of the question, even with a backup system that can take over. A failure completely wipes the system, OS and everything, so you're guaranteed that once or twice a year, you have to rebuild your system from the ground up. I'd rather spend that time at the beach!
Craig
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: How to allocate 8 disks
@ 2008-03-03 14:57 Matthew <matthew@flymine.org>
parent: Mark Mielke <mark@mark.mielke.cc>
1 sibling, 1 reply; 14+ messages in thread
From: Matthew @ 2008-03-03 14:57 UTC (permalink / raw)
To: pgsql-performance
On Mon, 3 Mar 2008, Mark Mielke wrote:
> Has anybody been able to prove to themselves that RAID 0 vs RAID 1+0 is
> faster for these sorts of loads? My understanding is that RAID 1+0 *can*
> reduce latency for reads, but that it relies on random access, whereas RAID 0
> performs best for sequential scans? Does PostgreSQL ever do enough random
> access to make RAID 1+0 shine?
Theoretically the performance of RAID 0 and RAID 10 should be identical
for reads, both seeks and throughput, assuming you have a sensible
readahead and a good controller. For writes, RAID 10 needs to write to
multiple drives, so is slower. Whether this is true in reality is another
matter, as all sorts of factors come in, not least how good your
controller is at managing the arrangement.
Matthew
--
The only secure computer is one that's unplugged, locked in a safe,
and buried 20 feet under the ground in a secret location...and i'm not
even too sure about that one. --Dennis Huges, FBI
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: How to allocate 8 disks
@ 2008-03-03 15:06 Mark Mielke <mark@mark.mielke.cc>
parent: Matthew <matthew@flymine.org>
0 siblings, 0 replies; 14+ messages in thread
From: Mark Mielke @ 2008-03-03 15:06 UTC (permalink / raw)
To: Matthew <matthew@flymine.org>; +Cc: pgsql-performance
Matthew wrote:
> On Mon, 3 Mar 2008, Mark Mielke wrote:
>> Has anybody been able to prove to themselves that RAID 0 vs RAID 1+0
>> is faster for these sorts of loads? My understanding is that RAID 1+0
>> *can* reduce latency for reads, but that it relies on random access,
>> whereas RAID 0 performs best for sequential scans? Does PostgreSQL
>> ever do enough random access to make RAID 1+0 shine?
> Theoretically the performance of RAID 0 and RAID 10 should be
> identical for reads, both seeks and throughput, assuming you have a
> sensible readahead and a good controller. For writes, RAID 10 needs to
> write to multiple drives, so is slower. Whether this is true in
> reality is another matter, as all sorts of factors come in, not least
> how good your controller is at managing the arrangement.
I don't think your statement that they should be identical is true -
RAID 1+0 can satisfy and given read from at least two drives. A good
controller can satisfy half the reads from one side of the array, and
half the reads from the other side of the array, where the first set
does not have to wait for the second set, before continuing. To
contrast, sequential reads of a RAID 1+0 system is almost always HALF of
the speed of sequential reads of a RAID 0 system. The hardware
read-ahead on the RAID 1+0 system is being wasted as even if you did
leap from one side of the array to the other, each side ends up
"skipping" the data served by the other side, making any caching
ineffective.
The question I have is not whether RAID 1+0 vs RAID 0 show different
characteristics. I know they do based upon my own analysis. My question
is whether PostgreSQL disk access patterns for certain loads ever
benefit from RAID 1+0, or whether RAID 1+0 is always a bad choice for
performance-only (completely ignore reliability) loads.
Cheers,
mark
--
Mark Mielke <mark@mielke.cc>
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: How to allocate 8 disks
@ 2008-03-03 15:22 Scott Marlowe <scott.marlowe@gmail.com>
parent: Mark Mielke <mark@mark.mielke.cc>
1 sibling, 0 replies; 14+ messages in thread
From: Scott Marlowe @ 2008-03-03 15:22 UTC (permalink / raw)
To: Mark Mielke <mark@mark.mielke.cc>; +Cc: Matthew <matthew@flymine.org>; pgsql-performance
On Mon, Mar 3, 2008 at 8:48 AM, Mark Mielke <mark@mark.mielke.cc> wrote:
> Matthew wrote:
> > On Sat, 1 Mar 2008, Craig James wrote:
> >> Right, I do understand that, but reliability is not a top priority in
> >> this system. The database will be replicated, and can be reproduced
> >> from the raw data.
> >
> > So what you're saying is:
> >
> > 1. Reliability is not important.
> > 2. There's zero write traffic once the database is set up.
> >
> > If this is true, then RAID-0 is the way to go. I think Greg's options
> > are good. Either:
> >
> > 2 discs RAID 1: OS
> > 6 discs RAID 0: database + WAL
> >
> > which is what we're using here (except with more discs), or:
> >
> > 8 discs RAID 10: everything
>
> Has anybody been able to prove to themselves that RAID 0 vs RAID 1+0 is
> faster for these sorts of loads? My understanding is that RAID 1+0 *can*
> reduce latency for reads, but that it relies on random access, whereas
> RAID 0 performs best for sequential scans? Does PostgreSQL ever do
> enough random access to make RAID 1+0 shine?
RAID 1+0 has certain theoretical advantages in parallel access
scenarios that straight RAID-0 wouldn't have. I.e. if you used n>2
disks in a mirror and built a RAID-0 out of those types of mirrors,
then you could theoretically have n users reading data on the same
"drive" (the raid-1 underneath the raid-0) at the same time where
RAID-0 would only have the one disk to read from. The effects of this
advantage are dulled by caching, depending on how much of the data set
you can cache. With a system that can cache it's whole data set in
memory (not uncommon for transactional systems) or at least a large
percentage, the n>2 RAID-1 sets aren't that big of an advantage.
RAID-0 of n drives should behave pretty similarly to RAID-10 with 2n
drives for most types of access. I.e. no better or worse for
sequential or random access, if the number of drives is equivalent.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: How to allocate 8 disks
@ 2008-03-04 10:45 Ivan Voras <ivoras@geri.cc.fer.hr>
parent: Joshua D. Drake <jd@commandprompt.com>
1 sibling, 1 reply; 14+ messages in thread
From: Ivan Voras @ 2008-03-04 10:45 UTC (permalink / raw)
To: pgsql-performance
Joshua D. Drake wrote:
> This scares me... You lose WAL you are a goner. Combine your OS and
> WAL into a RAID 1.
Can someone elaborate on this? From the WAL concept and documentation at
http://www.postgresql.org/docs/8.3/interactive/wal-intro.html I'd say
the only data that should be lost are the transactions currently in the
log but not yet transferred to permanent storage (database files proper).
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: How to allocate 8 disks
@ 2008-03-04 15:04 Shane Ambler <pgsql@Sheeky.Biz>
parent: Ivan Voras <ivoras@geri.cc.fer.hr>
0 siblings, 0 replies; 14+ messages in thread
From: Shane Ambler @ 2008-03-04 15:04 UTC (permalink / raw)
To: Ivan Voras <ivoras@geri.cc.fer.hr>; +Cc: pgsql-performance
Ivan Voras wrote:
> Joshua D. Drake wrote:
>
>> This scares me... You lose WAL you are a goner. Combine your OS and
>> WAL into a RAID 1.
>
> Can someone elaborate on this? From the WAL concept and documentation at
> http://www.postgresql.org/docs/8.3/interactive/wal-intro.html I'd say
> the only data that should be lost are the transactions currently in the
> log but not yet transferred to permanent storage (database files proper).
>
The log records what changes are made to your data files before the data
files are changed. (and gets flushed to disk before the data files are
changed)
In the event of power loss right in the middle of the data files being
updated for a transaction, when power is restored, how do we know what
changes were made to which data files and which changes are incomplete?
Without the log files there is no way to be sure your data files are not
full of "half done transactions"
Chances are that 90% of the time everything is fine but without the log
files how do you check that your data files are as they should be.
(or do you expect to restore from backup after any power outs?)
Keeping them on a raid 1 gives you a level of redundancy to get you past
hardware failures that happen at the wrong time. (as they all do)
--
Shane Ambler
pgSQL (at) Sheeky (dot) Biz
Get Sheeky @ http://Sheeky.Biz
^ permalink raw reply [nested|flat] 14+ messages in thread
end of thread, other threads:[~2008-03-04 15:04 UTC | newest]
Thread overview: 14+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2008-03-01 18:06 How to allocate 8 disks Craig James <craig_james@emolecules.com>
2008-03-01 18:47 ` Scott Marlowe <scott.marlowe@gmail.com>
2008-03-01 21:03 ` Joshua D. Drake <jd@commandprompt.com>
2008-03-01 21:53 ` Craig James <craig_james@emolecules.com>
2008-03-01 22:30 ` Scott Marlowe <scott.marlowe@gmail.com>
2008-03-02 04:51 ` Greg Smith <gsmith@gregsmith.com>
2008-03-03 12:11 ` Matthew <matthew@flymine.org>
2008-03-03 14:48 ` Mark Mielke <mark@mark.mielke.cc>
2008-03-03 14:57 ` Matthew <matthew@flymine.org>
2008-03-03 15:06 ` Mark Mielke <mark@mark.mielke.cc>
2008-03-03 15:22 ` Scott Marlowe <scott.marlowe@gmail.com>
2008-03-03 14:53 ` Craig James <craig_james@emolecules.com>
2008-03-04 10:45 ` Ivan Voras <ivoras@geri.cc.fer.hr>
2008-03-04 15:04 ` Shane Ambler <pgsql@Sheeky.Biz>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox