Міграція та hardening production-кластера PostgreSQL + Patroni на Ubuntu з відновленням реплікації та налаштуванням бекапів

Початкова ситуація
Зараз використовується PostgreSQL 14 в production для SaaS (мультіарендність, до 1200 rps у піку, ~900 ГБ даних). Кластер 3 вузла (2x primary/standby + witness) на Ubuntu 20.04 у Hetzner Cloud, управління Patroni+etcd. Після серії інцидентів помічені: періодичні failover зі split-brain, відставання репліки до 20-40 хвилин, barman-бекапи іноді биті, а оновлення ОС та Postgres відкладалися. Планується перехід на Ubuntu 22.04 та PostgreSQL 16 з мінімальним простоєм, плюс наведення порядку у спостережуваності та безпечній експлуатації.

Технічне середовище
- 3 VM (Hetzner Cloud), NVMe, мережа 1 Gbps
- Ubuntu 20.04 -> 22.04
- PostgreSQL 14 -> 16
- Patroni, etcd, HAProxy
- barman для PITR
- Prometheus + node_exporter вже є, postgres_exporter місцями налаштований
- Доступ: SSH за ключом, обмеження за часом простою - не більше 10 хвилин на фінальному перемиканні

Завдання та очікуваний результат
1) Провести аналіз поточної конфігурації HA (Patroni/etcd/HAProxy/Postgres) та виявити причини split-brain та лагів реплікації. Зафіксувати знайдені проблеми та запропоновані зміни у короткому звіті.
2) Підготувати план та виконати міграцію на PostgreSQL 16 та Ubuntu 22.04 із збереженням Patroni-кластера та прозорим перемиканням для додатків через HAProxy.
3) Налаштувати бекапи та перевірку відновлення так, щоб було гарантовано PITR та регулярну валідацію бекапів.
4) Посилити безпеку та експлуатаційну надійність: обмеження мережного доступу, коректні параметри kernel/limits, ротація логів, базові заходи hardening без фанатизму.
5) Привести моніторинг стану, коли можна вимірно бачити lag реплікації, стан failover, заповнення дисків, тривалі транзакції і зростання WAL.

Обмеження
- Не можна змінювати додаток та схему БД (тільки серверна частина та параметри Postgres/Patroni/HAProxy).
- Не можна використовувати managed DB, все залишається на поточному провайдері.
- Доступ до продакшену обмежений: роботи у прайм-тайм тільки читання та діагностика, зміни та перемикання – за погодженим вікном.
- Документація має бути зрозумілою інженеру, який супроводжуватиме систему після завершення робіт.

Критерії приймання (вимірювані)
- Фінальне перемикання на новий primary вкладається в 10 хвилин загального на сервіс.
- Реплікація в штатному режимі: lag standby < 5 секунд при середньому навантаженні (за метриками) та без накопичення WAL.
- Виключено split-brain: коректне налаштування quorum/ttl/loop_wait/retry_timeout та перевірка сценарію втрати мережі/вузла на стенді або у погодженому вікні.
- Бекапи: щоденний full або basebackup та безперервний archiving WAL, успішна тестова процедура PITR з відновленням в окрему VM до заданого часу.
- Моніторинг: в Prometheus доступні метрики Postgres (включаючи replication lag, WAL, long running queries), є мінімум 5 алертів (диск, лаг, недоступність вузла, зростання помилок, зупинка бекапів).
- Передача артефактів: актуальні конфіги Patroni/HAProxy/Postgres, інструкції з оновлення та аварійного відновлення, список виконаних змін.

Етапи виконання
- Аудит та фіксація поточного стану, збір метрик та логів, діагностика інцидентів.
- Проектування цільової схеми та плану міграції з відкатом.
- Розгортання нових VM, перенесення конфігурацій, налаштування Patroni/etcd/HAProxy.
- Міграція даних (pg_basebackup/pg_upgrade чи узгоджений метод), прогін перевірок.
- Налаштування barman та тест PITR.
- Налаштування моніторингу та алертів, фінальна перевірка та передача документації.

Професійні інструменти, які знадобляться
- patronictl, etcdctl, psql, pgBackRest або barman, pgbench (або аналог для прогонки), Prometheus exporters, tcpdump/ss, journald/rsyslog, Ansible (бажано) для відтворюваності.

Важливо
Потрібна робота саме руками в інфраструктурі, з аналізом та акуратною міграцією, а не загальна консультація.