Если мастер падает, то резервный сервер должен начать процедуру failover (обеспечения отказоустойчивости).
Если падает резервный сервер, то никаких действий предпринимать не надо. Если резервный сервер может быть перезапущен, даже спустя некоторое время, то процесс восстановления может быть немедленно возобновлён. Если же перезапустить резервный сервер не возможно, то тогда нужно использовать другой резервный сервер.
Если мастер падает и резервный сервер становится новым мастером, а затем перезапускается старый мастер, то у Вас должен быть механизм, который бы сообщил старому мастеру, что он уже не является основным сервером. Чаще всего это называется STONITH (Shoot The Other Node In The Head - Выстрел Другому Узлу в Голову - ВДрУГ ;) ), что необходимо для того, чтобы избежать ситуаций, где два узла действовали бы как мастера, что привело бы к проблемам и потере информации.
Многие системы обеспечения отказоустойчивости используют только две системы - мастер и резервный сервер, которые соединены каким-то механизмом, который контролирует наличие соединения между обоими системами и жизнеспособность мастера. Кроме того, можно использовать третью систему ("мудрый" сервер), который позволит избежать некоторых случаев отказа, но его использование оправдано лишь при наличии достаточного внимания к настройке и скрупулёзном тестировании.
PostgreSQL не предоставляет системы ПО, которая бы определяла падение мастера и сообщала об этом резервному серверу. Есть множество систем, которые для этого можно использовать и которых хорошо интегрированы со средствами ОС, необходимыми для обеспечения отказоустойчивости, такими как миграция IP.
После того, как происходит переход на резервный сервер, у Вас есть только один действующий сервер. Это называется "вырожденное" состояние, так как бывший резервный сервер теперь мастер, а бывший мастер выключен и может оставаться в таком состоянии. Чтобы вернуться к нормальной системе, Вы должны пересоздать резервный сервер, либо на бывшем мастере после его ремонта, либо на третей, возможно новой, системе. После этого Вы можете захотеть поменять роли серверов. Некоторые используют третий сервер в качестве резерва для нового мастера, пока не сделают новый резервный сервер, однако это усложняет настройку системы и её обслуживание.
Таким образом переключение с мастера на резервный сервер может быть быстрым, но требует некоторой подготовки отказоустойчивого кластера. Периодическое переключение с мастера на резервный сервер полезно, так как предоставляет время для обслуживания каждого из серверов. Кроме того, это позволяет проверить механизм обеспечения отказоустойчивости и убедиться, что он и вправду будет работать, когда это понадобится. Очень желательно, чтобы все действия администратора на этот случай были так же письменно зафиксированы.
Для того, чтобы активировать резервный сервер в случае аварии при использовании пересылки логов, используйте pg_ctl promote или создайте триггер-файл с именем и по адресу, указанным в параметре trigger_file файла recovery.conf. Если Вы собираетесь использовать команду pg_ctl promote, то параметр trigger_file не нужен. Он так же не нужен, если Вы будете использовать резервные сервера только для снятия нагрузки с мастера за счёт выполнения на них только запросов на чтение, а не для обеспечения отказоустойчивости.
