Часть 2 из 2.
Внимательный читатель задаст вопрос
"Алекс, кого ты лечишь? РДС не даёт рекомендации, если всего полчаса в день отставание, ты что-то упускаешь, кривой ETL не дал бы такой эффект".
Да, всё так.
Починив ELT/DAG, мы поняли, что рекомендация остаётся даже после этого.
Сняли всю информацию, все метрики клоудвоча, аудит логи - не смогли найти причину. Написали в саппорт. Дали все метрики, в том числе аномальные транзакции.
Буквально в 5-6 итераций общения с саппортом и мы поняли, что все были правы - рекомендация по делу триггерится - по метрике, но сама метрика обманывает.
...
Update: root cause of the TransactionAgeMaximum anomaly is confirmed cosmetic
Our Aurora MySQL engineering team completed an end-to-end root-cause analysis of the ~1.77–1.78 billion-second (~56-year) TransactionAgeMaximum readings — the same class of anomaly you identified. The finding is definitive:
1. The anomaly is caused by a race condition in the engine's transaction start-time path on Graviton (ARM) instance classes, specific to the 3.0x.x engine family. In brief, a transaction's start-time is briefly visible to the metric-gathering poller before it is fully initialized, so the poller computes an age against a near-zero epoch — yielding the nonsensical ~56-year value.
2. Engineering traced the code path end-to-end (from the internal gauge, through information_schema, to CloudWatch) and concluded: "Cosmetic metric anomaly only. No actual long-running transaction, no performance or availability impact." They explicitly found no code path that produces a real transaction behind these readings.
...
Yes — it is safe to proceed the upgrade.
Тот дикий "возраст транзакции в 56 лет" оказался реальным, подтверждённым багом Aurora MySQL 3.*.x на Гравитонах. Race condition в коде движка: поллер метрики иногда читает время старта транзакции чуть раньше, чем оно успело проинициализироваться, и считает возраст от почти нулевой эпохи😬. Никакой реальной транзакции за этим не стоит, чистая косметика в метрике.
А вот прямую связь с тем, что база полгода не возвращается к норме, доказать так и не смогли. Слишком много времени прошло. Так и закрыли: корреляция по времени подтверждена, причинность нет, а вердикт практический: purge здоров, текущий уровень не риск, апгрейду быть.
Апгрейд прошёл отлично.
После апгрейда баг с метрикой ушёл.
Так что же в итоге?
Иногда в процессе подготовки агрейда находишь множество не явных вещей:
- не настроен мониторинг/алёртинг RDS рекомендаций и никто на это не смотрит, а в скоуп уведомлений от Amazon Notification Center это не входит
- схемы/диаграммы надо поддерживать
- нет мониторинга/алёртинга RDS/Airflow на долгие транзакции
- баги. Иногда копаешь неделями, а там ты ваще не виноват, это лишь баги
- - -
* Все умные слова для БД, точные запросы, интерпретация ответов была сделана при помощи значительно более умных коллег, у кого больше опыта с БД.
Сам я как был слабый по БД, так и остался.
** Конечно все знают кто это, аудит показывает, но при блеймлесс калча нельзя кого-либо обвинять. 😬