Признаюсь и я, и команда из этого проекта были откровенно слабыми.
Я категорически слабо разбирался в базах данных, тюнинге, а на проекте никто не понимал что происходит.
База "тупила", клиенты были недовольны, никто не понимал куда копать.
Мы, словно угля в топку, накидывали неделя за неделей ресурсами всё выше и выше, лишь бы поезд ехал, но все понимали, что рано или поздно мы упрёмся в максимум типа инстанса и поезд остановится.
Откровенно говоря я даже не понимал как вот это всё работает, замучав всех в русскоязычных чатах глупыми вопросами по БД перформансу.
Так или иначе я пришёл к мнению, что надо внедрять мониторинг и алёртинг базы данных.
- Мы научились готовить PMM(расширенный бесплатный аналог AWS Performance Insights).
Он нам показал исторически на графиках куча мест, где у нас было сделано не оптимально(селекты, делиты и так далее).
- Мы научились мониторить стандартные метрики БД.
CPU usage, memory free/usage и другие системные ресурсы.
- Этого было мало, мы научились мониторить и алёртить сложные запросы.
Мне пришлось нырнуть дальше и у нас появились борды с MySQL slow query и алёртинг на их.
На правах внезапного репоста этого блога продублирую ссылку на свою статью, как мониторить/алёртить
AWS RDS slow logs (8.0.mysql_aurora.3.06.0), которую я писал в 2024 году.https://medium.com/@kruchkov.alexandr/monitoring-and-alerting-for-slow-logs-in-amazon-rds-12dd048e16db
* Помню, что медиум это для многих неудобно, но я уже не вспомню зачем я публикую заметки именно там.
#AWS #RDS