me2

The beta cluster has two databases instances: 10.68.17.94 and 10.68.16.193 which are respectively deployment-db2 and deployment-db1.

The instances have been moved to new hosts which caused intermittent failures (T97033) and from SAL, @thcipriani restarted MariaDB on both on April 22nd:

April 22nd
21:40 thcipriani: restarted mariadb on deployment-db{1,2}

The error logs are sent to /mnt/sqldata/deployment-db1.err or /mnt/sqldata/deployment-db2.err but nothing suspicious there.

db1 has been restarted on Apr 23 according to last:

reboot   system boot  3.2.0-59-virtual Thu Apr 23 23:53 - 09:47  (09:54)

Maybe the service does not start automatically on boot, it does not show in /var/log/boot.log.

Didn't see mysql in /etc/rc[1-5].d/ anywhere.

Added mysql to both deployment-db{1,2] using:

sudo update-rc.d mysql defaults

I think this is typically done in the upstream package; however, we're using our own apt repo for mariadb precise instances on beta.

This should fix the issue for subsequent reboots, but we should review the puppet role and/or check with ops.

to be verified, it is well possible that in production we intentionally prevent mysql from starting manually. Either via the deb package or puppet.

On beta we might want to autostart it.

This issue is still occurring . Any update on this?

Not occurring for me.

The issue has evolved a bit.Not getting those cant connect to MySQL error, but VE is silently failing to load there.There is one error in the console though: TypeError: mw.log.error is not a function

That error looks like it could be related to https://gerrit.wikimedia.org/r/#/c/206033/

(So yes, I see the error as well, but VE still functions)

Krenair, try saving your edit and re-open multiple times . It didnt occur to me in one shot as well.