Когда hot_standby параметр установлен в значение true на резервном сервере, он начнет принимать соединения, как только в процессе восстановления система перейдет в согласованное состояние. Все такие соединения доступны строго только для чтения; запись не разрешена даже во временные таблицы.

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

Транзакции, инициированные в режиме горячего резервирования, могут использовать следующие команды:

Транзакциям, запущенным в режиме горячего резервирования, никогда не присваивается идентификатор транзакции; такие транзакции не могут выполнять запись в системный журнал упреждающей записи. Следовательно, следующие действия приведут к возникновению ошибок:

В штатном режиме работы, «только для чтения» транзакциям разрешено использовать LISTEN и NOTIFY, поэтому сеансы в режиме горячего резервирования функционируют с несколько более строгими ограничениями, чем обычные сеансы в режиме «только для чтения». Существует вероятность, что некоторые из этих ограничений будут смягчены в будущих выпусках системы.

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

Пользователи могут определить, активен ли в настоящее время режим горячего резервирования для текущего сеанса, с помощью команды SHOW in_hot_standby. (В версиях сервера до 14-й параметр in_hot_standby параметр отсутствовал; приемлемым альтернативным методом для серверов более ранних версий является SHOW transaction_read_only.) Кроме того, набор функций (Таблица 2.6.96) позволяет пользователям получать информацию о резервном сервере. Это дает возможность разрабатывать приложения, учитывающие текущее состояние базы данных. Данные функции могут применяться для мониторинга процесса восстановления или для создания сложных программ, восстанавливающих базу данных до определенных состояний.

Основной узел и резервный сервер во многих отношениях являются слабо связанными. Действия на основном узле будут оказывать влияние на работу резервного узла. Вследствие этого существует вероятность возникновения нежелательных взаимодействий или конфликтов между ними. Наиболее простым для понимания типом конфликта является конфликт производительности: если на основном узле выполняется масштабная загрузка данных, это генерирует аналогичный поток записей WAL на резервном узле, в результате чего запросы на резервном сервере могут конкурировать за системные ресурсы, такие как подсистема ввода-вывода.

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

На основном сервере такие ситуации просто приводят к ожиданию; и пользователь может принять решение об отмене любого из конфликтующих действий. Однако на резервном узле выбора нет: действие, зафиксированное в журнале WAL, уже было выполнено на основном узле, поэтому резервный узел должен обязательно его применить. Кроме того, предоставление возможности неограниченного ожидания при применении записей WAL крайне нежелательно, так как состояние резервного узла будет всё больше отставать от состояния основного сервера. В связи с этим реализован механизм принудительной отмены запросов на резервном сервере, вступающих в конфликт с применяемыми записями WAL.

Примером проблемной ситуации является выполнение администратором на основном сервере команды DROP TABLE в отношении таблицы, к которой в данный момент выполняются запросы на резервном сервере. Очевидно, что запрос на резервном сервере не может быть продолжен, если DROP TABLE применяется на резервном узле. Если бы подобная ситуация возникла на основном сервере, DROP TABLE будет ожидать завершения другого запроса. Однако когда DROP TABLE выполняется на основном узле, основной узел не располагает информацией о том, какие запросы выполняются на резервном сервере, поэтому он не будет ожидать завершения таких запросов на резервном сервере. Записи WAL об изменениях поступают на резервный узел в то время, когда запрос на резервном сервере все еще выполняется, что вызывает конфликт. Резервный сервер должен либо отложить применение записей WAL (а также всех последующих данных), либо отменить конфликтующий запрос, чтобы DROP TABLE можно было применить.

Если конфликтующий запрос непродолжителен, обычно целесообразно позволить ему завершиться, немного отложив применение записей WAL; однако длительная задержка при применении записей WAL, как правило, нежелательна. В связи с этим механизм отмены имеет параметры, max_standby_archive_delay и max_standby_streaming_delay, которые определяют максимально допустимую задержку в применении записей WAL. Конфликтующие запросы будут отменены, как только время, затраченное на применение любых вновь полученных данных WAL, превысит соответствующее установленное значение задержки. Предусмотрено два параметра, позволяющих задавать различные значения задержки для случаев чтения данных WAL из архива (то есть при начальном восстановлении из базовой резервной копии или «наверстывании отставания» резервный сервер, имеющий значительное отставание) в противовес чтению данных WAL посредством потоковой репликации.

На резервном сервере, предназначенном в первую очередь для обеспечения отказоустойчивости, рекомендуется устанавливать относительно малые значения параметров задержки, чтобы сервер не мог значительно отстать от основного узла из-за задержек, вызванных запросами на резервном сервере. Однако, если резервный сервер предназначен для выполнения длительных запросов, предпочтительным может быть большое или даже бесконечное значение задержки. Следует учитывать, что длительный запрос может привести к тому, что другие сессии на резервном сервере не будут видеть последние изменения на основном узле, если такой запрос задерживает применение записей WAL.

