Я использую PostgreSQL 9.1 с потоковой репликацией для аварийного переключения и WAL для архивирования.
Если я использую archive_command директиве конфигурации на моем резервном сервере он всегда будет терпеть неудачу (поскольку сегменты WAL, которые он пытается заархивировать, уже заархивированы мастером), поэтому я использую пустой archive_command на резервном сервере.
Проблема в том, что мой главный сервер не работает, а резервный сервер становится новым главным, архивирование прекращается. Есть ли способ узнать в сценарии archive_command, работает ли сервер в основном режиме?
Я могу сделать archive_command скрипт, который возвращает 0, если файл с именем сегмента, который я пытаюсь заархивировать, уже существует, но я не уверен, что это правильное поведение для archive_command.
Ваши инстинкты верны - вроде того.
Напишите команду архивирования, которая определяет, является ли локальный сервер Postgres в настоящее время главным (простой способ: подключиться и выполнить SELECT pg_is_in_recovery(); - Если правда, ты на рабе).
Если вы обнаружите, что находитесь на главном сервере, архивируйте сегменты обычным образом.
Если вы обнаружите, что находитесь на подчиненном сервере, ничего не делайте и завершите работу.
Вышеупомянутый трюк работает, потому что вы не можете подключиться к мастеру, который находится в (аварийном) восстановлении. Единственный раз, когда вы сможете подключиться к серверу Postgres, который находится в режиме восстановления, - это когда вы подключились к ведомому устройству с потоковой передачей. репликация.
После аварийного переключения ваше ведомое устройство станет главным (и больше не будет в режиме восстановления), так что ваши сценарии архивирования WAL смогут делать свое дело.
Все в порядке: PostgreSQL на резервном сервере работает в режиме восстановления, поэтому операции WAL отключены.