Кратко: цель — быстро определить, какие транзакции и узлы заблокированы, собрать артефакты (снимки состояния, логи), аккуратно разблокировать/откатывать транзакции через средства СУБД или координатора 2PC, минимизировав потерю данных и риск рассогласования.
Диагностика (что проверить и какие артефакты собрать)
- Собрать метаданные и логи прежде чем форсить изменения: дамп состояния блокировок, список подготовленных 2PC-транзакций, бинарные логи/redo/WAL, журналы координатора.
- Проверить кто держит блокировки и кто ждёт:
- PostgreSQL: `pg_locks`, `pg_stat_activity`, `pg_prepared_xacts`.
- MySQL/InnoDB: `INFORMATION_SCHEMA.INNODB_TRX`, `SHOW ENGINE INNODB STATUS`, `performance_schema`.
- Oracle: `v$transaction`, `v$session`, `dba_2pc_pending`.
- Для распределённых БД (CockroachDB, Yugabyte, Vitess, Galera): служебные команды/статус кворума, логи консенсуса (raft/paxos), список глобальных транзакций.
- Проверить состояние координатора 2PC/XA: жив ли, отвечает ли, есть ли подготовленные (prepared) транзакции без финального COMMIT/ROLLBACK.
- Проверить сетевые и системные причины: partition, высокие задержки/потери пакетов, дисковое пространство, блокировка I/O, нагрузка CPU/memory, репликационный лаг.
- Визуализация: метрики блокировок/латентности из Prometheus/Grafana, трассировка запросов (APM).
- Оценить возраст блокирующих транзакций: если транзакция висит дольше чем $...$ (например $...$ минут), повышается риск «завоздушивания» ресурсов — фиксируйте значение.
Инструменты (примеры)
- CLI/SQL: описанные выше системные представления и show-команды.
- 2PC/XA: `COMMIT PREPARED 'gid'` / `ROLLBACK PREPARED 'gid'` (Postgres), `XA RECOVER` / `XA ROLLBACK` (MySQL).
- Управление сессиями: `pg_cancel_backend(pid)`, `pg_terminate_backend(pid)`; в MySQL `KILL `.
- Логи координатора транзакций или middleware (transaction manager).
- Снэпшоты/бэкапы: filesystem snapshot, logical dump, копии бинарных логов/WAL.
- Мониторинг/трейсинг: Prometheus, Grafana, ELK, Jaeger.
Безопасная процедура восстановления (пошагово)
1) Сбор артефактов (не менять состояние)
- Создать снимок/бэкап node/instance и скопировать логи транзакций и координатора.
- Экспортировать список активных и подготовленных транзакций.
2) Попытки мягкой разблокировки
- Попросить приложение/клиента корректно завершить транзакцию (retry/rollback).
- Отправить `pg_cancel_backend` / `KILL` для долгих запросов (сначала cancel, затем terminate если не помогло).
- Для подготовленных 2PC: если известно, что координатор успешно закоммитил на других участниках — выполнить `COMMIT PREPARED 'gid'`. Если известно, что координатор откатил — `ROLLBACK PREPARED 'gid'`.
3) Принятие решения при отсутствии координатора/информации
- Оценить вероятность того, что транзакция была зафиксирована на части участников. Сценарии:
- Низкий риск данных (готовность отката): предпочитаем откат (abort) заблокированных prepared-транзакций.
- Высокий риск уже выполненных изменений на других нодах: предпочитаем commit после тщательной проверки логов/бинарных журналов.
- Документировать принятые решения и сохранять все исходные артефакты.
4) Принудительный откат/коммит как крайняя мера
- Использовать стандартные команды `ROLLBACK PREPARED`/`COMMIT PREPARED` или `XA ROLLBACK`/`XA COMMIT`.
- Если приходится убивать backend-процессы — сначала graceful cancel, затем terminate; после terminate выполнить проверку согласованности и репликации.
5) Восстановление кворума/консенсуса для распределённой СУБД
- Для систем на raft/paxos: вернуть достаточное число нод для кворума; при необходимости последовательно перезапускать ноды в контролируемом порядке.
- Не восстанавливать старые ноды без очистки состояния, если они могли быть отставшими: синхронизировать реплику (rebuild) или resync.
6) Валидация после разблокировки
- Проверить согласованность данных: контрольные суммы, application-level checks, проверка внешних ключей, целостности.
- Просмотреть репликационный лаг и убедиться, что реплики догнали мастер.
- Наблюдать метрики и запросы в течение стабилизации ($...$ минут/часов в зависимости от нагрузки).
7) Постмортем и меры предотвращения
- Проанализировать корень причины: таймауты, long-running queries, утечки транзакций в приложении, нехватка ресурсов, баг в координаторе.
- Внедрить автоматические таймауты: максимальная длительность транзакции, автоматический откат prepared после $...$ часов если политика позволяет.
- Улучшить мониторинг и playbook для быстрого реагирования.
Рекомендации по минимизации потерь данных и риску рассогласования
- Всегда собирать артефакты перед вмешательством.
- При сомнении отдавать предпочтение откату подготовленных транзакций, если нет явного доказательства коммита на других участниках.
- В распределённых системах ориентироваться на логи координатора и бинарные журналы участников — они дают источник истины.
- Настроить alerting по долгим транзакциям и подготовленным 2PC, а также health-check координатора.
Короткий чеклист для экстренной операции
- Сделать snapshot/копию логов.
- Экспортировать active/prepared транзакции.
- Попытаться graceful cancel/rollback.
- При подготовленных 2PC: решить commit vs rollback на основании логов/координатора.
- Принудительно завершить только после бэкапа и документирования.
- Проверить согласованность и восстановить реплики.
Если нужен — могу привести конкретные команды для вашей СУБД (Postgres/MySQL/Oracle/Cockroach) и пример playbook для экстренного восстановления.