Отработка отказа
Эта страница переведена при помощи нейросети GigaChat.
Если основной сервер выходит из строя, то резервный сервер должен начать процедуры отработки отказа.
Если резервный сервер выходит из строя, то отказоустойчивость не требуется. Если резервный сервер может быть перезапущен, даже некоторое время спустя, то процесс восстановления также может быть немедленно возобновлен с использованием восстанавливаемого восстановления. Если резервный сервер не может быть перезапущен, то следует создать новый экземпляр резервного сервера.
Если основной сервер выходит из строя и резервный сервер становится новым основным, а затем старый основной перезапускается, должна быть возможность сообщить старому основному устройству, что оно больше не является основным. Это иногда называют STONITH (Shoot The Other Node In The Head, «Выстрелите в голову другому узлу»), что необходимо для предотвращения ситуаций, когда обе системы думают, что они являются основными, что приведет к путанице и, в конечном счете, потере данных.
Многие системы отказоустойчивости используют всего две системы, основную и резервную, связанные каким-то механизмом сердцебиения для постоянного проверки связи между двумя системами и жизнеспособности основного устройства. Также возможно использовать третью систему (называемую сервером свидетеля) для предотвращения некоторых случаев неправильного отказа, но дополнительная сложность может не стоить того, если она настроена без должной тщательности и строгого тестирования.
PostgreSQL не предоставляет системное программное обеспечение, необходимое для определения сбоя на основном устройстве и уведомления сервера базы данных-резервной копии. Существует множество таких инструментов, которые хорошо интегрированы с функциями операционной системы, необходимыми для успешного переключения при отказе, такими как перенос IP-адреса.
После переключения на резервный сервер работает только один сервер. Это состояние называется вырожденным состоянием. Бывший резервный сервер теперь является основным, но бывший основной сервер отключен и может оставаться таковым. Чтобы вернуться к нормальной работе, необходимо воссоздать резервный сервер либо на бывшей основной системе при ее запуске, либо на третьей, возможно новой, системе. Утилита pg_rewind может использоваться для ускорения этого процесса в больших кластерах. После завершения работы первичный и резервный серверы могут считаться поменявшими роли. Некоторые люди предпочитают использовать третий сервер для обеспечения резервного копирования нового основного сервера до тех пор, пока не будет воссоздан новый резервный сервер, хотя очевидно, что это усложняет конфигурацию системы и операционные процессы.
Если выбрать синхронизацию слота логической репликации (см. раздел Синхронизация слотов репликации), перед переключением на резервный сервер рекомендуется проверить готовность логических слотов, синхронизированных на резервном сервере, к отказоустойчивости. Это можно сделать, выполнив шаги, описанные в разделе Отказоустойчивость логической репликации.
Чтобы инициировать отказоустойчивое переключение резервного сервера с потоковой передачей журналов, выполните команду pg_ctl promote или вызовите функцию pg_promote(). Если настраивать серверы отчетности, используемые исключительно для разгрузки запросов только для чтения с основного сервера, а не для целей высокой доступности, не нужно повышать уровень.