AWS, читающий экземпляры реплик mysql, продолжает получать ошибку «Слишком много подключений»

Я купил один VPC на AWS и инициировал там 6 баз данных MySql, и для каждой из них я создал реплику чтения, чтобы я всегда мог быстро выполнять запросы к репликам чтения.

Большую часть дня мои записывающие экземпляры (исходные экземпляры) полностью загружены, а их процент загрузки ЦП составляет в основном 99%. Тем не менее, реплики чтения показывают что-то ~ 7-10% использования ЦП, но иногда я получаю сообщение об ошибке, когда запускаю службу, подключающуюся к реплике чтения «СЛИШКОМ МНОГО ПОДКЛЮЧЕНИЙ».

Я не очень разбираюсь в AWS, но происходит ли это из-за того, что реплики записи полностью загружены и находятся в том же VPC?


mysql amazon-web-services vpc mysql-error-1064 aws-vpc
person Ahmad Al- Hashlamoun    schedule 02.04.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

это происходит из-за того, что реплики записи полностью загружены и находятся в том же VPC?

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

Эта проблема просто означает, что к реплике подключается больше клиентов, чем разрешено группой параметров на основе типа вашего экземпляра RDS. Используйте запрос SELECT @@MAX_CONNECTIONS;, чтобы узнать, каков этот предел. Используйте SHOW STATUS LIKE 'THREADS_CONNECTED';, чтобы увидеть, сколько подключений существует в настоящее время, и используйте SHOW PROCESSLIST; (в качестве администратора или любого пользователя, имеющего привилегию PROCESS), чтобы увидеть, что делают все эти подключения.

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

person Michael - sqlbot    schedule 02.04.2017