Florin Andrei wrote:
>On Wed, 2005-03-30 at 19:59 -0600, John Arbash Meinel wrote:
>
>
>
>>Put pg_xlog onto the same drive as the OS, not the drive with the database.
>>
>>
>
>I forgot to mention: the OS drive is purposefully made very slow - the
>write cache is turned off and the FS is Ext3 with data=journal. Is then
>still ok to put pg_xlog on it?
>
>The reason: if the power cord is yanked, the OS _must_ boot back up in
>good condition. If the DB is corrupted, whatever, nuke it then re-
>initialize it. But the OS must survive act-of-god events.
>
>No, there is no uninterruptible power supply. It sucks, but that's how
>it is. I cannot change that.
>
>
>
You don't want write cache for pg_xlog either. And you could always
create a second partition that used reiserfs, or something like that.
If you have to survine "act-of-god" you probably should consider making
the system into a RAID1 instead of 2 separate drives (software RAID
should be fine).
'Cause a much worse act-of-god is having a drive crash. No matter what
you do in software, a failed platter will prevent you from booting. RAID
1 at least means 2 drives have to die.
If you need insert speed, and can't do custom transactions at the
application side, you could try creating a RAM disk for the insert
table, and then create a cron job that bulk pulls it out of that table
and inserts it into the rest of the system. That should let you get a
super-fast insert speed, and the bulk copies should stay reasonably fast.
Just realize that if your cron job stops running, your machine will
slowly eat up all of it's ram, and really not play nice. I think adding
an extra hard-drive is probably the best way to boost performance and
reliability, but if you have a $0 budget, this is a possibility.
John
=:->