Управление несколькими резервными серверами PostgreSQL
11.3.1. sync_priority и sync_state
При потоковой репликации первичный сервер присваивает значения sync_priority и sync_state всем управляемым резервным серверам, обрабатывая каждый резервный сервер на основе этих значений:
-
sync_priority: указывает приоритет резервного сервера в синхронном режиме и является фиксированным значением. Меньшие значения указывают на более высокий приоритет, а 0 означает "асинхронный режим". Приоритеты резервных серверов назначаются в порядке, указанном в параметре конфигурации основного сервераsynchronous_standby_names. Например, в конфигурацииsynchronous_standby_names = 'standby1, standby2'приоритетыstandby1иstandby2равны 1 и 2 соответственно. Резервные серверы, не указанные в этом параметре, работают в асинхронном режиме с приоритетом 0;
-
sync_state: представляет состояние резервного сервера. Состояние зависит от рабочего состояния всех резервных серверов и их индивидуального приоритета. Возможные следующие состояния:
-
Sync: состояние синхронного резервного сервера с наивысшим приоритетом среди всех работающих резервных серверов (за исключением асинхронных серверов);
-
Potential: Состояние резервного синхронного резервного сервера со вторым или более низким приоритетом среди всех работающих резервных серверов (за исключением асинхронных серверов). Если синхронный резервный сервер выйдет из строя, он будет заменен резервным сервером с наивысшим приоритетом среди возможных;
-
Async: состояние асинхронного резервного сервера, которое остается фиксированным. Первичный сервер обрабатывает асинхронные резервные серверы так же, как и потенциальные резервные серверы, за исключением того, что ихsync_stateникогда не бывает «Sync» или «Potential».
Чтобы просмотреть приоритет и состояние резервных серверов, вы можете выполнить следующий запрос:
testdb=# SELECT application_name AS host,
sync_priority, sync_state FROM pg_stat_replication;
host | sync_priority | sync_state
----------+---------------+------------
standby1 | 1 | sync
standby2 | 2 | potential
(2 rows)
В приведенном выше примере standby1 имеет приоритет синхронизации 1 и находится в состоянии «Sync», а standby2 имеет приоритет синхронизации 2 и находится в «Potential» состоянии.
Управление основным сервером несколькими резервными серверами
Основной сервер ожидает только ответов ACK от синхронного резервного сервера. Он подтверждает запись и сброс данных WAL только синхронным резервным сервером. Таким образом, потоковая репликация гарантирует, что только синхронный резервный сервер остается в согласованном и синхронном состоянии с основным.
На рис. 124 показан сценарий, в котором ответ ACK от потенциального резервного сервера получен раньше, чем ответ от основного резервного сервера. В этом случае внутренний процесс основного сервера продолжает ожидать ответа ACK от синхронного резервного сервера. После получения ответа основного процесса серверный процесс освобождает защелку и завершает текущую обработку транзакции.
В противоположном сценарии, когда ответ ACK основного сервера получен раньше, чем ответ потенциального резервного сервера, основной сервер немедленно завершает действие фиксации текущей транзакции, не проверяя, записывает ли потенциальный резервный сервер данные WAL и сбрасывает их.
Поведение при сбое резервного сервера
Поведение основного сервера зависит от типа сбоя резервного сервера:
-
Сбой потенциального или асинхронного резервного сервера:
Если потенциальный или асинхронный резервный сервер выходит из строя, основной сервер завершает процесс walsender, связанный с отказавшим резервным сервером, и продолжает всю обработку. Другими словами, сбой этих резервных серверов не влияет на обработку транзакций основного сервера. -
Сбой синхронного резервного сервера:
Когда синхронный резервный сервер выходит из строя, основной сервер завершает процесс walsender, подключенный к отказавшему резервному серверу, и заменяет его потенциальным резервным сервером с наивысшим приоритетом. В отличие от предыдущего сценария, обработка запросов на основном сервере будет приостановлена с момента сбоя до замены синхронного резервного сервера. Обнаружение отказов резервных серверов играет решающую роль в повышении доступности системы репликации.
В любом случае, если один или несколько резервных серверов настроены для работы в синхронном режиме, основной сервер всегда поддерживает только один синхронный резервный сервер. Этот синхронный резервный сервер всегда остается в согласованном и синхронном состоянии с основным сервером.
