⚙️ Теория
🔄 Streaming replication
PostgreSQL использует WAL (Write-Ahead Log):
- primary пишет WAL;
- standby получает WAL и применяет изменения.
Это основа warm standby и failover.
⚖️ Asynchronous vs Synchronous
Asynchronous:
- ниже latency commit;
- есть риск потери последних транзакций при аварии primary.
Synchronous:
- commit подтверждается после участия standby;
- выше гарантии, но может вырасти latency.
🚨 Failover и Switchover
Failover: аварийное переключение при падении primary.Switchover: плановое переключение без аварии.
Ключевая задача: избежать split-brain и обеспечить контролируемый promotion standby.
⚠️ Типичные ошибки
- считать async репликацию "без потерь";
- не тестировать failover процедурно;
- не мониторить replication lag и WAL retention.
❓ Что нужно уметь объяснить
Почему replication не равна backup?
Репликация копирует текущее состояние и ошибки/удаления, backup нужен для point-in-time recovery и защиты от логических ошибок.
Когда синхронная репликация оправдана?
Когда приоритет у потери данных (RPO≈0), и команда готова платить latency/availability trade-off.
Главный operational риск?
Failover без автоматизированных проверок и fencing-механизмов.
🧪 Практика
1. Проверка репликационного статуса
SELECT application_name, state, sync_state, write_lag, flush_lag, replay_lag
FROM pg_stat_replication;SELECT pg_is_in_recovery();2. Минимальный DR чеклист
- регулярные backup + restore drills;
- метрики lag и алерты на деградацию;
- документированный runbook failover/switchover.
🧾 Вывод
Надежность PostgreSQL строится на ясном выборе async/sync, регулярных тестах failover и обязательной связке replication + backup/restore.