Hannes Dorbath wrote:
Chander Ganesan wrote:
Magnus Hagander wrote:
On Thu, Jan 31, 2008 at 03:34:05PM +0100, Martijn van Oosterhout wrote:
On Thu, Jan 31, 2008 at 01:28:48PM +0000, Simon Riggs wrote:
That sentence has no place in any discussion about "backup" because
the
risk is not just a few transactions, it is a corrupt and inconsistent
database from which both old and new data would be inaccessible.
Hmm? I thought the whole point of a filesystem snapshot was that it's
the same as if the system crashed. And I was fairly sure we could
recover from that...
That was my assumption as well. *Assuming* that the filesystem
snapshot is
consistent. There are a bunch of solutions that don't do consistent
snapshots between different partitions, so if your WAL or one
tablespace is
on a different partition, you'll get corruption anyway... (seen this in
Big Commercial Database, so that's not a pg problem)
Agreed. That's why I made it a point to mention that all of your
tablespaces should be on the same file system... In hindsight, I
should have also stated that your WAL logs should be on the same file
system as
One more reason to consider using Solaris ZFS -- it does consistent
snapshots across all file systems.
In general file system snapshots are quite a pain with Linux LVM.
Even when using separate spindles for the snapshot COW area the impact
on write performance on the origin LV is still huge. You'll have a hard
time to write with more than 15MB/sec to the origin LV.
Additionally when you lost your COW device there is this nice bug in
vgreduce --removemissing that will silently delete your origin LV as
well: http://readlist.com/lists/redhat.com/linux-lvm/0/2025.html
Not to mention that LVM does not support write barriers and does mess
with any kind of stripe alignment of your file system.
--
Best regards,
Hannes Dorbath
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
