Автоматическое масштабирование AWS Aurora приводит к неправильным аргументам mysqld_stmt_execute - PullRequest
5 голосов
/ 09 июля 2019

Мы используем AWS Aurora (RDS без сервера) в нашей производственной среде.Он должен масштабироваться от 2 единиц емкости (4 ГБ ОЗУ) до 8 единиц емкости (16 ГБ ОЗУ).

За последние 2 месяца наша база данных никогда не масштабировалась автоматически, она работала в минимальной емкости.На прошлой неделе из-за увеличения использования системы автоматическое масштабирование начало срабатывать каждые несколько минут.В дневное время он масштабировался от 4 до 8 единиц емкости.

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

Итак, мы предположили, что причиной может быть автоматическое масштабирование, и мы сохранили одинаковые единицы емкости для min (8) и max (8), чтобы избежать масштабирования.Таким образом, масштабирование не произошло, и мы не получили эту ошибку снова.Итак, мы подтвердили, что ошибка была вызвана автоматическим масштабированием.На самом деле, автоматическое масштабирование помогло нам снизить стоимость, но, к сожалению, вызывает ошибку.

Мы не понимаем, почему эта ошибка возникает во время масштабирования.Может кто-нибудь объяснить, почему масштабирование вызывает эту проблему и как ее избежать?

Или это связано с проблемой пула соединений?Я поднял его и в проекте пула подключений.

https://github.com/brettwooldridge/HikariCP/issues/1407

1 Ответ

0 голосов
/ 19 июля 2019

Это проблема с кэшированием подготовленных операторов.Когда новые серверы подготовлены для масштабирования и когда кешированные подготовленные операторы запускаются на новых серверах, MySQL выдает эту ошибку.Итак, мы отключили подготовленные кеши операторов , и мы больше не получаем ошибку.

Хотя это работает, мы не можем кэшировать подготовленные операторы, которые могут отставать от небольшой производительности.На данный момент это нормально, поскольку мы не заметили отставание.

...