Ошибка соединения too many connections

Время на прочтение
4 мин

Количество просмотров 16K

И снова ERROR 1040…

Техподдержка получает много жалоб на эту печально известную ошибку: ERROR 1040: Too many connections — слишком много соединений. Проблема очевидна: приложение или пользователи создают больше соединений, чем допускает сервер, то есть текущее число соединений превышает значение переменной max_connections.

Ситуация уже сама по себе проблема для конечных пользователей, но если еще при этом у вас нет доступа к серверу для диагностики и исправления причины, все становится совсем плохо. Обычно приходится завершать экземпляр и перезапускать его, чтобы восстановить.

Root-пользователь тоже не может подключиться! Почему?!

В правильно настроенной среде пользователь с привилегией SUPER сможет получить доступ к экземпляру и диагностировать причину ошибки 1040, из-за которой не хватает соединений. Это описано в руководстве:

mysqld разрешает max_connections + 1 клиентских соединений. Дополнительное соединение зарезервировано для аккаунтов с привилегиями SUPER. Когда эти привилегии предоставляются администраторам, а не обычным пользователям (которым они и не нужны), администратор, у которого есть еще и привилегия PROCESS, может подключиться к серверу и использовать SHOW PROCESSLIST, чтобы диагностировать проблемы, даже если подключено максимальное число клиентов без привилегий.

Но куча людей дают привилегии SUPER своим пользователям приложения или скрипта — из-за требований приложения (опасно!) или незнания последствий, а потом зарезервированное соединение занимает обычный пользователь, а административный пользователь (обычно root) не может подключиться.

Как гарантировать доступ к экземпляру

Можно использовать хорошо известный хак с GDB, который советовал Ауримас лет 100 назад для ошибки 1040, но теперь есть решения получше. Правда сначала их надо включить.
С Percona Server 5.5.29 и выше и MySQL 8.0.14 и выше можно настроить еще один порт с дополнительным числом соединений. Приложение не будет использовать эти интерфейсы. Они только для администраторов баз данных и агентов мониторинга и проверки работоспособности (см. примечание ниже).

Настройка Percona Server

Начиная с Percona Server 5.5.29 можно просто добавить extra_port в my.cnf, и при следующем перезапуске порт будет доступен и будет ожидать данные по тому же bind_address, что и обычные соединения. Если не настроить переменную extra_port, дополнительного порта по умолчанию не будет.

Еще можно определить extra_max_connections, чтобы задать количество подключений, которое будет обрабатывать этот порт. Количество по умолчанию — 1.

Для примера я занял все подключения к порту обычных пользователей у экземпляра, где уже настроил 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 8.0.14, где применен WorkLog 12138.

Чтобы включить админский интерфейс, нужно определить admin_addres, который должен быть единственным и уникальным (без подстановочных символов) IPv4, IPv6, IPv4-сопоставленным адресом или именем хоста, по которому админский интерфейс будет ожидать передачи данных. Если эта переменная не определена, интерфейс не включен.

Еще можно определить порт, но это не обязательно. По умолчанию это порт 33062. Если этот порт свободен, это значение не нужно настраивать. Если настраиваете, то поместите обе переменные в раздел [mysqld] в my.cnf.

Наконец, можно настроить create_admin_listener_thread (отключено по умолчанию), который создает отдельный поток для обработки входящих соединений. Это может пригодиться в некоторых ситуациях.

Еще одно различие — в документации Oracle сказано, что:

Число административных соединений не ограничено.

(А у нас значение по умолчанию — 1). Не уверен, что это значит, но я бы был осторожен, чтобы случайно не установить 1 млн соединений. Они, конечно, не ограничены, но ресурсы-то все равно потребляют.

Использование для мониторинга и проверок работоспособности

Удобно, что не только люди могут использовать дополнительный интерфейс или порт в экстренной ситуации, когда мы достигли max_connections. К нему может подключиться система мониторинга и проверки работоспособности прокси/балансировщика нагрузки/обнаружения сервисов.

Скрипты мониторинга смогут извлекать данные для диаграмм, чтобы потом вы разобрались, откуда столько соединений. А скрипты проверки работоспособности будут докладывать об ухудшившемся состоянии сервера, и определенный код может указывать, что соединений много, но сервер справляется (то есть может разобраться сам и лучше чуть дольше подождать до отработки отказа).

