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

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

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

Многие системы отработки отказа используют только два узла — основной и резервный, — соединенные механизмом контроля доступности («heartbeat») для непрерывной проверки связности между ними и работоспособности основного узла. Для предотвращения случаев ложного срабатывания механизмов отработки отказа возможно использование третьей системы (так называемого следящего сервера), однако такая дополнительная сложность может быть неоправданной без тщательной настройки и всестороннего тестирования.

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

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

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

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

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