Если основной сервер выходит из строя, то резервный сервер должен начать процедуры аварийного переключения.

Если резервный сервер выходит из строя, то не требуется переключение на другой сервер. Если резервный сервер может быть перезапущен, даже спустя некоторое время, то процесс восстановления также может быть немедленно перезапущен, с использованием возможности перезапуска восстановления. Если резервный сервер не может быть перезапущен, то должен быть создан полностью новый экземпляр резервного сервера.

Если основной сервер выходит из строя и резервный сервер становится новым основным, а затем старый основной сервер перезапускается, необходим механизм, который сообщит старому основному серверу, что он больше не является основным. Это иногда называется STONITH (Shoot The Other Node In The Head), что необходимо для предотвращения ситуаций, когда оба системы считают себя основными, что приведет к путанице и, в конечном итоге, потере данных.

Многие системы отказоустойчивости используют всего две системы: основную и резервную, соединенные неким механизмом проверки связи между ними и работоспособности основной системы. Также возможно использование третьей системы (называемой сервером-свидетелем) для предотвращения некоторых случаев неправильного переключения, но дополнительная сложность может оказаться нецелесообразной, если не установлена с достаточной осторожностью и проведенным тщательным тестированием.

Tantor BE не предоставляет системное программное обеспечение, необходимое для обнаружения сбоя на основном сервере и уведомления резервного сервера базы данных. Существует множество таких инструментов, которые хорошо интегрированы с требуемыми операционной системой средствами для успешного переключения, такими как миграция IP-адреса.

После переключения на резервный сервер остается только один работающий сервер. Это называется состоянием деградации. Бывший резервный сервер теперь является основным, но бывший основной сервер вышел из строя и может оставаться неработоспособным. Чтобы вернуться к нормальной работе, необходимо создать резервный сервер, либо на бывшей основной системе при ее восстановлении, либо на третьей, возможно новой, системе. Утилита pg_rewind может использоваться для ускорения этого процесса на больших кластерах. После завершения этого процесса можно считать, что основной и резервный серверы поменялись ролями. Некоторые люди выбирают использование третьего сервера для обеспечения резервного копирования нового основного сервера до того, как будет создан новый резервный сервер, хотя это, очевидно, усложняет конфигурацию системы и операционные процессы.

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

Чтобы инициировать переключение на резервный сервер с логической репликацией, выполните pg_ctl promote или вызовите pg_promote(). Если вы настраиваете серверы отчетности, которые используются только для разгрузки запросов только на чтение с основного сервера, а не для целей высокой доступности, вам не нужно выполнять повышение.