Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As part of my work, I manage a mySQL cluster composed of 3 Ubuntu 14.04 machines. All 3 machines should be identical.

On machines 1 and 2, when I run sudo service mysql status, I get a status report with uptime, etc, the equivalent of running /usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf version. This behavior is consistent with the /etc/init.d/mysql file, which has the entry:

'status')
    if mysqld_status check_alive nowarn; then
      log_action_msg "$($MYADMIN version)"
    else
      log_action_msg "MySQL (Percona Server) is stopped."
      exit 3
    fi
    ;;

(the $MYADMIN variable resolves to that command I posted earlier).

Machine number 3 however, does not behave like this. Upon running sudo service mysql status, I am given the standard Ubuntu status response, mysql start/running, process 2234.

The /etc/init.d/mysql file on machine 3 is identical to the files on 1 and 2 (checked with vimdiff). If I run the mysqladmin command by hand, it returns the expected output.

What gives? Is there something that would override the script in init.d?

Although the cluster seems to be working as expected, I don't like inconsistencies in computers... makes me feel like something I'm not aware of is happening.

Thanks in advance for any help you can provide.

share|improve this question
up vote 0 down vote accepted

The later looks like a daemon launched from systemd/upstart without the SysV compatibility layer (the init.d script; init.d scripts are actually depreciated). Try checking for an /etc/init/mysql* file.

share|improve this answer
    
thanks a lot @some-linux-nerd! This helped me figure out the cause for this. See, I had already looked at the /etc/init/mysql.conf file and decided that there was nothing special in it that would account for the different behavior. However, I hadn't tried looking at the other servers to see what they looked like, and it turns out they did not have that file. The question now is, which is the correct configuration? Having the init/mysql.conf file or the init.d/mysql? Is one deprecated? Do they complement each other? Does it matter? – Gene R Jan 20 at 14:28
    
Thats a really good question! It depends on why they're different. The server that's different may have had a different mysql rpm/dpkg installed. You can get mysql-server from most Linux distributions, but also from Oracle, Percona, the MariaDB project, etc. The level of standardization depends on how completely OCD you are feeling. If the mysql package is different on your systems I would leave everything as is. If nothing is actually setup yet, then you can standardize which package/rpm/dpkg is used on all the machines. – Some Linux Nerd Jan 20 at 20:08
    
If you want to standardize packages, you can turn off the mysql daemon on the different server, and then save /etc/my.cnf /var/lib/mysql and /etc/my/* somewhere. This is assuming everything is in the normal place. Then you can uninstall the "wrong" package, and install the correct one, then cleverly swap out the new /var/lib/mysql /etc/my.cnf and /etc/my/* files for the old version. Assuming you're using the same mysql version, everything should work when the server starts. If you change some mysql settings (innodb) this could result in data loss. – Some Linux Nerd Jan 20 at 20:10
    
Or alternately you can just try copying the /etc/init.d/mysql script to the new servers and see if it works. You might have to fiddle with paths or program names in the init.d script, but most mysql packages are very similar. – Some Linux Nerd Jan 20 at 20:11
    
Oh and they do not complement each other. You should have one or the other. If it really comes down to whether to use /etc/init.d/mysql or /etc/init/mysql.conf I would go with the later, but it's not that important unless something fails to start when rebooting (long story short, occasionally init.d scripts don't work correctly with systemd/upstart. It's a pretty rare problem.). – Some Linux Nerd Jan 20 at 20:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.