Search Postgresql Archives

Re: 2 questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/1/15 10:26 AM, Scott Mead wrote:
The data directory will cause you many problems. You will need one data
directory that is accessed by one AND ONLY one host for each node
connected. You can't run an instance on multiple machines pointing to
the same 'data' directory simultaneously.  Data directories cannot be
shared by multiple instances simultaneously, that's an active/active
shared disk cluster and most databases don't support it or require
massive overhead ( network/licensing I.e. Oracle rac) to do that.

Not only that, but trying to reliably operate a database on an NFS mount is *extremely* difficult. NFS is notorious for not correctly honoring things like fsync and atomic rename, which pretty much guarantees you'll end up with a corrupted (and unusable) database at some point.

VMs can also be dangerous in this regard, though as far as I know all the major ones should be safe with a default configuration. Be extremely careful about any "performance tweaks" you decide to do though.

Personally, for small environments, I tend to prefer just running the database on bare hardware and making use of features like connection poolers and replication to provide for high availability and operational flexibility, rather than trying to finagle it through a bunch of virtualization.

One last think to consider... you didn't mention backups. Understand that multiple copies of a database kept on the same storage system are NOT a replacement for backups, no matter how much redundancy that storage system has. All it takes is one bug in the storage firmware, or one person hacking into the control interface for the storage system (or one malicious employee) and ALL of your data goes *poof*. You may well decide that it's not worth the extra cost/overhead to protect against those events. Just don't fall into the trap of "we have multiple snapshots/copies, and those are just as good as backups". :)
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux