PostgreSQL на Proxmox VE и Ceph: ресурсы, отказ и восстановление

PostgreSQL сначала сохраняет в WAL сведения, нужные для повторного применения изменения, и только потом может отложенно записать основные страницы. Контроллер и носитель должны честно выполнять запрос устойчивого сброса.

Наличие BBU не доказывает сохранение и последующее воспроизведение данных кэша. Это свойство тракта проверяют отдельно; полные образы страниц WAL решают другую задачу PostgreSQL.

ВМ должна помещаться на каждом узле, куда её разрешено перенести, после вычета резерва гипервизора. Свободные ресурсы, замеченные в один момент, не являются гарантированной резервацией.

Процессор, память и ввод-вывод принимают по счётчикам и хвосту задержки рабочей нагрузки. Схема N+1 должна выдерживать эту нагрузку после отказа одного узла, а не просто содержать ещё один сервер.

Кворум задаёт порог для кластерных решений. Он сам по себе не подтверждает точку данных PostgreSQL и не доказывает, что прежний владелец перестал обращаться к общему диску.

Для HA-управляемых гостей Proxmox VE использует кластерные блокировки и watchdog. Узел, который не вернул связь Corosync с кворумной частью, самоизолируется перезапуском; в испытании подтверждают остановку старого экземпляра до восстановления гостя на другом узле.

Corosync требует устойчивой малой задержки. Высокая скорость сети миграции не доказывает пригодность служебного канала; основной и резервный каналы проверяют отказом и наблюдением состояния кластера.

RBD предоставляет блочное устройство поверх объектов Ceph. Для образа с включённой exclusive-lock после отказа владельца проверяют передачу блокировки и исключение соответствующего клиента, затем выполняют запись и чтение из PostgreSQL.

Параметр size задаёт число копий, min_size — порог доступности ввода-вывода. Состояние active ещё не означает завершённое восстановление, а правило CRUSH определяет допустимые устройства и домены отказа.

После отказа учитывают полезную ёмкость, запас и нагрузку восстановления. Сырая ёмкость и оценка MAX AVAIL сами по себе не отвечают, выдержит ли кластер заявленную нагрузку при восстановлении.

Для синхронной реплики выбирают конкретную резервную сторону и этап подтверждения записи, сброса или применения. Асинхронная реплика может отставать, поэтому фактическое отставание связывают с RPO.

PITR по архиву требует подходящую базовую копию, непрерывную нужную часть WAL и цель до ошибки. Текущая реплика или снимок ВМ отдельно не доказывают наличие этого набора.

Проверяют восстановленное содержимое и предусмотренную операцию клиента. Запущенный процесс PostgreSQL, состояние ВМ или успешное завершение задания резервного копирования сами по себе не закрывают приёмку.

Сценарий точно называет отказ: узел PVE, канал Corosync, OSD или RBD, PostgreSQL либо площадка. До запуска нового экземпляра подтверждают прекращение старой ВМ или её изоляцию; состояние Ceph фиксируют и клиентскую операцию измеряют в заранее согласованном состоянии пула.