Как только задержка, указанная в параметре max_standby_archive_delay или max_standby_streaming_delay , будет превышена, конфликтующие запросы будут отменены. Обычно это приводит лишь к ошибке отмены, хотя в случае воспроизведения операции DROP DATABASE весь конфликтующий сеанс будет завершен. Кроме того, если конфликт вызван блокировкой, удерживаемой бездействующей транзакцией, конфликтующий сеанс завершается (это поведение может измениться в будущем).

Отмененные запросы могут быть повторены немедленно (разумеется, после начала новой транзакции). Поскольку отмена запроса зависит от характера воспроизводимых записей WAL, запрос, который был отменен, вполне может быть успешно выполнен при повторном запуске.

Следует учитывать, что параметры задержки сравниваются с временем, прошедшим с момента получения данных WAL резервным сервером. Таким образом, льготный период, предоставляемый любому отдельному запросу на резервном узле, никогда не превышает значение параметра задержки и может быть значительно меньше, если резервный узел уже отстал в результате ожидания завершения предыдущих запросов или по причине невозможности справиться с высокой нагрузкой на обновление данных.

Наиболее распространенной причиной конфликта между запросами на резервном сервере и механизмом воспроизведения журнала WAL является «ранняя очистка». Как правило, система Digital Q.DataBase позволяет выполнять очистку устаревших версий строк, когда отсутствуют транзакции, которым они необходимы для обеспечения корректной видимости данных согласно правилам MVCC. Однако данное правило применимо только к транзакциям, выполняемым на основном узле. Таким образом, существует вероятность, что процедура очистки на основном узле удалит версии строк, которые все еще должны быть видны транзакции на резервном узле.

Очистка версий строк не является единственной потенциальной причиной возникновения конфликтов с запросами на резервных узлах. Все исключительно индексные сканирования (включая выполняемые на резервных узлах) должны использовать MVCC -снимки, которые «согласуются» с картой видимости. Следовательно, конфликты возникают всегда, когда функция VACUUM помечает страницу в карте видимости как полностью видимую (all-visible) , содержащую одну или несколько строк, не видимых для всех запросов на резервном сервере. Поэтому даже выполнение VACUUM в отношении таблицы, не имеющей обновленных или удаленных строк, требующих очистки, может привести к возникновению конфликтов.

Пользователям следует учитывать, что интенсивное и регулярное обновление таблиц на основном сервере приведет к быстрой отмене длительных запросов на резервном сервере. В подобных случаях установка конечного значения для max_standby_archive_delay или max_standby_streaming_delay может рассматриваться как действие, аналогичное установке statement_timeout.

Существуют способы устранения проблемы, если количество отмен запросов на резервном сервере становится неприемлемым. Первый вариант — установить параметр hot_standby_feedback, который предотвращает VACUUM процесс удаления недавно измененных строк, что позволяет избежать конфликтов очистки. В этом случае следует иметь в виду, что это приведет к задержке очистки устаревших строк на основном сервере, что может повлечь за собой нежелательное раздувание таблиц. Однако ситуация с очисткой будет не хуже, чем при выполнении запросов резервного сервера напрямую на основном сервере; при этом вы по-прежнему получаете выгоду от распределения нагрузки на резервный узел. Если резервные серверы часто подключаются и отключаются, может потребоваться внести корректировки для обработки периода, когда hot_standby_feedback обратная связь не предоставляется. Например, рассмотрите возможность увеличения значения max_standby_archive_delay чтобы исключить быструю отмену запросов из-за конфликтов в файлах архива WAL в периоды отсутствия соединения. Также следует рассмотреть возможность увеличения значения max_standby_streaming_delay во избежание быстрой отмены запросов новыми записями потоковой передачи WAL после восстановления соединения.

Количество отмен запросов и их причины можно просмотреть с помощью системного представления pg_stat_database_conflicts на резервном сервере. Системное представление pg_stat_database также содержит сводную информацию.

Пользователи могут управлять выводом сообщений в журнал, когда воспроизведение журнала WAL ожидает разрешения конфликтов дольше, чем deadlock_timeout из-за конфликтов. Это контролируется параметром log_recovery_conflict_waits параметр.

