Допустим, мы хотим иметь так называемый "запаздывающий slave" PostgreSQL в качестве одной из степеней защиты от человеческого фактора (DROP DATABASE и иже с ними). Эта такая штука, которая забирает с мастера Write-Ahead Logs (WAL) сразу, а применяет с отсрочкой. Таким образом, при обнаружении "опаньки" по этим WAL-ам можно откатиться до любого момента времени на протяжении интервала, заданного в директиве "recovery_min_apply_delay".
Что делаем.
- На мастере создаем отдельный replication slot (слот репликации).
- Цепляем к нему slave "как обычно".
- На slave в конфиге выставляем "recovery_min_apply_delay" столько, сколько нам надо. Например, "12h".
- Можно сделать slave в варианте "hot_standby", но тогда он потребует выделить ему такие же вычислительные ресурсы, как и мастеру (max_parallel_workers, max_connections и всё вот это вот). Можно не делать hot_standby, тогда он обойдется минимум ресурсов.
- Запускаем slave.
Вроде как всё хорошо, радуемся. Но есть косяк. Если мы перезапустим slave (например, зачем-то понадобилось перезагрузить машину), то он перестанет забирать с master-а WAL-ы до тех пор, пока не истечет интервал времени "recovery_min_apply_delay". Казалось бы, какая разница, где именно будут лежать WALы: на мастере или на slave? Но она всё-таки есть.
- Мы могли не рассчитывать и не закладывать на мастере объем дисков, потребный для хранения WALов на протяжении, скажем, суток. Самый распространенный случай: бэкапилка с дешевыми шпиндельными дисками и прод-сервер с дорогими SSD. При таком раскладе нам намного выгоднее содержать WALы именно на slave, а не на мастере.
- А вдруг мастер физически помрёт? Если WAL-ы будут на slave, то мы без проблем восстановим данные. А если на мастере, то они там помрут вместе с ним.
- Если прикручен мониторинг а-ля Zabbix+Mamonsu, то он начинает орать благим матом о том, что replication slot на мастере стал неактивным.
Пока что, по мотивам вот этого вопроса на StackOverflow я выхожу из ситуации так.
- Комментирую (удаляю) в конфиге параметр "recovery_min_apply_delay".
- Шлю процессу postgres сигнал SIGHUP.
- Возвращаю в конфиг "recovery_min_apply_delay".
- Снова шлю постгресу SIGHUP.
Но это же капец костыли.
Вот думаю, наверное надо бы зарепортить этот кейс в багтрекер разработчикам. Только пока что я не уверен в том, что это именно баг, а не фича.
