Laurent Laborde wrote:
On Tue, Nov 10, 2009 at 5:35 PM, Greg Smith <g...@2ndquadrant.com> wrote:
I have 1 spare dedicated to hot standby, doing nothing but waiting for
the master to fail.
+ 2 spare candidate for cluster mastering.
In theory, i could even disable fsync and all "safety" feature on the master.
There are two types of safety issues here:
1) Will the database be corrupted if there's a crash? This can happen
if you turn off fsync, and you'll need to switch to a standby to easily
get back up again
2) Will you lose transactions that have been reported as committed to a
client if there's a crash? This you're exposed to if synchronous_commit
is off, and whether you have a standby or not doesn't change that fact.
Everybody told me "nooo ! LVM is ok, no perceptible overhead, etc ...)
Are you 100% about LVM ? I'll happily trash it :)
Believing what people told you is how you got into trouble in the first
place. You shouldn't believe me either--benchmark yourself and then
you'll know. As a rule, any time someone suggests there's a
technological approach that makes it easier to manage disks, that
approach will also slow performance. LVM vs. straight volumes, SAN vs.
direct-attached storage, VM vs. real hardware, it's always the same story.
--
Greg Smith g...@2ndquadrant.com Baltimore, MD
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
