Вопросы Теги

Percona-сервер испытывает таймаут на/etc/init.d/mysql, запускаются

reprepro является хорошим инструментом, но это - вероятное излишество для того, что Вы делаете. Я рекомендовал бы смотреть на способный-utils пакет. Это содержит инструмент, склонный-ftparchive, который идеально подходит для поддержания довольно размерного внутреннего репозитория.

Посмотрите здесь для всех опций и ссылок на хорошие практические руководства.

6
задан 14 December 2012 в 21:28
4 ответа

Журнал ошибок выглядит нормально

Файл сокета создан Репликация MySQL началась просто отлично / usr / sbin / mysqld: готов к подключению. появляется

В частности, поскольку вы видите / usr / sbin / mysqld: готов к подключению. , вы должны иметь возможность подключиться к 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. В свете этого служба mysql stop и / etc / init. d / mysql stop может работать некорректно, поскольку он проверяет, знает ли файл pid идентификатор процесса mysqld.

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

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

CAVEAT

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

3
ответ дан 3 December 2019 в 00:29

Похоже, что сценарий инициализации проверяет работающий сервер 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 сценарии инициализации ожидают. О мастере,

3
ответ дан 3 December 2019 в 00:29

Была точно такая же проблема на 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

0
ответ дан 3 December 2019 в 00:29

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

Файл /etc/init.d/mysql 'start' функция имеет следующее (начальный 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», и это сработало для меня.

Ура

0
ответ дан 3 December 2019 в 00:29

Теги

Похожие вопросы