too many connections code 1040 что это
[Перевод] Подключение MySQL после ошибки 1040: слишком много соединений
И снова ERROR 1040…
Ситуация уже сама по себе проблема для конечных пользователей, но если еще при этом у вас нет доступа к серверу для диагностики и исправления причины, все становится совсем плохо. Обычно приходится завершать экземпляр и перезапускать его, чтобы восстановить.
Root-пользователь тоже не может подключиться! Почему?!
В правильно настроенной среде пользователь с привилегией SUPER сможет получить доступ к экземпляру и диагностировать причину ошибки 1040, из-за которой не хватает соединений. Это описано в руководстве:
Но куча людей дают привилегии SUPER своим пользователям приложения или скрипта — из-за требований приложения (опасно!) или незнания последствий, а потом зарезервированное соединение занимает обычный пользователь, а административный пользователь (обычно root ) не может подключиться.
Как гарантировать доступ к экземпляру
Можно использовать хорошо известный хак с GDB, который советовал Ауримас лет 100 назад для ошибки 1040, но теперь есть решения получше. Правда сначала их надо включить.
С Percona Server 5.5.29 и выше и MySQL 8.0.14 и выше можно настроить еще один порт с дополнительным числом соединений. Приложение не будет использовать эти интерфейсы. Они только для администраторов баз данных и агентов мониторинга и проверки работоспособности (см. примечание ниже).
Настройка Percona Server
Для примера я занял все подключения к порту обычных пользователей у экземпляра, где уже настроил extra_port и extra_max_connections в my.cnf :
Кстати, extra_port удален в Percona Server 8.0.14 и выше, поскольку в MySQL Community реализован admin_port с теми же функциями. Так что отредактируйте my.cnf при апгрейде до Percona Server 8.0.14 или выше, если вы уже определили extra_port.
Настройка в MySQL Community
Как я уже сказал, для этого нужен MySQL 8.0.14, где применен WorkLog 12138.
Чтобы включить админский интерфейс, нужно определить admin_addres, который должен быть единственным и уникальным (без подстановочных символов) IPv4, IPv6, IPv4-сопоставленным адресом или именем хоста, по которому админский интерфейс будет ожидать передачи данных. Если эта переменная не определена, интерфейс не включен.
Наконец, можно настроить create_admin_listener_thread (отключено по умолчанию), который создает отдельный поток для обработки входящих соединений. Это может пригодиться в некоторых ситуациях.
Еще одно различие — в документации Oracle сказано, что:
Число административных соединений не ограничено.
(А у нас значение по умолчанию — 1). Не уверен, что это значит, но я бы был осторожен, чтобы случайно не установить 1 млн соединений. Они, конечно, не ограничены, но ресурсы-то все равно потребляют.
Использование для мониторинга и проверок работоспособности
Скрипты мониторинга смогут извлекать данные для диаграмм, чтобы потом вы разобрались, откуда столько соединений. А скрипты проверки работоспособности будут докладывать об ухудшившемся состоянии сервера, и определенный код может указывать, что соединений много, но сервер справляется (то есть может разобраться сам и лучше чуть дольше подождать до отработки отказа).
Обязательно устанавливайте только по одному соединению за раз для мониторинга и проверки работоспособности, чтобы не забивать extra_max_connections в Percona Server и не создать миллион потоков в MySQL. То есть скрипты не должны подключаться снова, если предыдущий запрос или подключение к базе данных еще активны.
Для Percona Server 8.0.14 и выше процесс будет тем же, что и для MySQL Community.
Помогите! Мне нужно войти, но все порты заняты!
Если это та самая причина, по которой вы читаете этот пост, используйте безумный хак с GDB (без обид, Ауримас, просто выглядит рисково :-D) или завершите экземпляр. К счастью, экземпляр почти всегда можно аккуратно завершить с помощью SIGTERM (-15) вместо SIGKILL (-9). Так сервер выполнит чистую остановку, и у потоков будет шанс нормально завершить работу. Просто следуйте инструкциям:
2) Отправьте SIGTERM в этот PID:
3) Следите в журнале ошибок, как выполняется завершение работы. Это будет выглядеть примерно так:
Это означает начало процесса завершения работы. Экземпляр будет завершен, когда вы увидите подобную строку:
Ошибка MySQL — Error 1040 Too many connections
Обычно превышением количества соединений проявляется как прекративший работать сайт. Ошибку можно увидеть попробовав подключиться к базе данных с реквизитами пользователя, от имени которого работает сайт.
Enter password:
ERROR 1040 (08004): Too many connections
От имени суперпользователя подключиться удастся в случае если сайт работает не от root.
Лимит существует для пользователя, если сайт работает от root (что именно из-за этого является плохой практикой) и появилась такая ошибка — требуется перезагрузка MySQL.
Интересно в данном случае значение актуальное директивы max_user_connection
+——————-+——-+
| Variable_name | Value |
+——————-+——-+
| Threads_connected | 151 |
+——————-+——-+
1 row in set (0.01 sec)
А также действующий лимит
show global variables like ‘%connections%’;
+———————-+——-+
| Variable_name | Value |
+———————-+——-+
| max_connections | 151 |
| max_user_connections | 0 |
+———————-+——-+
2 rows in set (0.00 sec)
Лимит достигнут, скрипты при этом продолжают делать запросы. Исправить ситуацию можно добавив в /etc/mysql/my.cnf такую строку
max_user_connection=500
Затем перезапустив MySQL
Без перезапуска того же результата можно добиться установив новое значение глобальной переменной, от имени root в консоли MySQL это делается таким образом:
set global max_connections = 500;
Лимит теперь увеличен и сайт должен вновь стать доступен. Часто причиной является большая активность аудитории и длительные запросы на изменение данных. Они протекают с блокировками, если используются таблицы типа MyISAM получить значительное улучшение можно конвертировав их в InnoDB.
ошибка 1040
Сегодня появилась первый раз ошибка 1040:
Too many connections
Please contact server administrator
С чем это связано и как ее решить? Сайт не работает ((
Вчера ставили последние обновления шопскрипта, добавляли товары. В код никаких изменений не вносили
12 ответов
Ошибка говорит о том, что сервер баз данных на вашем хостинге перегружен. Если используете сторонний хостинг — по этому поводу следует обратиться в службу поддержки хостинга. Если хостинг наш — имеет смысл написать индивидуальный запрос в службу технической поддержки из вашего Центра заказчика:
webasyst.ru/my/
Периодически повторяется данная ошибка #1040, хостер nic.ru Недлю назад отписали:
Наши специалисты предприняли все возможные меры, чтобы снизить период недоступности сервисов.
В настоящее время все сервисы и оборудование хостинга функционируют в штатном режиме.
Сейчас снова повторяется.. Началось 2 недели назад.
Подскажите как удалось решить проблему ошибка #1040 с хостером nic.ru?
Последнее время нас достала данная проблема.
Аналогичная ситуация. Началось примерно пару месяцев назад. Иногда появляется когда админка просто открыта. Хостер уверяет, что с его стороны проблем нет. Хостинг Beget. Подскажите, смог ли кто разобраться с данной проблемой?
У хостера заявлен лимит в 50. Но почему тогда возникает ошибка и в состоянии простоя просто при открытой админке? И почему несколько лет до этого работало всё нормально %(
Если предположить, что это проблема хостера, то есть ли какой способ выявить это и доказать им? Ошибка всегда не предсказуемая, появляется в любой момент и снова всё Ок.
У нас сегодня началось тоже самое и хостинг тот же Beget
Периодически повторяется данная ошибка #1040, хостер nic.ru.
Отчего зависит не понятно. Проявляться начала примерно 2 месяца назад. Обращения в хостер nic.ru ни к чему не привели. Типа слишком много подключений к базе данных.
Главное проявление ее совсем не логично. Может появиться ночью часа в 2, когда нет пользователей. И в тоже время сайт может работать прекрасно во время максимальной нагрузки.
Может есть какое-то решение.
Здравствуйте,такая же проблема.Кто нибудь нашел решение?
Вам везет)) Я уже 2 месяца по ночам такое ловлю. Хостер Timeweb ложится все ок)
Неполадки с базой данных
При работе с базами данных могут встречаться ошибки. Ниже перечислены частые ошибки и меры по их диагностике и устранению.
Недоступность базы данных
Необходимо подключиться к серверу по SSH и выполнить следующие проверки:
1. Проверить, запущена ли служба MySQL:
Пример вывода для запущенной службы:
Если в выводе отсутствует слово running, служба не запущена. В этом случае необходимо попытаться ее запустить:
После этого надо проверить работу сайта и сделать следующую проверку, если ошибка сохраняется.
2. Проверить состояние дискового пространства.
Просмотреть общий и занятый объем на диске командой:
Доступное пространство должно быть на основном разделе. Если свободное пространство закончилось, необходимо освободить место или перейти на тариф выше. Для работы с дисковым пространством можно использовать утилиты ncdu или du.
Если на диске достаточно свободного места, но ошибка сохраняется, надо проверить состояние inodes.
Если не удается решить ошибку самостоятельно, то нужно обратиться в техническую поддержку.
Повреждены таблицы БД (Table is marked as crashed)
Если на сервере установлен phpMyAdmin, можно выполнить восстановление с его помощью. Для этого необходимо:
Без phpMyAdmin можно выполнить необходимые действия при подключении по SSH. Для восстановления одной таблицы нужно выполнить команду:
Для восстановления всех таблиц в базе используется команда:
Также можно выполнить проверку всех таблиц в базе с помощью команды:
Ошибка 2006: MySQL server has gone away
Ошибка MySQL server has gone away означает, что сервер закрыл соединение. Это происходит, как правило, в двух случаях: превышение таймаута ожидания или получение сервером слишком большого пакета.
В обоих случаях для устранения ошибки потребуется внести правки в конфигурационный файл MySQL. Это делается при подключении к серверу по SSH или с помощью веб-консоли в панели управления.
Конфигурационный файл может располагаться по различным путям, например:
Чтобы определить, в какой файл необходимо вносить изменения, можно использовать команду вида:
С ее помощью можно выяснить, в каких файлах прописан нужный параметр, и изменить в них его значение.
Чтобы увеличить таймаут ожидания, необходимо скорректировать значение параметра wait_timeout
Нужно открыть конфигурационный файл с помощью редактора, обязательно указав корректный путь к файлу:
Далее нужно изменить значение параметра wait_timeout на более высокое. Значение указывается в секундах: чтобы увеличить время ожидания до 10 минут, необходимо указать значение 600:
После перезапустить службу MySQL:
Скорректировать максимально допустимый размер пакетов можно увеличением параметра max_allowed_packet.
Нужно открыть конфигурационный файл с помощью редактора, обязательно указав корректный путь к файлу:
Дале нужно изменить значение параметра max_allowed_packet на более высокое (значение указывается в мегабайтах):
После перезапустить службу MySQL:
Ошибка 1040: Too many connections
Ошибка «Too many connections» означает, что исчерпан лимит подключений к базе данных. Ошибка связана с медленными запросами, которые выполняются слишком долго (в этом случае требуется оптимизация кода) либо в числе одновременных подключений. В этом случае можно попробовать решить проблему увеличением лимита подключений (параметр max_connections) в конфигурационном файле MySQL.
В пункте выше было описано, как определить расположение файла my.cnf.
Следует открыть конфигурационный файл с помощью редактора, обязательно указав корректный путь к файлу:
И заменить значение параметра на более высокое, например:
max_connections = 200
После перезапустить службу MySQL:
Ошибка 1292: Incorrect date value
При попытке добавить данные в таблицу MySQL без указания даты может выдаваться ошибка:
Из-за этой ошибки может нарушаться работа импорта в 1С.
Для исправления ошибки необходимо:
1.Открыть файл /etc/mysql/my.cnf:
2. В строке, начинающейся с sql-mode=, удалить следующие значения:
NO_ZERO_IN_DATE
NO_ZERO_DATE
STRICT_ALL_TABLES
3. Выполнить перезагрузку mysql-сервера:
Если строка вида sql-mode= отсутствует, необходимо:
Подключение MySQL после ошибки 1040: слишком много соединений
И снова ERROR 1040…
Ситуация уже сама по себе проблема для конечных пользователей, но если еще при этом у вас нет доступа к серверу для диагностики и исправления причины, все становится совсем плохо. Обычно приходится завершать экземпляр и перезапускать его, чтобы восстановить.
Root-пользователь тоже не может подключиться! Почему?!
В правильно настроенной среде пользователь с привилегией SUPER сможет получить доступ к экземпляру и диагностировать причину ошибки 1040, из-за которой не хватает соединений. Это описано в руководстве:
Но куча людей дают привилегии SUPER своим пользователям приложения или скрипта — из-за требований приложения (опасно!) или незнания последствий, а потом зарезервированное соединение занимает обычный пользователь, а административный пользователь (обычно root ) не может подключиться.
Как гарантировать доступ к экземпляру
Можно использовать хорошо известный хак с GDB, который советовал Ауримас лет 100 назад для ошибки 1040, но теперь есть решения получше. Правда сначала их надо включить.
С Percona Server 5.5.29 и выше и MySQL 8.0.14 и выше можно настроить еще один порт с дополнительным числом соединений. Приложение не будет использовать эти интерфейсы. Они только для администраторов баз данных и агентов мониторинга и проверки работоспособности (см. примечание ниже).
Настройка Percona Server
Для примера я занял все подключения к порту обычных пользователей у экземпляра, где уже настроил extra_port и extra_max_connections в my.cnf :
Кстати, extra_port удален в Percona Server 8.0.14 и выше, поскольку в MySQL Community реализован admin_port с теми же функциями. Так что отредактируйте my.cnf при апгрейде до Percona Server 8.0.14 или выше, если вы уже определили extra_port.
Настройка в MySQL Community
Как я уже сказал, для этого нужен MySQL 8.0.14, где применен WorkLog 12138.
Чтобы включить админский интерфейс, нужно определить admin_addres, который должен быть единственным и уникальным (без подстановочных символов) IPv4, IPv6, IPv4-сопоставленным адресом или именем хоста, по которому админский интерфейс будет ожидать передачи данных. Если эта переменная не определена, интерфейс не включен.
Наконец, можно настроить create_admin_listener_thread (отключено по умолчанию), который создает отдельный поток для обработки входящих соединений. Это может пригодиться в некоторых ситуациях.
Еще одно различие — в документации Oracle сказано, что:
Число административных соединений не ограничено.
(А у нас значение по умолчанию — 1). Не уверен, что это значит, но я бы был осторожен, чтобы случайно не установить 1 млн соединений. Они, конечно, не ограничены, но ресурсы-то все равно потребляют.
Использование для мониторинга и проверок работоспособности
Скрипты мониторинга смогут извлекать данные для диаграмм, чтобы потом вы разобрались, откуда столько соединений. А скрипты проверки работоспособности будут докладывать об ухудшившемся состоянии сервера, и определенный код может указывать, что соединений много, но сервер справляется (то есть может разобраться сам и лучше чуть дольше подождать до отработки отказа).
Обязательно устанавливайте только по одному соединению за раз для мониторинга и проверки работоспособности, чтобы не забивать extra_max_connections в Percona Server и не создать миллион потоков в MySQL. То есть скрипты не должны подключаться снова, если предыдущий запрос или подключение к базе данных еще активны.
Для Percona Server 8.0.14 и выше процесс будет тем же, что и для MySQL Community.
Помогите! Мне нужно войти, но все порты заняты!
Если это та самая причина, по которой вы читаете этот пост, используйте безумный хак с GDB (без обид, Ауримас, просто выглядит рисково :-D) или завершите экземпляр. К счастью, экземпляр почти всегда можно аккуратно завершить с помощью SIGTERM (-15) вместо SIGKILL (-9). Так сервер выполнит чистую остановку, и у потоков будет шанс нормально завершить работу. Просто следуйте инструкциям:
2) Отправьте SIGTERM в этот PID:
3) Следите в журнале ошибок, как выполняется завершение работы. Это будет выглядеть примерно так:
Это означает начало процесса завершения работы. Экземпляр будет завершен, когда вы увидите подобную строку: