Re: linux standard layout

Hi Ben,

If you must use a VMware server for your databases, please run
some "pull-the-power-plug" tests on your system to ensure that
your data integrity is maintained. Virtual machines can sometimes
cache filesystem updates in the name of performance with disasterous
consequences to your filesystems and databases.

Cheers,
Ken

On Tue, Mar 09, 2010 at 08:18:21AM -0600, Ben Kim wrote:
>
> Thanks all.
>
> I cannot change the decision on vmware or layout, but it's great to know
> that the rpm way is a valid one.
>
> I appreciate all inputs.
>
>
>
> Regards,
>
> Ben Kim
>
>
> On Mon, 8 Mar 2010, Scott Marlowe wrote:
>
>> On Mon, Mar 8, 2010 at 10:31 PM, Ben Kim <bkim@tamu.edu> wrote:
>>> Dear list,
>>>
>>> I have about 20 postgresql databases, about 3-4 GB in total.
>>>
>>> We are moving them from Solaris/SPARC to a linux based virtual machine.
>>>
>>> I don't like the VMWare environment, but it's not my choice, and assuming
>>> the cpu load is ok, will there be any benefits if I put each database on
>>> separate partitions, vs. simply using the one data directory?
>>
>> What reasoning was given for putting your database server in a
>> virutalizeed environment?
>>
>>> Also, how is using standard rpm, with its standard layout
>>> (/var/lib/pgsql,
>>> /usr/lib/pgsql, ...), generally regarded? ( vs. compiling everything ?)
>>> Does
>>> anyone think using the rpm is unprofessional or something that only
>>> beginners will do?
>>>
>>> I have someone who opposes the use of standard rpms (even yums) for this
>>> reason. I thought I'd check out how it is received professionally.
>>
>> Sounds like a religious argument.  I mostly used packages, unless I
>> can't.  (i.e. two different versions on RH at the same time)
>>
>>> I ask the question because sometimes I feel uneasy mixing rpms and source
>>> compilation.
>>
>> Worry more about accidentally having two different versions of the
>> same lib linked to various executables.  It's easy to do with things
>> like mysql and apache and php and zlib.
>>
>>> If I compile something from the source, sometimes I see a boundary
>>> condition
>>> - like, if I already have DBI from a standard rpm, it expects postgresql
>>> library at a certain location - making me wonder whether I should remove
>>> the
>>> DBI rpm and compile it also from the source, or whether I should use
>>> standard rpms for postgresql as well. (DBI may not be a good example.)
>>>
>>> In general I didn't have any problems yet with standard rpms and I can
>>> make
>>> the rpms work if there's a problem, but I may be missing something.
>>
>> My advice:
>>
>> put postgresql on its own, powerful, reliable non-virtualized server.
>> Demand that the person who wants to virtualize it justify their
>> decision with more than hand-wavy methodologies.  Use packages unless
>> you're on RPM and you need > 1 version of pgsql.  Even if you need to
>> compile some tarball against the packages, it's still easier to
>> maintain than to install it all from source.
>>
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin
>