Как диагностировать (и исправлять) постоянные ошибки mysql с сайта drupal 7 на сервере ubuntu 16?

Я развертываю сайт Drupal 7x на сервере Digital Ocean Ubuntu 16.04 для тестирования и демонстрации. Я переключил версии php сервера с php7 на PHP 5.6, но в остальном использовал версии Mysql и Apache2 по умолчанию. У меня не было проблем с установкой сайта и его функций; однако у меня часто возникают ошибки, связанные с базой данных, в частности, следующая:

PDOException: SQLSTATE[HY000] [2002] Connection refused in lock_may_be_available() (line 167 of /var/www/html/phisigmarho.org/includes/lock.inc).

Обычно я получаю эту ошибку, но я также получаю сообщения об ошибках «на веб-сайте произошла ошибка» или «сервер mysql ушел», когда я делаю что-либо с базой данных или интенсивным процессом (обновление модулей через пользовательский интерфейс и т. д.). Я относительно новый администратор сервера, поэтому я не уверен, что может быть не так или какие журналы я должен искать, чтобы понять, что не так. На данный момент перезапуск MySQL из терминала позволяет мне продолжить настройку сайта, но я не могу позволить кому-либо использовать сайт так, как он есть сейчас.

Итак, как мне понять, почему MySQL продолжает исчезать? Я озадачен, потому что сервер очень похож на мою машину разработки (рабочий стол ubunutu 16 с php5.6), и у меня нет ничего отдаленно похожего. Где мне искать значимые журналы, которые помогут мне диагностировать и исправить это. Итак, идеи?


person nizz0k    schedule 27.12.2016    source источник


Ответы (1)


Вот несколько вещей, которые я бы попробовал в этом сценарии.

  • Установите Drush (если он еще не установлен). Затем посмотрите, что вы получите для следующих команд:

    • drush status - check the site configuration looks correct including the DB connection
    • drush sqlc — вы войдете в командную строку MySQL, используя данные подключения, указанные в settings.php. Стоит убедиться, что это соединение успешно открывается
    • drush cc all — Очистка кеша вашего сайта всегда полезна при переходе на новую среду.
  • Если все еще не работает, я бы обрезал все таблицы cache_* в базе данных Drupal. Я видел ошибки, подобные приведенным выше, и обычной очистки кеша было недостаточно для ее устранения.

  • Убедитесь, что Drupal Watchdog включен. drush en dblog. Затем вы можете просмотреть записи журнала сторожевого таймера, используя Drush, например. drush ws

  • Проверьте журналы PHP. Возможно, вам придется связаться с Digital Ocean для определения местоположения и доступа к ним.

person Scott Anderson    schedule 29.12.2016
comment
это помогло, в итоге проблема с конфигурацией - person nizz0k; 28.01.2017