25.2. Трансляция журналов на резервные серверы
- 25.2.1. Планирование
- 25.2.2. Работа резервного сервера
- 25.2.3. Подготовка главного сервера для работы с резервными
- 25.2.4. Настройка резервного сервера
- 25.2.5. Потоковая репликация
- 25.2.6. Слоты репликации
- 25.2.7. Каскадная репликация
- 25.2.8. Синхронная репликация
- 25.2.9. Непрерывное архивирование на резервном сервере
Постоянная архивация может использоваться для создания кластерной конфигурации высокой степени доступности (HA) с одним или несколькими резервными серверами, способными заменить ведущий сервер в случае выхода его из строя. Такую реализацию отказоустойчивости часто называют тёплый резерв или трансляция журналов.
Ведущий и резервный серверы работают совместно для обеспечения этой возможности, при этом они связаны опосредованно. Ведущий сервер работает в режиме постоянной архивации изменений, в то время как каждый резервный сервер работает в режиме постоянного приёма архивных изменений, получая файлы WAL от ведущего. Для обеспечения этой возможности не требуется вносить изменения в таблицы БД, поэтому администрировать данное решение репликации проще, чем ряд других. Так же такая конфигурация относительно слабо влияет на производительность ведущего сервера.
Непосредственную передачу записей WAL с одного сервера БД на другой обычно называют трансляцией журналов (или доставкой журналов). PostgreSQL реализует трансляцию журналов на уровне файлов, передавая записи WAL по одному файлу (сегменту WAL) единовременно. Файлы WAL (размером 16 МБ) можно легко и эффективно передать на любое расстояние, будь то соседний сервер, другая система в местной сети или сервер на другом краю света. Требуемая пропускная способность при таком подходе определяется скоростью записи транзакций на ведущем сервере. Трансляция журналов на уровне записей более фрагментарная операция, при которой изменения WAL передаются последовательно через сетевое соединение (см. Подраздел 25.2.5).
Следует отметить, что трансляция журналов асинхронна, то есть записи WAL доставляются после завершения транзакции. В результате образуется окно, когда возможна потеря данных при отказе сервера: будут утеряны ещё не переданные транзакции. Размер этого окна при трансляции файлов журналов может быть ограничен параметром archive_timeout
, который может принимать значение меньше нескольких секунд. Тем не менее подобные заниженные значения могут потребовать существенного увеличения пропускной способности, необходимой для трансляции файлов. При потоковой репликации (см. Подраздел 25.2.5) окно возможности потери данных гораздо меньше.
Скорость восстановления достаточно высока, обычно резервный сервер становится полностью доступным через мгновение после активации. В результате такое решение называется тёплым резервом, что обеспечивает отличную отказоустойчивость. Восстановление сервера из архивной копии базы и применение изменений обычно происходит существенно дольше. Поэтому такие действия обычно требуются при восстановлении после аварии, не для отказоустойчивости. Так же резервный сервер может обрабатывать читающие запросы. В этом случае он называется сервером горячего резерва. См. Раздел 25.5 для подробной информации.
25.2.1. Планирование
Обычно разумно подбирать ведущий и резервный серверы так, чтобы они были максимально похожи, как минимум с точки зрения базы данных. Тогда в частности, пути, связанные с табличными пространствами, могут передаваться без изменений. Таким образом, как на ведущем, так и на резервных серверах должны быть одинаковые пути монтирования для табличных пространств при использовании этой возможности БД. Учитывайте, что если CREATE TABLESPACE выполнена на ведущем сервере, новая точка монтирования для этой команды уже должна существовать на резервных серверах до её выполнения. Аппаратная часть не должна быть в точности одинаковой, но опыт показывает, что сопровождать идентичные системы легче, чем две различные на протяжении жизненного цикла приложения и системы. В любом случае архитектура оборудования должна быть одинаковой — например, трансляция журналов с 32-битной на 64-битную систему не будет работать.
В общем случае трансляция журналов между серверами с различными основными версиями PostgreSQL невозможна. Политика главной группы разработки PostgreSQL состоит в том, чтобы не вносить изменения в дисковые форматы при обновлениях корректирующей версии, таким образом, ведущий и резервный серверы, имеющие разные корректирующие версии, могут работать успешно. Тем не менее, формально такая возможность не поддерживается и рекомендуется поддерживать одинаковую версию ведущего и резервных серверов, насколько это возможно. При обновлении корректирующей версии безопаснее будет в первую очередь обновить резервные серверы — новая корректирующая версия с большей вероятностью прочитает файл WAL предыдущей корректирующей версии, чем наоборот.
25.2.2. Работа резервного сервера
Сервер, работающий в режиме резервного, последовательно применяет файлы WAL, полученные от главного. Резервный сервер может читать файлы WAL из архива WAL (см. restore_command) или напрямую с главного сервера по соединению TCP (потоковая репликация). Резервный сервер также будет пытаться восстановить любой файл WAL, найденный в кластере резервного в каталоге pg_xlog
. Это обычно происходит после перезапуска сервера, когда он применяет заново файлы WAL, полученные от главного сервера перед перезапуском. Но можно и вручную скопировать файлы в каталог pg_xlog
, чтобы применить их в любой момент времени.
В момент запуска резервный сервер начинает восстанавливать все доступные файлы WAL, размещённые в архивном каталоге, указанном в команде restore_command
. По достижении конца доступных файлов WAL или при сбое команды restore_command
сервер пытается восстановить все файлы WAL, доступные в каталоге pg_xlog
. Если это не удаётся и потоковая репликация настроена, резервный сервер пытается присоединиться к ведущему и начать закачивать поток WAL с последней подтверждённой записи, найденной в архиве или pg_xlog
. Если это действие закончилось неудачей, или потоковая репликация не настроена, или соединение позднее разорвалось, резервный сервер возвращается к шагу 1 и пытается восстановить файлы из архива вновь. Цикл обращения за файлами WAL к архиву, pg_xlog
, и через потоковую репликацию продолжается до остановки сервера или переключения его роли, вызванного файлом-триггером.
Режим резерва завершается и сервер переключается в обычный рабочий режим при получении команды pg_ctl promote
или при обнаружении файла-триггера (trigger_file
). Перед переключением сервер восстановит все файлы WAL, непосредственно доступные из архива или pg_xlog
, но пытаться подключиться к главному серверу он больше не будет.
25.2.3. Подготовка главного сервера для работы с резервными
Настройка постоянного архивирования на ведущем сервере в архивный каталог, доступный с резервного, описана в Разделе 24.3. Расположение архива должно быть доступно с резервного сервера даже при отключении главного, то есть его следует разместить на резервном или другом доверенном, но не на главном сервере.
При использовании потоковой репликации следует настроить режим аутентификации на ведущем сервере, чтобы разрешить соединения с резервных. Для этого создать роль и обеспечить подходящую запись в файле pg_hba.conf
в разделе доступа к БД replication
. Так же следует убедиться, что для параметра max_wal_senders
задаётся достаточно большое значение в конфигурационном файле ведущего сервера. При использовании слотов для репликации также достаточно большое значение нужно задать для max_replication_slots
.
Создание базовой резервной копии, необходимой для запуска резервного сервера, описано в Подразделе 24.3.2.
25.2.4. Настройка резервного сервера
Для запуска резервного сервера нужно восстановить резервную копию, снятую с ведущего (см. Подраздел 24.3.4). Затем нужно создать файл команд восстановления recovery.conf
в каталоге данных кластера резервного сервера и включить режим standby_mode
. Задайте в restore_command
обычную команду копирования файлов из архива WAL. Если планируется несколько резервных серверов в целях отказоустойчивости, установите для recovery_target_timeline
значение latest
, чтобы резервный сервер переходил на новую линию времени, образуемую при отработке отказа и переключении на другой сервер.
Примечание
Не используйте pg_standby или подобные средства со встроенным режимом резервного сервера, описанным здесь. Команда restore_command
должна немедленно прекратиться при отсутствии файла; сервер повторит команду вновь при необходимости. Использование средств, подобных pg_standby, описано в Разделе 25.4.
При необходимости потоковой репликации заполните primary_conninfo
параметрами строки соединения для libpq, включая имя (или IP-адрес) сервера и все остальные необходимые данные для соединения с ведущим сервером. Если ведущий требует пароль для аутентификации, пароль также должен быть указан в primary_conninfo
.
Если резервный сервер настраивается в целях отказоустойчивости, на нём следует настроить архивацию WAL, соединения и аутентификацию, как на ведущем сервере, потому что резервный сервер станет ведущим после отработки отказа.
При использовании архива WAL его размер может быть уменьшен с помощью команды в параметре archive_cleanup_command, которая удаляет файлы уже не нужные для дальнейшей работы резервного сервера. Утилита pg_archivecleanup разработана специально для использования в archive_cleanup_command
при типичной конфигурации с одним резервным сервером (см. pg_archivecleanup). Следует отметить, что если архив используется в целях резервирования, следует сохранять все файлы необходимые для восстановления как минимум с последней базовой резервной копии, даже если они не нужны для резервного сервера.
Простой пример recovery.conf
:
standby_mode = 'on' primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' restore_command = 'cp /path/to/archive/%f %p' archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
Можно поддерживать любое количество резервных серверов, но при применении потоковой репликации необходимо убедиться, что значение max_wal_senders
на ведущем достаточно большое, чтобы все они могли подключиться одновременно.
25.2.5. Потоковая репликация
При потоковой репликации резервный сервер может работать с меньшей задержкой, чем при трансляции файлов. Резервный сервер подключается к ведущему, который передаёт поток записей WAL резервному в момент их добавления, не дожидаясь окончания заполнения файла WAL.
Потоковая репликация асинхронна по умолчанию (см. Подраздел 25.2.8), то есть имеется небольшая задержка между подтверждением транзакции на ведущем сервере и появлением этих изменений на резервном. Тем не менее, эта задержка гораздо меньше, чем при трансляции файлов журналов, обычно в пределах одной секунды, если резервный сервер достаточно мощный и справляется с нагрузкой. При потоковой репликации настраивать archive_timeout
для уменьшения окна потенциальной потери данных не требуется.
При потоковой репликации без постоянной архивации на уровне файлов, сервер может избавиться от старых сегментов WAL до того, как резервный получит их. В этом случае резервный сервер потребует повторной инициализации из новой базовой резервной копии. Этого можно избежать, установив для wal_keep_segments
достаточно большое значение, при котором сегменты WAL будут защищены от ранней очистки, либо настроив слот репликации для резервного сервера. Если с резервного сервера доступен архив WAL, этого не требуется, так как резервный может всегда обратиться к архиву для восполнения пропущенных сегментов.
Чтобы включить потоковую репликацию, сначала настройте резервный сервер на приём трансляции журналов, как описано в Разделе 25.2. Затем сделайте следующий шаг — переключите резервный сервер в режим репликации, установив в primary_conninfo
в файле recovery.conf
строку подключения, указывающую на ведущий. Настройте listen_addresses и параметры аутентификации (см. pg_hba.conf
) на ведущем сервере таким образом, чтобы резервный смог подключиться к псевдобазе replication
на ведущем (см. Подраздел 25.2.5.1).
В системах, поддерживающих параметр сокета keepalive, подходящие значения tcp_keepalives_idle, tcp_keepalives_interval и tcp_keepalives_count помогут ведущему вовремя заметить разрыв соединения.
Установите максимальное количество одновременных соединений с резервных серверов (см. описание max_wal_senders).
При запуске резервного сервера с правильно установленным primary_conninfo
резервный подключится к ведущему после воспроизведения всех файлов WAL, доступных из архива. При успешном установлении соединения можно увидеть процесс walreceiver на резервном сервере и соответствующий процесс walsender на ведущем.
25.2.5.1. Аутентификация
Право использования репликации очень важно ограничить так, чтобы только доверенные пользователи могли читать поток WAL, так как из него можно извлечь конфиденциальную информацию. Резервный сервер должен аутентифицироваться на ведущем от имени суперпользователя или пользователя с правом REPLICATION
. Настоятельно рекомендуется создавать выделенного пользователя с правами REPLICATION
и LOGIN
специально для репликации. Хотя право REPLICATION
даёт очень широкие полномочия, оно не позволяет модифицировать данные в ведущей системе, тогда как с правом SUPERUSER
это можно делать.
Список аутентификации клиентов для репликации содержится в pg_hba.conf
в записях с установленным значением replication
в поле database
. Например, если резервный сервер запущен на компьютере с IP-адресом 192.168.1.100
и учётная запись для репликации foo
, администратор может добавить следующую строку в файл pg_hba.conf
ведущего:
# Разрешить пользователю "foo" с компьютера 192.168.1.100 подключаться к этому # серверу в качестве партнёра репликации, если был передан правильный пароль. # # TYPE DATABASE USER ADDRESS METHOD host replication foo 192.168.1.100/32 md5
Имя компьютера и номер порта для ведущего, имя пользователя для соединения и пароль указываются в файле recovery.conf
. Пароль также может быть задан в файле ~/.pgpass
на резервном сервере (указанном в определении с replication
в поле database
). Например, если ведущий принимает подключения по IP-адресу 192.168.1.50
, через порт 5432
, пользователя для репликации foo
с паролем foopass
, то администратор может добавить следующую строку в файл recovery.conf
на резервном сервере:
# Резервный сервер подключается к ведущему, работающему на компьютере 192.168.1.50 # (порт 5432), от имени пользователя "foo" с паролем "foopass". primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
25.2.5.2. Наблюдение
Важным индикатором стабильности работы потоковой репликации является количество записей WAL, созданных на ведущем, но ещё не применённых на резервном сервере. Можно подсчитать задержку, сравнив текущий WAL, записанный на ведущем, с последним WAL, полученным на резервном. Эти показатели могут быть получены с помощью функций pg_current_xlog_location
на ведущем и pg_last_xlog_receive_location
на резервном соответственно (более подробно см. Таблицу 9.68 и Таблицу 9.69). Местоположение последнего полученного WAL на резервном сервере так же показывается в статусе процесса получателя WAL, отображаемого по команде ps
(более подробно см. Раздел 27.1).
Можно запросить список процессов отправителей WAL через представление pg_stat_replication
. Большая разница между pg_current_xlog_location
и полем sent_location
может указывать на то, что главный сервер работает с большой нагрузкой, в то время как разница между sent_location
и pg_last_xlog_receive_location
на резервном может быть признаком задержек в сети или большой нагрузки резервного сервера.
25.2.6. Слоты репликации
Слоты репликации автоматически обеспечивают механизм сохранения сегментов WAL, пока они не будут получены всеми резервными и главный сервер не будет удалять строки, находящиеся в статусе recovery conflict даже при отключении резервного.
Вместо использования слотов репликации для предотвращения удаления старых сегментов WAL можно применять wal_keep_segments, или сохранять сегменты в архиве с помощью команды archive_command. Тем не менее, эти методы часто приводят к тому, что хранится больше сегментов WAL, чем необходимо, в то время как слоты репликации оставляют только то количество сегментов, которое необходимо. Преимущество этих методов состоит в том, что они чётко задают объёмы места, необходимого для pg_xlog
; в то время как текущая реализация репликационных слотов не представляет такой возможности.
Подобным образом, параметры hot_standby_feedback и vacuum_defer_cleanup_age позволяют защитить востребованные строки от удаления при очистке, но первый параметр не защищает в тот промежуток времени, когда резервный сервер не подключён, а для последнего часто нужно задавать большое значение, чтобы обеспечить должную защиту. Слоты репликации решают эти проблемы.
25.2.6.1. Запросы и действия слотов репликации
Каждый слот репликации обладает именем, состоящим из строчных букв, цифр и символов подчёркивания.
Имеющиеся слоты репликации и их статус можно просмотреть в представлении pg_replication_slots
.
Слоты могут быть созданы и удалены как с помощью протокола потоковой репликации (см. Раздел 50.3), так и посредством функций SQL (см. Подраздел 9.26.6).
25.2.6.2. Пример конфигурации
Для создания слота репликации выполните:
postgres=# SELECT * FROM pg_create_physical_replication_slot('node_a_slot'); slot_name | xlog_position -------------+--------------- node_a_slot | postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots; slot_name | slot_type | active -------------+-----------+-------- node_a_slot | physical | f (1 row)
Для настройки резервного сервера на использование этого слота primary_slot_name
должно быть настроено в конфигурации recovery.conf
резервного. Вот простейший пример:
standby_mode = 'on' primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' primary_slot_name = 'node_a_slot'
25.2.7. Каскадная репликация
Свойство каскадной репликации позволяет резервному серверу принимать соединения репликации и потоки WAL от других резервных, выступающих посредниками. Это может быть полезно для уменьшения числа непосредственных подключений к главному серверу, а также для уменьшения накладных расходов при передаче данных в интрасети.
Резервный сервер, выступающий как получатель и отправитель, называется каскадным резервным сервером. Резервные серверы, стоящие ближе к главному, называются серверами верхнего уровня, а более отдалённые — серверами нижнего уровня. Каскадная репликация не накладывает ограничений на количество или организацию последующих уровней, а каждый резервный соединяется только с одним сервером вышестоящего уровня, который в конце концов соединяется с единственным главным/ведущим сервером.
Резервный сервер каскадной репликации не только получает записи WAL от главного, но так же восстанавливает их из архива. Таким образом, даже если соединение с сервером более высокого уровня разорвётся, потоковая репликация для последующих уровней будет продолжаться до исчерпания доступных записей WAL.
Каскадная репликация в текущей реализации асинхронна. Параметры синхронной репликации (см. Подраздел 25.2.8) в настоящее время не оказывают влияние на каскадную репликацию.
Распространение обратной связи горячего резерва работает от нижестоящего уровня к вышестоящему уровню вне зависимости от способа организации связи.
Если вышестоящий резервный сервер будет преобразован в новый главный, нижестоящие серверы продолжат получать поток с нового главного при условии, что recovery_target_timeline
установлен в значение 'latest'
.
Для использования каскадной репликации необходимо настроить резервный каскадный сервер на приём соединений репликации (то есть установить max_wal_senders и hot_standby, настроить host-based authentication). Так же может быть необходимо настроить на нижестоящем резервном значение primary_conninfo
на каскадный резервный сервер.
25.2.8. Синхронная репликация
По умолчанию в PostgreSQL потоковая репликация асинхронна. Если ведущий сервер выходит из строя, некоторые транзакции, которые были подтверждены, но не переданы на резервный, могут быть потеряны. Объём потерянных данных пропорционален задержке репликации на момент отработки отказа.
Синхронная репликация предоставляет возможность гарантировать, что все изменения, внесённые в транзакции, были переданы одному синхронному резервному серверу. Это увеличивает стандартный уровень надёжности, гарантируемый при фиксации транзакции. Этот уровень защиты соответствует второму уровню безопасности репликации из теории вычислительной техники.
При задействовании синхронной репликации, каждое подтверждение пишущей транзакции ожидает подтверждения того, что транзакция записана в журнал транзакций на диске на обоих серверах: ведущем и резервном. При таком варианте потеря данных может произойти, только в случае одновременного выхода из строя ведущего и резервного серверов. Это обеспечивает более высокий уровень надёжности, но только в случае внимательной работы системного администратора при установке и настройке этих двух серверов. Ожидание подтверждения увеличивает уверенность в том, что данные не будут потеряны во время сбоя сервера, но при этом увеличивает время отклика для обработки транзакции. Минимальное время ожидания равно времени передачи данных от ведущего к резервному и обратно.
Транзакции только для чтения и откат транзакции не требуют ожидания для ответа с резервного сервера. Промежуточные подтверждения не ожидают ответа от резервного сервера, только подтверждение верхнего уровня. Долгие операции вида загрузки данных или построения индекса не ожидают финального подтверждения. Но все двухфазные подтверждения требуют ожидания, включая подготовку и непосредственно подтверждение.
25.2.8.1. Базовая настройка
При настроенной потоковой репликации установка синхронной репликации требует только дополнительной настройки: необходимо выставить synchronous_standby_names в непустое значение. Так же необходимо установить synchronous_commit
в значение on
, но так как это значение по умолчанию, обычно действий не требуется. (См. Подраздел 18.5.1 и Подраздел 18.6.2.) В такой конфигурации каждая транзакция будет ожидать подтверждение того, что на резервном сервере произошла запись транзакции в надёжное хранилище. Значение synchronous_commit
может быть выставлено для отдельного пользователя, может быть прописано в файле конфигурации, для конкретного пользователя или БД или динамически изменено приложением для управления степенью надёжности на уровне отдельных транзакций.
После подтверждения транзакции происходит запись на диск на ведущем сервере, запись WAL отправляется на резервный. Резервный сервер посылает ответ каждый раз, когда новый пакет данных WAL записан на диск, даже если значение wal_receiver_status_interval
установлено в 0 на резервном. Первый резервный сервер, соответствущий по имени значению из synchronous_standby_names
, установленному на ведущем и ответивший подтверждением записи, позволяет считать ведущему, что подтверждение получено. Этот параметр позволяет администратору указать, который из резервных серверов будет участвовать в синхронной репликации. Следует отметить, что настройка синхронной репликации происходит по большей части на главном сервере. Названный резервный сервер должен быть напрямую соединён с главным, так как главный ничего не знает о резервных более низкого уровня, задействованных в каскадной репликации.
Если synchronous_commit
имеет значение remote_write
, то в случае подтверждения транзакции ответ от резервного сервера об успешном подтверждении будет передан, когда данные запишутся в операционной системе, но не когда данные будет реально сохранены на диске. При таком значении уровень надёжности снижается по сравнению со значением on
. Резервный сервер может потерять данные в случае падения операционной системы, но не в случае падения PostgreSQL. Тем не менее, этот вариант полезен на практике, так как позволяет сократить время отклика для транзакции. Потеря данных может произойти только в случае одновременного сбоя ведущего и резервного, осложнённого повреждением БД на ведущем.
Пользователи прекратят ожидание в случае запроса на быструю остановку сервера. В то время как при использовании асинхронной репликации сервер не будет полностью остановлен, пока все исходящие записи WAL не переместятся на текущий присоединённый резервный сервер.
25.2.8.2. Планирование производительности
Организуя синхронную репликацию, обычно нужно обстоятельно обдумать конфигурацию и размещение резервных серверов, чтобы обеспечить приемлемую производительность приложений. Ожидание не потребляет системные ресурсы, но блокировки транзакций будут сохраняться до подтверждения передачи. Как следствие, непродуманное использование синхронной репликации приведёт к снижению производительности БД из-за увеличения времени отклика и числа конфликтов.
PostgreSQL позволяет разработчикам выбрать требуемый уровень надёжности, обеспечиваемый при репликации. Он может быть установлен для системы в целом, для отдельного пользователя или соединения или даже для отдельной транзакции.
Например, в рабочей нагрузке приложения 10% изменений могут относиться к важным данным клиентов, а 90% — к менее критичным данным, потеряв которые, бизнес вполне сможет выжить (например, это могут быть текущие разговоры пользователей между собой).
При настройке уровня синхронности репликации на уровне приложения (на ведущем) можно задать синхронную репликацию для большинства важных изменений без замедления общего рабочего ритма. Возможность настройки на уровне приложения является важным и практичным средством для получения выгод синхронной репликации при высоком быстродействии.
Следует иметь в виду, что пропускная способность сети должна быть больше скорости генерирования данных WAL.
25.2.8.3. Планирование отказоустойчивости
Если транзакция фиксируется в режиме synchronous_commit
on
или remote_write
, ведущий сервер будет ждать ответа синхронного резервного. Этот ответ может быть не получен никогда, если последний (или единственный) резервный сервер выйдет из строя.
Лучший способ избежать потери данных — защититься от потери последнего из синхронных резервных серверов. Этого можно добиться, перечислив имена нескольких потенциальных синхронных резервных серверов в строке synchronous_standby_names
. Изначально в качестве синхронного резервного сервера будет выбираться первый из них. Следующие по списку синхронные серверы будут задействованы в случае сбоя первого.
Когда к ведущему серверу впервые присоединяется резервный, он ещё не будет полностью синхронизированным. Это называется состоянием навёрстывания
. Как только отставание резервного от ведущего сервера сократится до нуля в первый раз, система перейдет в состояние потоковой передачи
в реальном времени. Сразу после создания резервного сервера навёрстывание может быть длительным. В случае выключения резервного сервера длительность этого процесса увеличится соответственно продолжительности простоя. Резервный сервер может стать синхронным только по достижении состояния потоковой передачи
.
Если ведущий сервер перезапускается при наличии зафиксированных транзакций, ожидающих подтверждения, эти транзакции будут помечены как полностью зафиксированные после восстановления ведущего. При этом нельзя гарантировать, что все резервные серверы успели получить все текущие данные WAL к моменту падения ведущего. Таким образом, некоторые транзакции могут считаться незафиксированными на резервном сервере, даже если они считаются зафиксированными на ведущем. Гарантия, которую мы можем дать, состоит в том, что приложение не получит явного подтверждения успешной фиксации, пока не будет уверенности, что резервный получил данные WAL.
Если действительно был утрачен последний резервный сервер, то следует отменить synchronous_standby_names
и перезагрузить файл конфигурации на ведущем.
В случае если ведущий сервер стал недоступным для оставшихся резервных, следует переключиться на наиболее подходящий из имеющихся резервных серверов.
Если необходимо пересоздать резервный сервер при наличии ожидающей подтверждения транзакции необходимо убедиться, что команды pg_start_backup() и pg_stop_backup() запускаются в сессии с установленным synchronous_commit
= off
, в противном случае эти запросы на подтверждение будут бесконечными для вновь возникшего резервного сервера.
25.2.9. Непрерывное архивирование на резервном сервере
Когда на резервном сервере применяется последовательное архивирование WAL, возможны два различных сценария: архив WAL может быть общим для ведущего и резервного сервера, либо резервный сервер может иметь собственный архив WAL. Когда резервный работает с собственным архивом WAL, установите в archive_mode
значение always
, и он будет вызывать команду архивации для каждого сегмента WAL, который он получает при восстановлении из архива или потоковой репликации. В случае с общим архивом можно поступить аналогично, но archive_command
должна проверять, нет ли в архиве файла, идентичного архивируемому. Таким образом, команда archive_command
должна позаботиться о том, чтобы существующий файл не был заменён файлом с другим содержимым, а в случае попытки повторного архивирования должна сообщать об успешном выполнении. При этом все эти действия должны быть рассчитаны на условия гонки, возможные, если два сервера попытаются архивировать один и тот же файл одновременно.
Если в archive_mode
установлено значение on
, архивация в режиме восстановления или резерва не производится. В случае повышения резервного сервера, он начнёт архивацию после повышения, но в архив не попадут те файлы WAL или файлы истории линии времени, которые генерировал не он сам. Поэтому, чтобы в архиве оказался полный набор файлов WAL, необходимо обеспечить архивацию всех файлов WAL до того, как они попадут на резервный сервер. Это естественным образом происходит при трансляции файлов журналов, так как резервный сервер может восстановить только файлы, которые находятся в архиве, однако при потоковой репликации это не так. Когда сервер работает не в режиме резерва, различий между режимами on
и always
нет.