Похоже, что сценарий инициализации проверяет работающий сервер MySQL / Percona в Ubuntu с помощью mysqladmin --defaults-file=/etc/mysql/debian.cnf ping (см. строки 27 и 77 из /etc/init.d/mysql в этом случае percona-server-server-5.5 версия пакета 5.5.28-rel29.2-360.precise). Это работает в новой установке по умолчанию, но при копировании файлов данных при настройке репликации с другого компьютера пользователь, настроенный в debian.cnf больше не совпадает.

В результате mysqladmin команда завершится ошибкой, и сценарий инициализации отчет служба не удалась, но она работает нормально, как вы можете видеть в журналах.

Одно из решений - воссоздать пользователя MySQL, которого ожидают сценарии инициализации. На главном сервере просто добавьте такого пользователя (кажется, у него все права по умолчанию ?!):

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;

и создать / изменить /etc/mysql/debian.cnf файл:

[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

Возможно, вам придется подождать, пока процесс репликации будет достигнут, а затем попытаться перезапустить.

Отображение журнала ошибок выглядит вполне нормально

Файл сокета был создан. Репликация MySQL началась нормально. /usr/sbin/mysqld: ready for connections. появляется

Особенно с тех пор, как вы видите /usr/sbin/mysqld: ready for connections., вы должны иметь возможность подключиться к mysql, о котором вы только что заявили.

Ваш процесс mysqld в порядке.

Ошибка может исходить от /etc/init.d/mysql но не раньше, чем mysqld сделает все, что ему нужно.

Если ты заглянешь внутрь /etc/init.d/mysql есть две линии

[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 &

Если /etc/init.d/mysql время истекло, это определенно произошло после этих двух строк.

Вот код, который проверяет файл 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() вызывается после запуска 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=$?

В худшем случае mysqld работает без файла pid. В свете этого, service mysql stop и /etc/init.d/mysql stop может работать некорректно, поскольку он проверяет, знает ли файл pid идентификатор процесса mysqld.

Без файла pid правильным способом завершения работы mysqld является

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

ПРЕДОСТЕРЕЖЕНИЕ

Это не та местность явления. Я видел, как это происходит и со стандартными двоичными файлами MySQL.

Была точно такая же проблема на debian. Сервер действительно запускается, но сценарий инициализации сообщает, что он не работает:

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

тогда как my.cnf, скорее всего, настроен на

/var/lib/mysql/mysql.sock

Убедитесь, что путь сокета и pid в my.cnf указывает на то, что установлено в

/etc/mysql/debian.cnf

Также не забудьте указать mysqld, а не mysql

Я знаю, что это немного устарело, но это 30 апреля 2015 года, и у нас была такая же проблема с Percona 5.6.

Функция start /etc/init.d/mysql имеет следующее (начиная с 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

Нашему серверу обычно требуется около 40-70 секунд для запуска (инициализация пула буферов innodb размером 97 ГБ занимает около 35 секунд), поэтому, естественно, «start» сообщает, что он «мертв», поскольку файл сокета еще не создан.

Я только что увеличил значение «10», и это сработало для меня.

Ура