2

Is it a problem that mysqld socket has a different version than the mysqld server? I noticed this in my mysqld log during startup

120420 19:30:06 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120420 19:30:06  InnoDB: Initializing buffer pool, size = 8.0M
120420 19:30:06  InnoDB: Completed initialization of buffer pool
120420 19:30:06  InnoDB: Started; log sequence number 0 44233
120420 19:30:06 [Note] Event Scheduler: Loaded 0 events
120420 19:30:06 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.61'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  Source distribution

Yet, when I show variables I get this

SHOW VARIABLES LIKE "%version%";

+-------------------------+-------------------------------------------+
| Variable_name           | Value                                     |
+-------------------------+-------------------------------------------+
| innodb_version          | 5.5.30                                    |
| protocol_version        | 10                                        |
| slave_type_conversions  |                                           |
| version                 | 5.5.30-cll                                |
| version_comment         | MySQL Community Server (GPL) by Atomicorp |
| version_compile_machine | x86_64                                    |
| version_compile_os      | Linux                                     |
+-------------------------+-------------------------------------------+
7 rows in set (0.00 sec)

Based on golimar's questions I ran a

ps aux

and I see this

mysql 633 31.4 33.5 11942788 5452172 ? SNl 08:18 101:31 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=/var/lib/mysql/host.reviewcritical.com.err --open-files-limit=4096 --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock --port=3306

root 32674 0.0 0.0 108292 1576 ? SN 08:18 0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --pid-file=/var/run/mysqld/mysqld.pid --basedir=/usr --user=mysql

4
  • do you remember installing both versions, and if so in which order did you install them?
    – golimar
    Mar 5, 2013 at 13:10
  • Yep, originally I had mysql 5.1, then later with yum I upgraded mysql on my centos to 5.5, but it seems this mysql.sock may have been missed? I am not finding much doucmentation unfortunately on this mysql.sock.
    – giorgio79
    Mar 5, 2013 at 21:14
  • 1
    The socket doesn't have a version, it just connects you to a server. How may different mysqld processes do you have?
    – golimar
    Mar 6, 2013 at 9:10
  • Great question golimar, I see two mysql related processes, one for mysqld_safe and another for mysqld. I updated the question as the reply did not fit here. Looks like this is the problem that I somehow have a mysql_safe running for some reason next to mysqld.
    – giorgio79
    Mar 6, 2013 at 12:47

1 Answer 1

5

As we all know, mysqld_safe and mysqld are very different

mysqld : The database server instance daemon

mysqld_safe : Control program that examines and sets the environment for mysqld to execute. The mysqld executable is actually launched in a loop. When mysqld terminates, the mysqld_safe program will examine the return results and decide whether

  • mysqld terminated normally (intentional shutdown), leaves mysqld_safe
  • mysqld terminated abnormally (crash or kill -9 of mysqld)
    • Loop back, mysqld fails on retry, leaves mysqld_safe
    • Loop back, mysqld starts up, stays in the mysqld_safe loop

Why is it important to have mysqld and mysqld_safe using the same MySQL version?

Let me illustrate it this way: Percona Server sometimes has additional features in mysqld_safe for manipulating the OS. For example, I have seen numactl --interleave=all in a Percona Server mysqld_safe. If that line was not there, the mysqld for Percona Server may run into issues with memory and swapping.

The same scenario could possibly be the case for Oracle's (ugh, still hate saying that) mysqld and mysqld_safe. There could be improvements from one major release to another that would be removed if the mysqld_safe was older.

Rather than exploring the possibilities of using a old mysqld_safe and a new mysqld (or vica versa), please make your life simple and reinstall MySQL 5.5.30 from scratch.

Before doing so, please run

updatedb
locate mysqld_safe

in Linux and see if there are two lingering. If there are, get the paths straightened out. Otherwise, you may have to reinstall MySQL 5.5.30.

3
  • Thanks Rolando! You rock! You are the God of mysql :) Will reinstall my battle worn mysql db :)
    – giorgio79
    Mar 7, 2013 at 19:47
  • Hello, I've arrived at this question because after updating phpmyadmin and mysql. I got an error saying that "Your PHP MySQL library version 5.5.34 differs from your MySQL server version 5.1.69."Something strange, because when I check trough phpinfo, SQL "SELECT version;" or in mysql monitor. I get the right 5.5.34 version. After reading your answer, the result of locate mysqld_safe gives indeed two results: /usr/share/man/man1/mysqld_safe.1.gz and /usr/share/man/man8/mysqld_safe_selinux.8.gz. Since I'm super noob in this, what do you mean by "straighten the paths" ? thx
    – Kev
    Sep 23, 2013 at 11:12
  • @Amida, "straighten the paths" refers to figure out the duplicate binary files for mysqld_safe and get rid of the incorrect one, and also ensure that the mysqld_safe command points to the correct one. Aug 5, 2016 at 9:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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