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

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

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

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

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

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

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

Основной и резервный серверы во многих отношениях слабо связаны. Действия на основном сервере будут влиять на резервный. В результате возможны негативные взаимодействия или конфликты между ними. Самый простой конфликт, который можно понять, - это производительность: если на основном сервере происходит огромная загрузка данных, то это приведет к генерации аналогичного потока записей 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-журнала - это “ранняя очистка”. Обычно Tantor SE-1Cпозволяет очищать старые версии строк, когда нет транзакций, которым нужно их видеть, чтобы обеспечить правильную видимость данных в соответствии с правилами MVCC. Однако это правило может быть применено только для транзакций, выполняющихся на основном сервере. Поэтому возможно, что очистка на основном сервере удалит версии строк, которые все еще видны для транзакции на резервном сервере.

Очистка версий строк — не единственная потенциальная причина конфликтов с запросами на резервных серверах. Все индексные сканирования (включая те, которые выполняются на резервных серверах) должны использовать снимок MVCC, который “согласуется” с картой видимости. Поэтому конфликты необходимы всякий раз, когда VACUUM устанавливает страницу как полностью видимую в карте видимости, содержащей одну или несколько строк, не видимых для всех запросов на резервных серверах. Таким образом, даже выполнение 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 на основном сервере. Достижение согласованного состояния также может быть задержано при наличии обоих этих условий:

Если вы используете логическую репликацию на основе файлов ("теплый резерв"), вам может потребоваться подождать, пока прибудет следующий файл журнала предзаписи, что может занять столько времени, сколько указано в параметре 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, поэтому данные на резервном сервере, скорее всего, снова перезапишут подсказки на резервном сервере. Таким образом, резервный сервер все равно будет выполнять записи на диск, даже если все пользователи только для чтения; сами значения данных не изменяются. Пользователи все равно будут записывать большие временные файлы сортировки и пересоздавать файлы информации о кеше отношений, поэтому ни одна часть базы данных на самом деле не является полностью только для чтения в режиме горячего резервного копирования. Обратите также внимание, что записи в удаленные базы данных с использованием модуля dblink и другие операции вне базы данных с использованием PL-функций все равно будут возможны, даже если транзакция является локально только для чтения.

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

Снова обратите внимание, что некоторые из этих команд фактически разрешены во время транзакций в режиме "только для чтения" на основном сервере.

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

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

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

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

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

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

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

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

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

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

DROP TABLESPACE может выполниться только в том случае, если табличнoe пространствo пусто. Некоторые резервные пользователи могут активно использовать табличнoe пространствo через свой параметр temp_tablespaces. Если в табличном пространстве есть временные файлы, все активные запросы отменяются, чтобы убедиться, что временные файлы удалены, и табличнoe пространствo может быть удалено, а воспроизведение 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 не будут увеличиваться.

Автоочистка не активен во время восстановления. Он будет запущен нормально в конце восстановления.

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

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

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

На резервном сервере можно использовать параметры hot_standby, max_standby_archive_delay и max_standby_streaming_delay.

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