Re: 2 questions

Поиск
Список
Период
Сортировка
Искать
От
Jim Nasby
Тема
Re: 2 questions
Дата
Msg-id
565F8F28.2070602@BlueTreble.com
Ответ на
Re: 2 questions (Scott Mead)
Список
Дерево обсуждения
2 questions anj patnaik <patna73@gmail.com>
Re: 2 questions Adrian Klaver <adrian.klaver@aklaver.com>
Re: 2 questions anj patnaik <patna73@gmail.com>
Re: 2 questions Adrian Klaver <adrian.klaver@aklaver.com>
Re: 2 questions anj patnaik <patna73@gmail.com>
Re: 2 questions Scott Mead <scottm@openscg.com>
Re: 2 questions Jim Nasby <Jim.Nasby@BlueTreble.com>
Re: 2 questions anj patnaik <patna73@gmail.com>
Re: 2 questions Adrian Klaver <adrian.klaver@aklaver.com>
Re: 2 questions Adrian Klaver <adrian.klaver@aklaver.com>
Re: 2 questions Adrian Klaver <adrian.klaver@aklaver.com>
Re: 2 questions Albe Laurenz <laurenz.albe@wien.gv.at>
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

В списке pgsql-general по дате отправления
От: Sheena, Prabhjot
Дата:
От: Bruce Momjian
Дата:
FAQ