klink0v (klink0v) wrote,
klink0v
klink0v

Category:

Багофича с recovery_min_apply_delay (PostgreSQL)

Допустим, мы хотим иметь так называемый "запаздывающий slave" PostgreSQL в качестве одной из степеней защиты от человеческого фактора (DROP DATABASE и иже с ними). Эта такая штука, которая забирает с мастера Write-Ahead Logs (WAL) сразу, а применяет с отсрочкой. Таким образом, при обнаружении "опаньки" по этим WAL-ам можно откатиться до любого момента времени на протяжении интервала, заданного в директиве "recovery_min_apply_delay".

Что делаем.


  1. На мастере создаем отдельный replication slot (слот репликации).

  2. Цепляем к нему slave "как обычно".

  3. На slave в конфиге выставляем "recovery_min_apply_delay" столько, сколько нам надо. Например, "12h".

  4. Можно сделать slave в варианте "hot_standby", но тогда он потребует выделить ему такие же вычислительные ресурсы, как и мастеру (max_parallel_workers, max_connections и всё вот это вот). Можно не делать hot_standby, тогда он обойдется минимум ресурсов.

  5. Запускаем slave.

Вроде как всё хорошо, радуемся. Но есть косяк. Если мы перезапустим slave (например, зачем-то понадобилось перезагрузить машину), то он перестанет забирать с master-а WAL-ы до тех пор, пока не истечет интервал времени "recovery_min_apply_delay". Казалось бы, какая разница, где именно будут лежать WALы: на мастере или на slave? Но она всё-таки есть.


  • Мы могли не рассчитывать и не закладывать на мастере объем дисков, потребный для хранения WALов на протяжении, скажем, суток. Самый распространенный случай: бэкапилка с дешевыми шпиндельными дисками и прод-сервер с дорогими SSD. При таком раскладе нам намного выгоднее содержать WALы именно на slave, а не на мастере.

  • А вдруг мастер физически помрёт? Если WAL-ы будут на slave, то мы без проблем восстановим данные. А если на мастере, то они там помрут вместе с ним.

  • Если прикручен мониторинг а-ля Zabbix+Mamonsu, то он начинает орать благим матом о том, что replication slot на мастере стал неактивным.

Пока что, по мотивам вот этого вопроса на StackOverflow я выхожу из ситуации так.


  1. Комментирую (удаляю) в конфиге параметр "recovery_min_apply_delay".

  2. Шлю процессу postgres сигнал SIGHUP.

  3. Возвращаю в конфиг "recovery_min_apply_delay".

  4. Снова шлю постгресу SIGHUP.

Но это же капец костыли.

Вот думаю, наверное надо бы зарепортить этот кейс в багтрекер разработчикам. Только пока что я не уверен в том, что это именно баг, а не фича.

Tags: it, грабли, датабазы, ссылки, трудовыебудни
Subscribe

  • Вдогонку про IPSec

    Вдогонку к предыдущему посту. Я разобрался в чём косяк. В IKEv2 появилась новая фича: так называемый "childless IKE_SA" (RFC6023). Это…

  • Очередные грабли с IPSec (StrongSWAN + Juniper + IKEv2)

    Во время строительства очередного IPSec-а опять традиционно походил по граблям. Потерял кучу времени и замудохал саппорт одного хостинг-провайдера.…

  • Мелкий наброс насчет Linux-дистрибутивов

    Мелкий холиварчик на тему Linux-дистрибутивов. Все нижеизложенное является исключительно моим личным мнением. У меня иногда спрашивают какой мой…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 1 comment