On Wed, Sep 30, 2015 at 4:58 PM, Benjamin Smith <ben@xxxxxxxxx> wrote:
On Wednesday, September 30, 2015 03:49:44 PM Keith Fiske wrote:
> We've run postgres on ZFS for years with great success (first on
> OpenSolaris, now on OmniOS, and I personally run it on FreeBSD). The
> snapshotting feature makes upgrades on large clusters much less scary
> (snapshot and revert if it goes bad) and being able to bring a snapshot
> backup up as a clone to restore an accidentally dropped table is great.
Somebody mentioned some trouble running it with ZFS on Linux, which is exactly
how we're planning our roll out. (We're a RHEL/CentOS shop) Have you tried
that config, and has it worked for you?
We've not run it in production where I work and I haven't met anyone that is doing it either. Personally, I tried it at home for a while when I used to use Linux on my home server. But whenever there was a kernel or zfs update, i'd occasionally have problems with it booting up or seeing the zfs mount. Rebooting again usually fixed it, but it made me nervous every time there was a kernel update. I switched to FreeBSD a few years ago to get native ZFS support and haven't looked back since. As that was a few years ago, things may have improved, but I couldn't speak to those improvements anymore.
> Others have given a lot of great advice as far as system tuning. Only other
> thing I can add is you definitely do want your data directory on its own
> pool. But I recommend putting the actual data in a folder under that pool
> (possibly by major version name). For example if your pool is
>
> /data/postgres
>
> Create a folder under that directory to actually put the data:
>
> mkdir /data/postgres/9.4
>
> This allows pg_upgrade's --link option to work during major upgrades since
> you can't have an upgrade destination on a different filesystem. Just make
> a 9.5 directory in the same spot when the time comes around. With ZFS
> snapshots available, there's really no reason not to use the --link option
> to greatly speed up upgrades.
Recently, the PGDG RPMs provided by PostgreSQL have done something similar by
moving from /var/lib/pgsql/ to (EG) /var/lib/pgsql/9.4 and we've followed
suit, trying to keep things "stock" where possible.
Our intent is to make /var/lib/pgsql a filesystem in a pool containing no other
file systems, with SSD-based VDEVs that aren't shared for any other purpose.
