Moving postgres data folder on NFS drive. Is it better to symlink, reinit cluster, or modify init.d script?

Question

I want to move my postgres data folder to an NFS drive but I'm not sure what would be the best way to do it. I've got three options in mind:

1. According to Postgres Documentation, one method would be to use the initdb command with the -D option.

   initdb will attempt to create the directory you specify if it does not already exist.

2. Another method listed on LinuxQuestions.org is to update the postgressql init script to point to the new directory, which in this case would be the NFS drive.

3. Lastly, I was thinking I would just copy the pgsql/data folder to the NFS drive and simply symlink the folder.

   i.e., pgsql/data -> nfs/data

Symlinking or updating the init script seem like the simplest approach to me, but I'm not sure if they would be best or the safest way. This is where I hope someone can help me out. Any suggestions, concerns, and pros/cons would be appreciated.

Environment Information

• Red Hat Enterprise Linux Server 5.7
• PostgreSQL 8.3.6

Assume that the NFS drive is mounted with -maproot=root option and that the NFS drive would be accessed by the root user.

Solution

You can simply shut down Postgres, move the folder over and change the init scripts to point to the correct location for the data directory. Double-check the configuration files under data/ for references to the old path before restarting the server.

---

You probably don't want to do this. Really. It's a BAD idea.
NFS's other name is the Network Failure System. It is not known for its reliability, and having the underlying filesystem go away at an inopportune time (e.g. when appending to the WAL) could really ruin your day, not to mention your database. Remember that Postgres does nothing special for NFS, and will freak out if something unexpected happens (see 17.2.1 in the Postgres manual).

Perhaps if you describe the underlying problem you're trying to solve (ask a new question) we can help you do so in a less risky way?

Comments

[ewwhite]

Why do you wish to move your database to an NFS mount?

[beldaz]

@womble Perhaps circumstances have changed in the 4 years since this comment, but these days with cloud systems one often has little choice in the matter: NFS is often the only way to get persistent storage.

[womble]

If your cloud provider's only persistent storage option is NFS, find a better cloud provider. Every provider I can think of supports at least block storage, too.

[MastaJeet]

This is NFS FUD. NFS can be stable. Oracle and VMWare (both doing highly intensive I/O) run well on NFS exports.

[scofield]

Thanks embobo for sharing. I am inclined to agree with you and fairly confident in the underlying systems. The organization here uses VMWare vSphere and have a full-time team of administrators monitoring the systems with redundancy and backups to the 9s. Admittedly, still not a 100% guarantee, but nothing really is. With that said, voretaq7, if I were to follow the recommendations in the documentation, specifically "mount NFS file systems synchronously (without caching)", would you still be concerned? Also, thanks for your help again, voretaq7. I really appreciate it.

[womble]

@embobo: That it can be stable is irrelevant. Why would you even want to take the risk for no benefit?

[voretaq7]

@John - I'd be concerned running anything critical like a database server over NFS, AFS, or any remote-mounted filesystem (NFS in particular - while it CAN be stable, it often is not, and the list of potential failure modes is rather long). Following the recommendations in the postgres docs & designing a robust NFS environment is a good start, but I'd smoke-test the ever-loving bejeebus out of it in a lab before trusting it in production :-)

[JamesRyan]

tbh Postgres should be able to cope with a tablespace dissapearing or reappearing without it effecting others whether it does is another question. As long as you sync writes with nfs the data will always be consistent if it is there.