Обязательно устанавливайте только по одному соединению за раз для мониторинга и проверки работоспособности, чтобы не забивать extra_max_connections в Percona Server и не создать миллион потоков в MySQL. То есть скрипты не должны подключаться снова, если предыдущий запрос или подключение к базе данных еще активны.

Вот тот же пример, но с MySQL.

Для Percona Server 8.0.14 и выше процесс будет тем же, что и для MySQL Community.

Помогите! Мне нужно войти, но все порты заняты!

Если это та самая причина, по которой вы читаете этот пост, используйте безумный хак с GDB (без обид, Ауримас, просто выглядит рисково :-D) или завершите экземпляр. К счастью, экземпляр почти всегда можно аккуратно завершить с помощью SIGTERM (-15) вместо SIGKILL (-9). Так сервер выполнит чистую остановку, и у потоков будет шанс нормально завершить работу. Просто следуйте инструкциям:

1) Получите PID:

marcos.albe in ~/ pgrep -x mysqld;
650

2) Отправьте SIGTERM в этот PID:

marcos.albe in ~/ kill -15 650;

3) Следите в журнале ошибок, как выполняется завершение работы. Это будет выглядеть примерно так:

2019-07-11T13:43:28.421244Z 0 [Note] Giving 0 client threads a chance to die gracefully
2019-07-11T13:43:28.521238Z 0 [Note] Shutting down slave threads
2019-07-11T13:43:28.521272Z 0 [Note] Forcefully disconnecting 0 remaining clients

Это означает начало процесса завершения работы. Экземпляр будет завершен, когда вы увидите подобную строку:

2019-07-11T13:43:31.292836Z 0 [Note] /opt/percona_server/5.7.26/bin/mysqld: Shutdown complete

При работе с базами данных могут встречаться ошибки. Ниже перечислены частые ошибки и меры по их диагностике и устранению.

• Недоступность базы данных
• Повреждены таблицы БД (Table is marked as crashed)
• Ошибка 2006: MySQL server has gone away
• Ошибка 1040: Too many connections
• Ошибка 1292: Incorrect date value

Недоступность базы данных

Необходимо подключиться к серверу по SSH и выполнить следующие проверки:

1. Проверить, запущена ли служба MySQL:

service mysql status

Пример вывода для запущенной службы:

Если в выводе отсутствует слово running, служба не запущена. В этом случае необходимо попытаться ее запустить:

service mysql start

После этого надо проверить работу сайта и сделать следующую проверку, если ошибка сохраняется.

2. Проверить состояние дискового пространства.

Просмотреть общий и занятый объем на диске командой:

df -h

Доступное пространство должно быть на основном разделе. Если свободное пространство закончилось, необходимо освободить место или перейти на тариф выше. Для работы с дисковым пространством можно использовать утилиты ncdu или du.

Если на диске достаточно свободного места, но ошибка сохраняется, надо проверить состояние inodes.

Если не удается решить ошибку самостоятельно, то нужно обратиться в техническую поддержку.

Повреждены таблицы БД (Table is marked as crashed)

При возникновении ошибок вида «Warning: Table … is marked as crashed» необходимо выполнить восстановление таблиц.

Если на сервере установлен phpMyAdmin, можно выполнить восстановление с его помощью. Для этого необходимо:

1. перейти в интерфейс PMA,
2. выбрать нужную базу данных в меню слева,
3. отметить в списке таблицы, которые нужно восстановить — то есть таблицы, имена которых фигурируют в ошибках,
4. в самом низу страницы нажать на выпадающее меню «С отмеченными» и выбрать вариант «Восстановить».

Без phpMyAdmin можно выполнить необходимые действия при подключении по SSH. Для восстановления одной таблицы нужно выполнить команду:

mysqlcheck -r имя_базы имя_таблицы -uroot -p

Для восстановления всех таблиц в базе используется команда:

mysqlcheck -r имя_базы -uroot -p

Также можно выполнить проверку всех таблиц в базе с помощью команды:

mysqlcheck -r -A -uroot -p

Ошибка 2006: MySQL server has gone away

Ошибка MySQL server has gone away означает, что сервер закрыл соединение. Это происходит, как правило, в двух случаях: превышение таймаута ожидания или получение сервером слишком большого пакета.

