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