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