Re: PG over NFS
От | Hannes Dorbath |
---|---|
Тема | Re: PG over NFS |
Дата | |
Msg-id | 460843B0.7080602@theendofthetunnel.de обсуждение исходный текст |
Ответ на | PG over NFS ("Yang" <jkfe7q002@sneakemail.com>) |
Ответы |
Re: PG over NFS
|
Список | pgsql-general |
There is GFS2, OCFS, DRBD, ENBD, iSCSI, AoE and a ton of other technologies. What on earth is the point in trying to use a DBMS over NFS? :) In case it's just for the fun of it, maybe consider: - davfs2 - curlftpfs > However, I am primarily concerned with safety/recoverability (on sudden power loss); Well then.. forget about NFS :) What about various replication solutions like slony, 8.2 warm standby log shipping, mammoth replicator? > must also assume the NFS server may lose power A raid controller with battery backed cache and/or an UPS might be a good start. If that's not an option disable all write caches or use a filesystem that supports write barriers. Yang wrote: > 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). -- Best regards, Hannes Dorbath
В списке pgsql-general по дате отправления: