← Back to team overview

maria-discuss team mailing list archive

Mounting tmpdir via NFS



I have a question that I've been struggling to get a clear answer to, or even any indication someone has done this before, and would appreciate any experience or thoughts.

Are there any known issues with defining tmpdir on multiple servers to point to a single NFS-mounted network share?  Would each instance co-habit peacefully and not try to change any files from another instance?

Why do I want to do this?

I have around 80 Centos/Rocky vms which run Mariadb 10.6.x.  Due to the nature of the work they do, some of them require a significant amount of tmpdir (up to 75Gb) relatively briefly (once or twice a day for a few minutes)

This growth is not always predictable, so generally the first I know about it is when Mariadb reports lowspace and the query stops. We then grow the /tmp partition that is defined as tmpdir and if we're quick enough, the query completes, but often the job dies. Then that extra space stays locked away forever, even if that server never tries to use that much tmpdir again. This does not feel efficient and I am pondering better ways of doing this.

One such thought would be to have a single HA NFS share on our network, mounted onto each VM as something like /mariadb-tempdir, and set $tmpdir to it.

In my mind, this would make a better use of one large allocation of space used by many things often, rather than lots of individual small to large sized bits of space used by one thing, rarely.  The chance of two or more servers filling that space feels small, but if it happened, one would wait until space was cleared - which might actually happen in this shared scenario when it never does in a single-server situation.

In my particular world, we have fast storage and a fast network. Speed tests on large and tiny files over NFS give surprisingly similar performance to writing to local vm disks, so I'm not worried about the overhead of NFS and even if it was, slow might still be preferred to full.

Thank you,


Follow ups