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/mysqld.cc: 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"
bugs
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.
PlanetMySQL Voting: Vote UP / Vote DOWN