Недавно мы обновили свои сервера с MySQL 5.7 на 8.0.

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

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

Ну и безусловно растёт наше приложение во все стороны — добавляются новые фичи, наворачиваются и усложняются старые, растёт количество клиентов и соответственно количество данных в БД. И в один не очень прекрасный момент приходит понимание, что что-то наше приложение тормозит. А значит надо или найти, что именно нагружает БД, хотя могло бы не нагружать, ну или если ничего такого нет, то взять ещё серверов побольше, да помощнее.

Стандартный совет как найти, что нагружает MySQL — включить slow-query-log и посмотреть, какие запросы будут туда попадать. Но в MySQL 5.7 по умолчанию присутствует куда лучший инструмент — sys schema, которая агрегирует данные из performance schema и позволяет их получить простыми запросами, буквально вида «Ok, MySQL, покажи мне топ запросов по максимальному суммарному времени выполнения»

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

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

КДПВ, она же грабли #1

AWS Lambda — это сервис вычислений, запускающий ваш код при определенных событиях и автоматически управляющий вашими вычислительными ресурсами. Обзор концепции, принципов работы, цен и тому подобного уже есть на хабре ( habrahabr.ru/company/epam_systems/blog/245949 ), я же попробую показать практический пример использования этого сервиса.

Итак, как следует из названия поста, мы будем использовать AWS Lambda для создания архива указанных нами файлов, хранящихся на AWS S3. Поехали!