Question Délai d'expiration du serveur Percona sur /etc/init.d/mysql start


A chaque fois que je lance mysql, en utilisant /etc/init.d/mysql start ou service mysql start, il arrive toujours à expiration.

 * Starting MySQL (Percona Server) database server mysqld                   [fail] 

Cependant, je peux entrer dans mysql. Je voulais juste savoir s'il y avait un problème d'installation car il se produit tout le temps, pas une erreur ponctuelle.

mysql-error.log montre:

121214 11:25:56 mysqld_safe Starting mysqld daemon with databases from /data/mysql/
121214 11:25:56 [Note] Plugin 'FEDERATED' is disabled.
121214 11:25:56 InnoDB: The InnoDB memory heap is disabled
121214 11:25:56 InnoDB: Mutexes and rw_locks use GCC atomic builtins
121214 11:25:56 InnoDB: Compressed tables use zlib 1.2.3
121214 11:25:56 InnoDB: Using Linux native AIO
121214 11:25:56 InnoDB: Initializing buffer pool, size = 14.0G
121214 11:25:58 InnoDB: Completed initialization of buffer pool
121214 11:26:01  InnoDB: Waiting for the background threads to start
121214 11:26:02 Percona XtraDB (http://www.percona.com) 1.1.8-rel29.2 started; log sequence number 9333955393950
121214 11:26:02 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
121214 11:26:02 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
121214 11:26:02 [Note] Server socket created on IP: '0.0.0.0'.
121214 11:26:02 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.005163' at position 624540946, relay log '/data/mysql/mysql-relay-bin.000043' position: 624541092
121214 11:26:02 [Note] Slave I/O thread: connected to master 'repl@10.8.25.111:3306',replication started in log 'mysql-bin.005180' at position 823447620
121214 11:26:02 [Note] Event Scheduler: Loaded 0 events
121214 11:26:02 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.28-29.2-log'  socket: '/data/mysql/mysql.sock'  port: 3306  Percona Server (GPL), Release 29.2

6
2017-12-14 19:28


origine


Sur quel OS êtes-vous? J'ai vu cela sur Debian / Ubuntu lorsque le /etc/mysql/debian.cnf Le fichier contenait des informations erronées. De plus, sur une très grande base de données, le délai d’expiration du script d’initialisation était trop court pour permettre à InnoDB de s’initialiser. - gertvdijk
C'est un serveur Ubuntu 12.04 qui fonctionne en tant qu'esclave, en utilisant le fichier my.cnf copié à partir du maître. La base de données est d'environ 750 Go, je ne sais pas si c'est très volumineux. - ks_1010
Dans ce cas, copiez également le debian.cnf du maître, je suppose que vous avez copié toute la base de données du maître de quelque temps. Ceci est utilisé pour vérifier le fonctionnement d'un serveur MySQL / Percona. Voir le fichier init aux lignes 27 et 77. - gertvdijk
+1 pour faire ressortir cette condition souvent négligée - RolandoMySQLDBA
@gertvdijk le maître d’un serveur Centos, la réplication est également affectée. - ks_1010


Réponses:


L'affichage du journal des erreurs semble assez normal

Le fichier de socket a été créé La réplication MySQL a bien commencé /usr/sbin/mysqld: ready for connections. apparaît

Especailly depuis que tu vois /usr/sbin/mysqld: ready for connections., vous devriez pouvoir vous connecter à mysql, ce que vous venez de dire.

Votre processus mysqld est bon.

L'erreur peut provenir de /etc/init.d/mysql mais pas avant que mysqld ait fait tout ce qui était nécessaire.

Si vous regardez à l'intérieur /etc/init.d/mysql il y a deux lignes

[root@***** init.d]$ cat mysql | grep -n "&" | grep "pid-file"
313:      $manager --user=$user --pid-file=$pid_file >/dev/null 2>&1 &
327:      $bindir/mysqld_safe --datadir=$datadir --pid-file=$server_pid_file $other_args >/dev/null 2>&1 &

Si /etc/init.d/mysql expiré, il est certainement arrivé après ces deux lignes.

Voici le code qui vérifie le fichier pid

wait_for_pid () {
  verb="$1"
  manager_pid="$2"  # process ID of the program operating on the pid-file
  i=0
  avoid_race_condition="by checking again"
  while test $i -ne $service_startup_timeout ; do

    case "$verb" in
      'created')
        # wait for a PID-file to pop into existence.
        test -s $pid_file && i='' && break
        ;;
      'removed')
        # wait for this PID-file to disappear
        test ! -s $pid_file && i='' && break
        ;;
      *)
        echo "wait_for_pid () usage: wait_for_pid created|removed manager_pid"
        exit 1
        ;;
    esac

    # if manager isn't running, then pid-file will never be updated
    if test -n "$manager_pid"; then
      if kill -0 "$manager_pid" 2>/dev/null; then
        :  # the manager still runs
      else
        # The manager may have exited between the last pid-file check and now.
        if test -n "$avoid_race_condition"; then
          avoid_race_condition=""
          continue  # Check again.
        fi

        # there's nothing that will affect the file.
        log_failure_msg "Manager of pid-file quit without updating file."
        return 1  # not waiting any more.
      fi
    fi

    echo $echo_n ".$echo_c"
    i=`expr $i + 1`
    sleep 1
  done

  if test -z "$i" ; then
    log_success_msg
    return 0
  else
    log_failure_msg
    return 1
  fi
}

