PostgreSQL: резервное копирование с минимальным временем восстановления
Предположим что у нас есть кластер postgresql работающий в режиме потоковой репликации. Есть master-сервер и горячий hot-standby готовый в любой момент стать полноценным мастером. Таким образом у нас реализована отказоустойчивая связка, в которой в случае выхода из строя мастера, горячий hot-stnadby заменить погибшего товарища. При плохом развитии событий, нам остается только создать trigger-файл и переключить наши приложения на работу с новым мастером. И стало все хорошо.
Известно что природа потоковой репликации устроена так, что изменения прошедшие в мастере, должны оказаться на подчиненном узле как можно быстрее. Выходит что, подчиненный узел представляет собой (почти полную) копию мастера. Это очень хорошо в случае немедленного восстановления на момент предшествующий сбою. Однако, возможны ситуации когда вполне легитимные изменения были сделаны на стороне приложения и попали как на мастер, так и на подчиненный сервер. Например, были удалены/изменены данные в части таблиц или же таблицы были вовсе удалены. С точки зрения базы данных ничего фатального не произошло, а с точки зрения бизнеса - произошла катастрофа. В таком случае провозглашение горячего hot-standby в мастера, процедура явно бесполезная...
