I've got a couple of InnoDB based MySQL servers that can depending on various circumstances take what feels like forever to start up. My suggestion is to change the logic of the startup check to actually check whether the pid is still owned by a mysqld process until the socket becomes available (even if this takes 5 or 10 or 20 minutes - although I only once in my life saw mysqld taking 40 odd mins to start up, that too should be covered). ewaitfile ${startup_timeout} "${socket}" Should thus become a loop like: einfo "Waiting for MySQL socket to become available" r=0 while ! ewaitfile ${startup_timeout} "${socket}"; do echo -n . if [ ! -r ${pidfile} ] || ! kill -0 $(< ${pidfile}); then r=1 break; fi done eend $r || return 1 I note newer builds no longer use ewaitfile ... but the above can be adjusted easily enough to function in newer builds too. Note that mostly long delays are due to non-clean shutdowns - which is pretty much the only type I ever see ... If possible both the pid-still-in-use on startup and the pid check above should actually verify that the pid is in fact a mysqld instance. Reproducible: Always
Hi, Thanks for re-assigning, I'd like to however query the priority level, seeing that this has caused me to lose data on a few occasions I believe that it should receive high priority. Data loss can occur if mysql starts up multiple times concurrently. With the current init scripts this can very easily happen if for example /etc/init.d/mysql deems the startup to have failed but mysql has in fact started up, and a later invocation of rc tries to start it again due to it begin "stopped". Default configuration (and recommended unless you need concurrent InnoDB access ...) is to skip-external-locking. Granted the second instance will fail when trying to open it's sockets, but that's not before InnoDB (and other engines) have had a chance to initialize.
Are you still experiencing this issue? If so, please provide information about the mysql, mysql-init-scripts and your init packages.
Hi Jorge, Haven't seen this recently, seems like a newer mysql-init-scripts package sorted this out. Thanks. Kind Regardsm Jaco
