#mysql #ubuntu #symphony-cms
#mysql #ubuntu #symphony-cms
Вопрос:
Недавно мы обновили нашу базу данных MySQL с 5.7 до 8.0 и изменили все параметры сортировки с latin на utf8 mb4.
В основном все прошло очень хорошо, и это устранило проблему, которую мы пытались решить. Но это создало еще одну проблему, которую мы просто не понимаем.
У нас очень длинный запрос в базе данных, который требует 65 соединений (не спрашивайте, я знаю, что это ужасно, мы находимся в процессе разработки, но пока мы застряли с этим).
Способ, которым мы заставили его работать на 5.7, заключался в том, чтобы создать запрос с 60 объединениями, а затем другой с 5 объединениями, а затем объединить результаты каждого вместе.
После обновления первый запрос (с 60 объединениями) больше не выполняется. Вместо этого мы получаем «код ошибки 2013: потерянное соединение с сервером MySQL во время запроса». Эта ошибка возникает сразу (через 0,2 секунды) после выполнения запроса. Другие запросы, похоже, выполняются нормально.
Мы попробовали обычные вещи, которые рекомендуются для этой ошибки
- увеличить время ожидания соединения
- увеличить максимально допустимый размер пакета
- увеличить время ожидания чистого чтения
- увеличить размер пула буферов innodb
- запуск обновления mysql
Но не повезло.
У нас есть обходной путь, который заключается в уменьшении количества объединений. Таким образом, вместо 60 объединений и 5 объединений у меня 40 объединений и 25 объединений. В этом случае я могу заставить оба запроса работать нормально. Интересно, что разделение объединений на 50/15 по-прежнему не работает.
Но обходной путь не помогает мне понять, что происходит не так, потому что запрос 60 join все равно должен работать, даже если это уродливый запрос. Поэтому я нервничаю по поводу выполнения обновления на нашем реальном сервере, если только я не могу быть уверен, что эта проблема не свидетельствует о какой-то более серьезной проблеме.
Проблемный запрос здесь https://www.codepile.net/pile/nN4XG6N4
РЕДАКТИРОВАТЬ Я только что заметил кое-что еще интересное. На сервере, где мы обновились до MySQL8.0, у нас немного другая конфигурация
table_open_cache = 2000
open_files_limit = 1048576
Но на сервере MySQL5.7 (где запрос выполняется без ошибок) конфигурация
table_open_cache = 3495
open_files_limit = 10000
Я поднял это из-за некоторых предупреждений в журнале ошибок во время выполнения
2021-12-09T12:35:11.722898Z 0 [Предупреждение] [MY-010140] [Сервер] Не удалось увеличить количество файлов max_open_file более чем до 10000 (r $ 2021-12-09T12:35:11.722915Z 0 [Предупреждение] [MY-010142] [Сервер] Изменены ограничения: table_open_cache: 3495 (запрошено 4000)
Помогает ли это предоставить дополнительную информацию?
ДРУГОЕ РЕДАКТИРОВАНИЕ
Это было не так, мы увеличили эти настройки, чтобы они соответствовали. Мы перестали получать предупреждения, но это не решило проблему.
Комментарии:
1. просто чтобы убедиться, что вы были здесь ‘Максимальное количество таблиц, на которые можно ссылаться в одном соединении, равно 61. Это включает в себя объединение, обрабатываемое путем объединения производных таблиц и представлений в предложении FROM во внешний блок запроса ‘ dev.mysql.com/doc/refman/8.0/en/join.html
2. Привет, спасибо за предложение P.Salmon, но я не думаю, что это проблема. Подзапрос, содержащий только 60 таблиц, а также только 50, не выполняется. Еще до того, как я попытался объединить его со второй частью запроса, чтобы увеличить его до 65 таблиц.
3. вы должны установить
table_open_cacheте же настройки или, возможно, даже установитьtable_open_cacheзначение 4000, как указано в журнале.4. Спасибо, Луук, извините, я должен был упомянуть об этом в своем сообщении. Мы установили его на 4000. К сожалению, это не помогло.
Ответ №1:
Итак, мы нашли решение!
Мы обновили следующее, и теперь оно работает.
ubuntu: с 16.04 по 20.04.
Mysql: 8.0.25@ubuntu16 чтобы 8.0.27@ubuntu20 .
PHP: Php7.0@ubuntu16 на Php@ubuntu20
Комментарии:
1. Обновление PHP не должно иметь значения
2. Спасибо, Мартин, да, я уверен, что вы правы. Мы думаем, что, скорее всего, это было обновление MySQL, которое имело значение. Возможно, это была ошибка в 8.0.25. или, возможно, что-то в старой версии Ubuntu, что требует совместимости с более новыми версиями MySQL.