configuration – MySQL, my.cnf and /etc/alternatives

2018. After the fresh install of 18.04, two years ago, I wanted to use my /etc/mysql/my.cnf setup from 16.04 to get things back to what they were. But the MySQL install sets two symlinks

  • /etc/mysql/my.cnf -> /etc/alternatives/my.cnf
  • /etc/alternatives/my.cnf -> /etc/mysql/mysql.cnf

thus I replaced the new /etc/mysql/mysql.cnf with my old 16.04 /etc/mysql/my.cnf.
Things went fine until another MySQL update, which, for some reasons, had my mysql.cnf replaced with the new one. Bug? Did I accept the replacement? Don’t think so, but, well, that’s always possible.

So what I did at the time was to bypass the alternatives system, i.e. replace the /etc/mysql/my.cnf link with my my.cnf file, and zeroed mysql.cnf. Since my.cnf takes precedence over mysql.cnf that worked (I think I tried to symlink mysql.cnf to my my.cnf file, and there were other trouble, don’t remember).

(To be honest, didn’t like much the alternatives implementation that I found, cumbersome and counter-intuitive)

2020. Did an upgrade from 18.04 to 20.04. And naturally, MySQL re-created a clean environment with the alternatives links. Good.

However, to complete the upgrade, this time I’d like to keep things clean, and as much as possible

  • keep using the alternatives system or not (depending on your advice)
  • ensure that a further MySQL upgrade (unless it’s v. 9) won’t overwrite my setup (or it asks)

What is the recommended way to keep a clean MySQL install?