>>>
>>> * I could buy two X25-E drives and have 32GB disk space, and some
>>> redundancy. This would cost about $1600, not counting the RAID
>>> controller. It is on the edge.
>> This was the solution I went with (4 drives in a raid 10 actually).
>> Not a cheap solution, but the performance is amazing.
>
> I've came across this article:
>
> http://www.mysqlperformanceblog.com/2009/03/02/ssd-xfs-lvm-fsync-write-cache-barrier-and-lost-transactions/
>
>
> It's from a Linux MySQL user so it's a bit confusing but it looks like
> he has some reservations about performance vs reliability of the Intel
> drives - apparently they have their own write cache and when it's
> disabled performance drops sharply.
Ok, I'm getting confused here. There is the WAL, which is written
sequentially. If the WAL is not corrupted, then it can be replayed on
next database startup. Please somebody enlighten me! In my mind, fsync
is only needed for the WAL. If I could configure postgresql to put the
WAL on a real hard drive that has BBU and write cache, then I cannot
loose data. Meanwhile, product table data could be placed on the SSD
drive, and I sould be able to turn on write cache safely. Am I wrong?
L
