6c6939a473
Партиционирование 7 audit-таблиц применено на боевой liderra.ru 23.05.2026.
Закрывает ПОСЛЕДНЮЮ (7-ю) дыру аудита журналирования — эпик завершён.
* `db/migrations/2026_05_23_hole2_partition_audit_tables.sql` — фактический
rewrite-SQL применённый на проде (источник истины = pg_dump прода, НЕ schema.sql):
- 7 таблиц → PARTITION BY RANGE (created_at|received_at), PK→(id, partition_key)
- 6 месячных партиций _yYYYY_mMM (m02..m07) + DEFAULT на таблицу
- FK на webhook_log удалены (W1)
- SET session_replication_role=replica при копировании → исходные log_hash
сохранены as-is (НЕ пересчёт): иначе триггер под postgres BYPASSRLS построил
бы global-within-partition chain ≠ per-tenant chain прода → false breach
- RLS tenant_isolation + оба триггера (audit_chain_hash + audit_block_mutation)
+ sequences + GRANT'ы воспроизведены из реального pg_dump прода
- retention seeds в формате команды: partition_retention_months_<table>
* Метод деплоя (max-safety, клиент info@lkomega.ru не пострадал):
- РЕПЕТИЦИЯ на liderra_rehearsal (restore прод-dump) ДО боя — counts/lkomega-t2/
chain-fingerprints совпали байт-в-байт, audit:verify-chains intact
- На боевом: backup pre-partitioning-20260523-162357.dump → apply в транзакции →
verify (counts 414/275/34/9/4, lkomega t2 414/275 цел, 7×7 партиций) →
partitions renamed _YYYY_MM→_yYYYY_mMM → retention keys → verify-chains intact
rc=0 → portal HTTPS 200
* ПИЛОТ.md §6 п.11 — #2 ✅ + известные нюансы (create-months под app-роль / schema.sql drift)
* tracker — все 7 дыр ✅, эпик завершён
NB: db/schema.sql разошёлся с реальным продом по колонкам 4 таблиц
(activity_log/webhook_log/balance_transactions/pd_processing_log) — прод-rewrite
построен из pg_dump прода. Ресинхронизация schema.sql↔prod — отдельная задача.
Phase A (tooling: VerifyAuditChains per-partition + PartitionsDropExpired +
MonthlyPartitionManager whitelist + schema.sql v8.31) уже на main (60ab5be3).