The fix for this contained multiple steps including different debug logs and then following clues in those logs. I'm documenting them to help others - your problems might be different but this process should help to discover what's wrong:
Firstly journalctl -xe
contains a lot more information. In my case it contained:
kernel: audit: type=1400 audit(1528794958.103:169): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/etc/mysql/my.cnf.fallback"
This could be fixed with vi /etc/apparmor.d/usr.sbin.mysqld
and adding lines for:
/etc/mysql/conf.d/mysql.cnf/ r,
/etc/mysql/conf.d/mysql.cnf/* r,
/etc/mysql/my.cnf.fallback r,
An interesting point is that it needs a separate line for a directory and wildcard files within it - this can be common for some unix applications but not all so might trip you up.
Once all the apparmor changes were done the system still wouldn't start, and this time the journalctl -xe
command yielded nothing useful.
I was then able to run sudo -u mysql mysqld
to try starting the daemon manually. This showed a failure with InnoDB starting up, but not why.
On a whim I deleted the files /var/lib/mysql/ib_logfile*
and ib_binlog
and tried again; this time the server started. I was then able to terminate this and run service start mysql
which worked.
Separately I deleted /var/lib/mysql/debian-5.7.flag
- I am unsure if this helped or would have caused subsequent problems if I had not done so.
Hopefully this example helps somebody; please feel free to add other answers along a similar line if you encountered different problems with this process.