Runbook: `DeadlockSpike`

Source of truth: tools/observability/alerts/angarabase_alerts.yaml. Backed by: RM-0.6.3.8 S7, RM-0.6.4.4 (SSI).

Что означает

rate(angarabase_deadlock_detected_total[1m]) > 1 — детектор deadlock’ов сработал чаще одного раза в минуту. Один-два deadlock’а в час — нормально; spike указывает на проблемный workload pattern.

Для SERIALIZABLE транзакций: всплеск ошибок 40001 (serialization_failure) может выглядеть как deadlock spike в логах приложения, но имеет другую природу (rw-антизависимости). См. метрику angarabase_ssi_aborts_total.

Severity

critical. Deadlock = aborted transaction = потенциальная потеря работы клиента. Для SSI: 40001 — штатный механизм, но высокий rate требует анализа contention.

Initial response

Grafana Overview v2 → row “Locks”.
Проверить, какие таблицы участвуют в spike (см. лог сервера на сообщения deadlock detected: ...).
Сопоставить с recent deploy / migration — новый workload?

Diagnostics

curl -sf http://127.0.0.1:9898/metrics | rg -E 'lock_|deadlock'
journalctl -u angarabase-server -n 500 | rg -i 'deadlock'

# Активные блокировки (если есть совместимый view)
psql -c "SELECT * FROM angara_stat_locks WHERE granted = false;"

Mitigation

Причина	Действие
Разные порядки lock acquisition	Унифицировать порядок (UPDATE по PK ASC) в коде клиента
Long-running txn держит lock	См. LongTransaction
Hot row contention	Шардирование счётчика; sequence вместо UPDATE
Конкретный код — обновить	Откатить deploy, исправить, redeploy

Escalation

Если spike не утихает > 15 минут — это блокирует бизнес-операции, эскалировать срочно.

AngaraBook