Обновление Owncloud не выполняется с таймаутом MySQL

Я только что обновился до новой версии Owncloud. После установки .deb пакет, я побежала

sudo -u www-data php /var/www/owncloud/occ upgrade

, которые дали мне:

 oc_appconfig                             
  1/24 [=>--------------------------]   4%DoctrineDBALExceptionDriverException: An exception occurred while executing 'SET unique_checks=1':

SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
Update failed

онлайн-исследование показало, что это, возможно, проблема с таймаутом MySQL, поэтому я создал /etc/mysql/my.cnf следующего содержания:

[mysqld]
interactive_timeout=86400
wait_timeout=86400
max_allowed_packet=521M

затем я перезапустил MySQL и попытался-безрезультатно. В большинстве случаев Шаг 1 терпит неудачу; иногда я добираюсь до шага 3 (Всегда с тем же временем ожидания команды SQL).

ОС Raspbian, работает на Raspberry Pi 3.

что исправит эту проблему?

24
задан user149408
30.01.2023 18:06 Количество просмотров материала 3003
Распечатать страницу

2 ответа

сервер, вероятно, за неправильный или слишком большой пакет. Если mysqld получает пакет, который является слишком большой или неправильной, она предполагает, что что-то пошло ужасно неправильно с клиентом и закрывает соединение. Чтобы исправить это, необходимо увеличить максимальный размер пакета max_allowed_packet в моем.файл cnf, затем перезапустите сервер MySQL: (/etc / init.D / перезапуск mysql).

0
отвечен Overmind 2023-02-01 01:54

сообщение об ошибке

SQLSTATE[HY000]: общая ошибка: 2006 MySQL server ушел

может означать несколько вещей: часто это относится к таймауту, который может быть исправлен путем увеличения значений таймаута (по умолчанию 8 часов), или указывает на то, что был превышен допустимый размер пакета, который может быть исправлен путем увеличения max_allowed_packet. это также происходит, когда сервер MySQL падает в середине операции, так что проверить это когда первые два варианта не дают облегчения.

после некоторого исследования я обратился к журналу MySQL. Там был пустой файл с именем/var/log/mysql.err, а также некоторые файлы, которые указывают на ротацию логов.

Running ps -ef | grep mysql затем дал мне полную командную строку процесса MySQL с параметром для файла журнала, который оказался /var/lib/mysql/<hostname>.err.

изучение этого файла показало, что MySQL продолжал сбой из-за повреждения данных, вероятно, влияя на oc_filecache таблица. Это объясняет, почему обновление не удалось-как восстановить из коррупции будет отдельный вопрос. Строка, отображаемая occ над индикатором выполнения, кажется таблицей, которая обрабатывалась, когда произошла ошибка (если это неясно из журналов MySQL, где нужно посмотреть близко, чтобы найти таблицу).

-1
отвечен user149408 2023-02-01 04:11

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Мы используем cookie. Это позволяет нам анализировать взаимодействие посетителей с сайтом и делать его лучше. Продолжая пользоваться сайтом, вы соглашаетесь с использованием файлов cookie. Политика конфиденциальности
Согласен
Вверх