В обоих случаях для устранения ошибки потребуется внести правки в конфигурационный файл MySQL. Это делается при подключении к серверу по SSH или с помощью веб-консоли в панели управления.

Конфигурационный файл может располагаться по различным путям, например:

/etc/my.cnf
/etc/mysql/my.cnf
/etc/mysql/mysql.conf.d/mysqld.cnf

Чтобы определить, в какой файл необходимо вносить изменения, можно использовать команду вида:

grep -Rl ‘имя_параметра’ /etc/*

Например:
grep -Rl ‘wait_timeout’ /etc/*

или:
grep -Rl ‘max_allowed_packet’ /etc/*

С ее помощью можно выяснить, в каких файлах прописан нужный параметр, и изменить в них его значение.

Таймаут

Чтобы увеличить таймаут ожидания, необходимо скорректировать значение параметра wait_timeout

Нужно открыть конфигурационный файл с помощью редактора, обязательно указав корректный путь к файлу:

nano /etc/mysql/my.cnf

Далее нужно изменить значение параметра wait_timeout на более высокое. Значение указывается в секундах: чтобы увеличить время ожидания до 10 минут, необходимо указать значение 600:

wait_timeout = 600

После перезапустить службу MySQL:

service mysql restart

Размер пакетов

Скорректировать максимально допустимый размер пакетов можно увеличением параметра max_allowed_packet.

Нужно открыть конфигурационный файл с помощью редактора, обязательно указав корректный путь к файлу:

nano /etc/mysql/my.cnf

Дале нужно изменить значение параметра max_allowed_packet на более высокое (значение указывается в мегабайтах):

max_allowed_packet = 64M

После перезапустить службу MySQL:

service mysql restart

Ошибка 1040: Too many connections

Ошибка «Too many connections» означает, что исчерпан лимит подключений к базе данных. Ошибка связана с медленными запросами, которые выполняются слишком долго (в этом случае требуется оптимизация кода) либо в числе одновременных подключений. В этом случае можно попробовать решить проблему увеличением лимита подключений (параметр max_connections) в конфигурационном файле MySQL.

В пункте выше было описано, как определить расположение файла my.cnf.

Следует открыть конфигурационный файл с помощью редактора, обязательно указав корректный путь к файлу:

nano /etc/mysql/my.cnf

И заменить значение параметра на более высокое, например:

max_connections = 200

После перезапустить службу MySQL:

service mysql restart

Ошибка 1292: Incorrect date value

При попытке добавить данные в таблицу MySQL без указания даты может выдаваться ошибка:

ERROR 1292 (22007): Incorrect date value: ‘0000-00-00’ for column ‘columnname’ at row 1

Из-за этой ошибки может нарушаться работа импорта в 1С.

Для исправления ошибки необходимо:

1.Открыть файл /etc/mysql/my.cnf:

nano /etc/mysql/my.cnf

2. В строке, начинающейся с sql-mode=, удалить следующие значения:

NO_ZERO_IN_DATE

NO_ZERO_DATE

STRICT_ALL_TABLES

3. Выполнить перезагрузку mysql-сервера:

sudo service mysql restart

Примечание:

Если строка вида sql-mode= отсутствует, необходимо:

1. В файл /etc/mysql/my.cnf после параметра [mysqld] добавить строку:

sql-mode=»ONLY_FULL_GROUP_BY,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION»

2. Выполнить перезагрузку mysql-сервера:

sudo service mysql restart
 

<<<
Назад

ERROR 1040 (HY000): Too many connections
pi@majordomo:~$ ERROR 1040 (HY000): Too many connections

перезапуск базы данных
sudo systemctl restart mysql

запускаем консоль бд с админскими правами

sudo mysql

смотрим текущие значения счетчиков соединений

show status like ‘%onn%’;

0

Если вам нужно увеличить MySQL Connections без перезапуска MySQL, сделайте, как показано ниже, также, если вы не знаете файл конфигурации, ниже используйте mysqlworkbench или phpmyadmin или командную строку для запуска запросов ниже.

mysql> show variables like ‘max_connections’;
+——————+——-+
| Variable_name | Value |
+——————+——-+
| max_connections | 151 |
+——————+——-+
1 row in set (0.00 sec)

mysql> SET GLOBAL max_connections = 250;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like ‘max_connections’;
+——————+——-+
| Variable_name | Value |
+——————+——-+
| max_connections | 250 |
+——————+——-+
1 row in set (0.00 sec)
Эти настройки изменятся при перезагрузке MySQL.

Для постоянных изменений добавьте строку ниже в my.cnf и перезапустите MySQL.

max_connections = 151
выходим

Если ошибка через какое-то время повторится — ищем, кто лезет в базу и не рвет соединения.

Обсуждение (1)

(3)

Иногда Вы можете сталкиваться с такой проблемой, что при открытии сайта возникает ошибка: «MySQL error: Too many connections», давайте поговорим о значении этой ошибки, причинах и методах ее устранения.

Что значит ошибка «MySQL error: Too many connections»

Итак, если при входе на сайт Вы видите надпись «MySQL error: Too many connections», то в большинстве случаев это говорит о том, что сайт превысил лимит на количество одновременных соединений к серверу баз данных MySQL. В остальных случаях это может говорить о превышении второго лимита, т.е. лимита на общее количество одновременных подключений к MySQL.

Для справки. Первый лимит регулируется параметром max_user_connections, а второй лимит — max_connections.

Если речь идет о ВЕБ хостинге с mysql, то возникновение ошибки по причине превышения лимита max_connections практически не возможно, поэтому такая ошибка будет возникать только на одном сайте,
даже если у Вас несколько сайтов на одном аккаунте, за исключением ситуаций, когда для всех баз данных указан один пользователь.

Если мы говорим о VDS хостинге или выделенном сервере, то здесь все зависит от настроек сервера MySQL. В том случае, если у Вас max_user_connections не значительно меньше max_connections, равно
или превышает этот параметр, то сбой в работе БД одного сайта повлияет на работу остальных сайтов.

Причины ошибки «MySQL error: Too many connections»

Мы будем рассматривать причины возникновения данной ошибки, только опираясь верную настройку сервера MySQL (о правильной настройке поговорим чуть ниже).

Самой распространенной причиной возникновения ошибки «Too many connections» является ошибка в коде сайта. Зачастую программисты пишут не оптимизированный код работы с БД, это может быть, как
отсутствие закрытий подключений к БД, так и тяжелые запросы, которые выполняются слишком медленно при высокой посещаемости сайта. В результате чего лимит max_user_connections переполняется, и
сервер выдает ошибку.

Второй причиной возникновения ошибки является DDOS-атака на сайт. В результате одновременного вызова большого количества страниц сервер БД не успевает обработать все запросы и выдает ошибку:
«MySQL error: Too many connections».

Третьей причиной ошибки, которая на ВЕБ хостинге почти не достижима (а для сервера и хостинга VDS встречается чаще), является общая нагрузка на сервер БД MySQL.

Методы устранения «MySQL error: Too many connections»

Основным методом устранения ошибки «MySQL error: Too many connections», конечно же, является оптимизация скриптов сайта, так как именно эта причина вызывает чаще всего данную ошибку. Также для каждой БД
мы рекомендуем создавать отдельного пользователя, это позволит изолировать сайты друг от друга.

Если же речь идет об атаке на сайт, то есть два варианта решения проблемы: временное отключение сайта, либо использование услуги защиты от DDOS-атак.

Следующий пункт — общая нагрузка на сервер БД. Если используется услуга ВЕБ хостинга, то решить эту проблему самостоятельно Вы не сможете. В этом случае нужно обратиться в техническую
поддержку хостинг-провайдера.

Говоря о хостинге VDS или выделенном сервере, здесь, прежде всего, нужно проверить, что установленный лимит max_user_connections значительно меньше значения max_connections. Также нужно
обратить внимание на общую нагрузку на VDS (сервер), если VDS (сервер) не справляется с нагрузкой, то количество одновременных подключений будет расти, что в итоге приведет к превышению лимитов.
Стоит обратить внимание и на настройку сервисов VDS (сервера), если какой-то сервис можно оптимизировать, выделив больше ресурсов для MySQL, то это следует незамедлительно выполнить. Если
наличие свободных ресурсов позволяет увеличить значение max_user_connections и max_connections, то это также нужно сделать.

В случае отсутствия навыков решения проблемы «MySQL error: Too many connections» Вы всегда можете обратиться в нашу компанию и заказать администрирование сайта или сервера, что поможет
исправить данную проблему в минимальные сроки.