Hi all,
This has been discussed before (some URLs below), but the threads have
unfortunately been rather free of (precise) information. I am
interested in getting PG running over NFS. However, I am primarily
concerned with safety/recoverability (on sudden power loss); I care
very, very little about the performance. Hence, I think this is a
substantially simpler question to answer definitively (must also
assume the NFS server may lose power). The particular NFS client and
server implementations I'm using are the Linux NFS implementation
(using kernel 2.6).
If PG is unsuitable for this task, can any (preferrably open-source)
alternatives be recommended? (Just for curiosity, consider any storage
system supporting transactions and recovery, not necessarily the
relational model or high performance.)
BTW I've included some correspondence from my colleagues; I would also
appreciate it if any corrections are offered to their statements (if
necessary). From querying #postgresql on FreeNode, I gathered that as
long as fsync works properly (flushes data to the server), there are
no other concerns (and that there is in fact no file locking, except
perhaps on the pid file).
Thanks a lot!
Yang
http://archives.postgresql.org/pgsql-performance/2004-06/msg00215.php
http://www.thescripts.com/forum/thread422520.html
http://lists.freebsd.org/pipermail/freebsd-database/2006-January/000372.html
> Hmm... that's bad. The memory mapped IO we can live without (sure,
> it's a performance issue, but at least it'll probably still work).
> Mutexes and locks... I wonder if we could put them in a ramdrive?
>
> > It is not recommended to place database storage onto NFS. This is
> > seems to be true for Postgresql, SQLite, and BerkleyDB, it seems that
> > this is a general problem. The reasons are:
> > * DBs use memory mapped IO
> > * DBs use mutexes and locks
> >
> > Presumably, neither of these work over NFS. I don't have any hard
> > evidence, I just read a bunch of FAQs and messages on mailings lists.
> > If this is indeed the case, that pretty much kills our plan for
> > hosting a DB on the slave. The "no,no" alternative is to place the DB
> > server on the master... and that would only work out of the box for
> > non-embedded databases.
