The documentation says that we need to run mysql as “root” user for it to be effective. The code also indicates the same thing where it tries to do a getuid call to check if the server is running as root user (sql/  if (locked_in_memory && !getuid())). The general rule of thumb is that we don’t want to run mysql or rather any database as root user since that leads to vulnerabilities.

Historically memlock seems to cause issues on some OS flavors where “mlockall” implementation is not stable. This is documented in mysql code with the below warning message.

The "–memlock" argument, which was enabled, uses system calls that are

unreliable and unstable on some operating systems and operating-system

versions (notably, some versions of Linux).  This crash could be due to use

of those buggy OS calls.  You should consider whether you really need the

"–memlock" parameter and/or consult the OS distributer about "mlockall"


On machines where only the database is hosted, if the memory sizing and parameters are set  optimally we might never want to use memlock.  It might be effective  to use “memlock” in machines where the database co-exists with  the application code and possibility of the database memory buffers getting swapped out is very high. Even on optimally sized standalone database machines due to various reasons (Jeremy has a nice blog post on this), there are chances of the database memory buffers getting swapped.

“memlock” seems to be a good option to pin the database in memory. But given the caveat that the servers needs to run as root user makes this option not usable in production since we don’t want to open up to vulnerabilities. Is there a workaround to use “memlock” in production or rather what would be the recommended way of using it.  

About these ads