wait_for_pid() s'appelle après le lancement de mysqld_safe

  # Give extra arguments to mysqld with the my.cnf file. This script
  # may be overwritten at next upgrade.
  pid_file=$server_pid_file
  $bindir/mysqld_safe --datadir=$datadir --pid-file=$server_pid_file $other_args >/dev/null 2>&1 &
  wait_for_pid created $!; return_value=$?

Dans le pire des cas, mysqld s'exécute sans fichier pid. À la lumière de cela, service mysql stop et /etc/init.d/mysql stop peut ne pas fonctionner correctement car il vérifie que le fichier pid connaît l'identifiant du processus de mysqld.

Sans un fichier pid, la bonne façon d’arrêter mysqld est

# mysqladmin -uroot -h127.0.0.1 --protocol=tcp -p shutdown

CAVEAT

Ce n'est pas si local d'un phénomène. J'ai vu cela se produire également avec les fichiers binaires standard de MySQL.


3
2017-12-14 20:11





Il semble que le script init recherche un serveur MySQL / Percona en cours d’exécution sur Ubuntu à l’aide de mysqladmin --defaults-file=/etc/mysql/debian.cnf ping (voir lignes 27 et 77 du /etc/init.d/mysql de la dans ce cas percona-server-server-5.5 version du paquet 5.5.28-rel29.2-360.precise). Cela fonctionne dans une nouvelle installation par défaut, mais lors de la copie de fichiers de données lors de la configuration de la réplication à partir d'une autre machine, l'utilisateur configuré dans debian.cnf ne correspond plus.

En conséquence, le mysqladmin commande échouera et le script init sera rapport le service a échoué, mais il fonctionne correctement comme vous pouvez le voir dans les journaux.

Une solution consiste à recréer l'utilisateur MySQL attendu par les scripts init. Sur le maître, ajoutez simplement l'utilisateur comme ceci (semble avoir tous les privilèges par défaut?!):

GRANT ALTER, ALTER ROUTINE, CREATE, CREATE ROUTINE, CREATE TEMPORARY TABLES,
CREATE USER, CREATE VIEW, DELETE, DROP, EVENT, EXECUTE, FILE, INDEX, INSERT,
LOCK TABLES, PROCESS, REFERENCES, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE,
SELECT, SHOW DATABASES, SHOW VIEW, SHUTDOWN, SUPER, TRIGGER, UPDATE
ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY PASSWORD 
*replacethiswithaknownhash' WITH GRANT OPTION;

et créer / modifier le /etc/mysql/debian.cnf fichier:

[client]
host     = localhost
user     = debian-sys-maint
password = yourpass
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = debian-sys-maint
password = yourpass
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

Vous devrez peut-être attendre que le processus de réplication soit rattrapé, puis essayer de redémarrer.


3
2017-12-14 21:27



Oui, mysqladmin incapable de se connecter à mysqld vient de démarrer est l'une des raisons pour lesquelles le script semble échouer. M'est arrivé lors de la mise à niveau vers Debian Wheezy, alors que mysqladmin n'était pas encore à niveau. - Marki555


Avait exactement le même problème sur Debian. Le serveur démarre mais le script init dit qu'il échoue:

/etc/mysql/debian.cnf has the mysql socket set at /var/run/mysqld/mysqld.sock

alors que le my.cnf a probablement mis à

/var/lib/mysql/mysql.sock

Assurez-vous que le chemin du socket et du pid dans my.cnf pointe vers ce qui est défini dans

/etc/mysql/debian.cnf

Assurez-vous également de pointer vers mysqld pas mysql


0
2018-05-23 13:57





Je sais que c'est un peu vieux, mais c'est 30/4/2015 et nous avons eu le même problème avec Percona 5.6.

La fonction /etc/init.d/mysql 'start' a les caractéristiques suivantes (à partir de ln: 112):

#wait 10sec before start checking if pid file created or server is dead
if [ $dead_check_counter -lt 10 ]; then
   dead_check_counter=$(( dead_check_counter + 1 ))
else
  if mysqld_status check_dead warn; then break; fi
fi

Notre serveur a normalement besoin de 40 à 70 secondes pour démarrer (l’initialisation d’un pool de mémoire tampon Innodb de 97 Go ne prend que 35 secondes environ); il est donc naturel que "start" le signale comme "mort" car le fichier de socket n’a pas encore été créé.

Je viens d'augmenter la valeur "10" et cela a bien fonctionné pour moi.

À votre santé


0
2018-04-29 21:24