Если hot_standby имеет значение on в postgresql.conf (значение по умолчанию) и при наличии standby.signal файла сервер будет функционировать в режиме горячего резерва. При этом для разрешения подключений в режиме горячего резерва может потребоваться некоторое время, так как сервер не будет принимать соединения до тех пор, пока не выполнит восстановление в объеме, достаточном для обеспечения согласованного состояния, при котором допускается выполнение запросов. В течение этого периода попытки подключения клиентов будут отклоняться с выводом сообщения об ошибке. Чтобы подтвердить готовность сервера, можно либо инициировать цикл попыток подключения из приложения, либо отслеживать появление следующих сообщений в журналах сервера:

LOG:  entering standby mode

... then some time later ...

LOG:  consistent recovery state reached
LOG:  database system is ready to accept read-only connections

Информация о согласованности записывается на основном узле один раз при прохождении контрольной точки. Включение режима горячего резервирования невозможно при чтении журналов WAL, записанных в период, когда параметр wal_level не был установлен в значение replica или logical на основном узле. Достижение согласованного состояния также может задерживаться при одновременном выполнении обоих следующих условий:

При использовании файловой передачи журналов («теплое резервирование») может потребоваться дождаться поступления следующего файла WAL, что может занять время, определяемое значением archive_timeout параметра на основном узле.

Значения некоторых параметров определяют размер разделяемой памяти для отслеживания идентификаторов транзакций, блокировок и подготовленных транзакций. Объем данных структур в разделяемой памяти на резервном узле должен быть не меньше, чем на основном узле, чтобы гарантировать наличие достаточного объема разделяемой памяти на резервном узле в процессе восстановления. Например, если на основном узле использовались подготовленные транзакции, а на резервном узле не было выделено достаточно разделяемой памяти для их отслеживания, процесс восстановления будет остановлен до изменения конфигурации резервного узла. К затрагиваемым параметрам относятся:

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

Механизм журнала WAL отслеживает изменения данных параметров на основном узле. Если узел в режиме горячего резервирования обрабатывает журнал WAL, записи которого указывают на то, что текущее значение параметра на основном узле превышает его собственное значение, он регистрирует предупреждение и приостанавливает восстановление, например:

WARNING:  hot standby is not possible because of insufficient parameter settings
DETAIL:  max_connections = 80 is a lower setting than on the primary server, where its value was 100.
LOG:  recovery has paused
DETAIL:  If recovery is unpaused, the server will shut down.
HINT:  You can then restart the server after making the necessary configuration changes.

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

Администратору важно выбрать соответствующие параметры для max_standby_archive_delay и max_standby_streaming_delay. Оптимальный выбор параметров варьируется в зависимости от бизнес-приоритетов. Например, если сервер в первую очередь выполняет функции обеспечения отказоустойчивости, следует установить минимальные значения задержки, возможно, даже нулевые, хотя такие настройки являются весьма агрессивными. Если резервный сервер используется в качестве дополнительного узла для выполнения аналитических запросов, может быть допустимым установить максимальное значение задержки на несколько часов или даже -1, что означает неограниченное ожидание завершения запросов.

«Биты подсказок» (hint bits) статуса транзакции, записываемые на основном узле, не заносятся в журнал WAL, поэтому данные на резервном узле, вероятно, будут приводить к повторной перезаписи этих подсказок. Таким образом, резервный сервер будет выполнять операции записи на диск, даже если все пользователи работают в режиме «только чтение»; непосредственно значения данных при этом не изменяются. Пользователи по-прежнему будут создавать объемные временные файлы сортировки и заново генерировать файлы кэша отношений (relcache), поэтому ни одна часть базы данных не является полностью доступной только для чтения в режиме горячего резерва. Также следует учитывать, что операции записи в удаленные базы данных с использованием dblink модуль, а также другие операции вне базы данных с использованием функций PL по-прежнему будут возможны, даже если транзакция имеет статус «только для чтения» на локальном уровне.

Следующие типы команд администрирования не поддерживаются в режиме восстановления:

Обратите внимание, что некоторые из этих команд разрешены при выполнении транзакций в режиме «только для чтения» на основном узле.

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

pg_cancel_backend() и pg_terminate_backend() будут работать с пользовательскими фоновыми процессами, но не с процессом запуска (startup process), который выполняет восстановление. pg_stat_activity не отображает восстанавливаемые транзакции как активные. В результате, pg_prepared_xacts всегда пуст в процессе восстановления. Если необходимо разрешить сомнительные подготовленные транзакции, просмотрите pg_prepared_xacts на основном узле и выполните команды для разрешения транзакций на нем или разрешите их после завершения восстановления.

pg_locks будет отображать блокировки, удерживаемые фоновыми процессами, в штатном режиме. pg_locks также отображает виртуальную транзакцию под управлением процесса запуска, который владеет всеми AccessExclusiveLocks , удерживаемыми транзакциями, воспроизводимыми при восстановлении. Следует учитывать, что процесс запуска не запрашивает блокировки для внесения изменений в базу данных, поэтому блокировки, отличные от AccessExclusiveLocks , не отображаются в pg_locks для процесса Startup; их существование просто предполагается.

Плагин Nagios плагин check_pgsql будет функционировать, так как необходимая для проверки базовая информация существует. check_postgres Операции очистки (VACUUM), выполняемые на основном узле, по-прежнему передают изменения на резервный узел.

Команды управления файлами WAL не будут работать в процессе восстановления, например, pg_backup_start, pg_switch_wal и т. д.

Динамически загружаемые модули работают, включая pg_stat_statements.

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

Системы репликации на основе триггеров, такие как Slony, Londiste и Bucardo вовсе не будут работать на резервном узле, хотя они будут успешно функционировать на основном сервере, пока соответствующие изменения не отправляются на резервные серверы для применения. Механизм воспроизведения журнала WAL не использует триггеры, поэтому невозможна ретрансляция данных с резервного узла в любую систему, требующую дополнительных операций записи в базу данных или полагающуюся на использование триггеров.

Новые идентификаторы OID не могут быть назначены, хотя некоторые UUID генераторы могут продолжать работу, пока они не зависят от записи нового состояния в базу данных.

В настоящее время создание временных таблиц не допускается в транзакциях в режиме «только для чтения», поэтому в некоторых случаях существующие сценарии будут работать некорректно. Данное ограничение может быть снято в одной из будущих версий. Это является как вопросом соответствия стандарту SQL, так и технической проблемой.

DROP TABLESPACE может быть выполнена успешно только в том случае, если табличное пространство пусто. Некоторые пользователи резервного узла могут активно использовать табличное пространство через свой temp_tablespaces параметр. Если в табличном пространстве присутствуют временные файлы, все активные запросы отменяются для обеспечения удаления временных файлов, чтобы табличное пространство можно было удалить, а воспроизведение журнала WAL могло быть продолжено.

Выполнение команды DROP DATABASE или ALTER DATABASE ... SET TABLESPACE на основном узле сгенерирует запись в журнале WAL, которая приведет к принудительному отключению всех пользователей, подключенных к этой базе данных на резервном узле. Данное действие выполняется немедленно, независимо от значения параметра max_standby_streaming_delay. Обратите внимание, что ALTER DATABASE ... RENAME не отключает пользователей, что в большинстве случаев проходит незамеченным, хотя в некоторых ситуациях может вызвать ошибки в работе приложения, если оно зависит от имени базы данных.

В обычном режиме (вне процесса восстановления) при выполнении команды DROP USER или DROP ROLE в отношении роли с правом входа, пока данный пользователь остается подключенным, текущее соединение не разрывается — пользователь остается в системе. Однако пользователь не сможет подключиться повторно. Это поведение сохраняется и в режиме восстановления, поэтому выполнение данной операции DROP USER на основном узле не приводит к отключению этого пользователя на резервном узле.

Механизм сбора накопленной статистики функционирует во время восстановления. Все операции сканирования, чтения, блокировки, использование индексов и прочее будут регистрироваться на резервном узле в штатном режиме. При этом воспроизведение журнала WAL не приводит к увеличению счетчиков, специфичных для отношений и баз данных. То есть процесс воспроизведения не инкрементирует pg_stat_all_tables столбцы (такие как n_tup_ins), а операции чтения или записи, выполняемые процессом запуска, не будут отслеживаться в pg_statio_ представлениях, а значения в соответствующих pg_stat_database столбцах не будут увеличиваться.

Механизм автоочистки (autovacuum) не активен в режиме восстановления. Он будет запущен в штатном режиме по завершении восстановления.

Процесс контрольной точки (checkpointer) и процесс фоновой записи (background writer) активны в режиме восстановления. Процесс контрольной точки будет выполнять точки перезапуска (restartpoints), аналогичные контрольным точкам на основном узле, а процесс фоновой записи будет выполнять стандартные операции по очистке блоков. Это может включать в себя обновление информации о бит-подсказках (hint bits), хранящейся на резервном сервере. CHECKPOINT команда принимается в режиме восстановления, хотя она выполняет точку перезапуска, а не новую контрольную точку.

Выше были упомянуты различные параметры в Раздел 3.11.4.2 и Раздел 3.11.4.3.

На основном узле может использоваться wal_level параметр. max_standby_archive_delay и max_standby_streaming_delay не имеют эффекта, если они заданы на основном узле.

На резервном узле могут использоваться hot_standby, max_standby_archive_delay и max_standby_streaming_delay следующие параметры.

Существует несколько ограничений режима горячего резервирования. Они могут быть и, вероятно, будут устранены в будущих выпусках: