Горячий резерв

примечание

Эта страница переведена при помощи нейросети GigaChat.

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

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

Обзор на уровне пользователя

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

Данные на резервной копии занимают некоторое время для прибытия с основного сервера, поэтому будет измеримая задержка между основным и резервным серверами. Запуск одного и того же запроса почти одновременно на основном и резервном сервере может, следовательно, возвращать различные результаты. Можно сказать, что данные на резервной копии являются согласованными в конечном итоге с основными данными. Как только запись фиксации транзакции воспроизводится на резервной копии, изменения, внесенные этой транзакцией, будут видны при создании любого нового снимка состояния на резервной копии. Снимки могут быть сделаны в начале каждого запроса или в начале каждой транзакции, в зависимости от текущего уровня изоляции транзакций. Для получения более подробной информации см. раздел «Изоляция транзакций».

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

• Доступ к запросу: SELECT, COPY TO.

• Команды курсора: DECLARE, FETCH, CLOSE.

• Настройки: SHOW, SET, RESET.

• Команды управления транзакциями:

  • BEGIN, END, ABORT, START TRANSACTION.
  • SAVEPOINT, RELEASE, ROLLBACK TO SAVEPOINT.
  • EXCEPTION блоки и другие внутренние подоперации.

• LOCK TABLE, только когда явно находится в одном из этих режимов: ACCESS SHARE, ROW SHARE или ROW EXCLUSIVE.

• Планы и ресурсы: PREPARE, EXECUTE, DEALLOCATE, DISCARD.

• Плагины и расширения: LOAD.

• UNLISTEN.

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

• Язык манипулирования данными (DML): INSERT, UPDATE, DELETE, MERGE, COPY FROM, TRUNCATE. Обратите внимание, что нет разрешенных действий, которые приводят к выполнению триггера во время восстановления. Это ограничение применяется даже к временным таблицам, поскольку строки таблицы нельзя читать или записывать без назначения идентификатора транзакции, что в настоящее время невозможно в среде горячего резерва.

• Язык определения данных (DDL): CREATE, DROP, ALTER, COMMENT. Это ограничение применяется даже к временным таблицам, поскольку выполнение этих операций потребовало бы обновления системных каталоговых таблиц.

• SELECT ... FOR SHARE | UPDATE, потому что блокировки строк не могут быть установлены без обновления базовых файлов данных.

• Правила для SELECT операторов, которые генерируют команды DML.

• LOCK, который явно запрашивает режим выше, чем ROW EXCLUSIVE MODE.

• в краткой форме по умолчанию, поскольку он запрашивает ACCESS EXCLUSIVE MODE.

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

  • BEGIN READ WRITE, START TRANSACTION READ WRITE.
  • SET TRANSACTION READ WRITE, SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE.
  • SET transaction_read_only = off.

• Команды двухфазного подтверждения: PREPARE TRANSACTION, COMMIT PREPARED, ROLLBACK PREPARED потому что даже транзакции только для чтения должны записывать WAL во время подготовки (первая фаза двухфазной фиксации).

• Обновления последовательности: nextval(), setval().

• LISTEN, NOTIFY.

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

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

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

Обработка конфликтов запросов

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

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

• Блокировки доступа, взятые на первичном сервере, включая явные LOCK команды и различные действия DDL, вступают в конфликт с доступом к таблицам в запросах резервирования.
• Удаление табличного пространства на основном сервере конфликтует с запросами резервной копии, использующими это табличное пространство для временных рабочих файлов.
• Удаление базы данных на основном сервере конфликтует с сеансами, подключенными к этой базе данных на резервном сервере.
• Применение записи очистки вакуума из WAL конфликтует с транзакциями резервного копирования, снимки которых все еще могут «видеть» любые строки, которые должны быть удалены.
• Применение записи очистки вакуума из 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 является «ранняя очистка». В обычных условиях PostgreSQL позволяет очищать старые версии строк, когда нет транзакций, которым необходимо их видеть, чтобы обеспечить правильную видимость данных согласно правилам 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 на основном сервере. Достижение согласованного состояния также может быть отложено при наличии обоих этих условий:

• Транзакция записи имеет более 64 под транзакций.
• Очень долгоживущие транзакции записи.

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

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

• max_connections;
• max_prepared_transactions;
• max_locks_per_transaction;
• max_wal_senders;
• max_worker_processes.

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

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, что означает ожидание завершения запросов навсегда.

Вспомогательные биты статуса транзакций, записанные на первичном сервере, не регистрируются в журнале WAL, поэтому данные на резервном сервере, вероятно, снова запишут подсказки на резервном сервере. Таким образом, резервный сервер все равно будет выполнять запись на диск, несмотря на то, что все пользователи являются только читателями; никаких изменений значений данных не происходит. Пользователи по-прежнему будут записывать большие временные файлы сортировки и повторно генерировать файлы информации о кеше отношений, так что ни одна часть базы данных не является действительно доступной только для чтения во время режима горячего резерва. Обратите внимание также, что записи в удаленные базы данных с использованием модуля dblink и другие операции вне базы данных с использованием функций PL по-прежнему будут возможны, даже если транзакция доступна только для чтения локально.

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

• Язык определения данных (DDL): например, CREATE INDEX.
• Привилегии и владение: GRANT, REVOKE, REASSIGN.
• Команды обслуживания: ANALYZE, VACUUM, CLUSTER, REINDEX.

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

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

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 может быть успешным только в том случае, если табличное пространство пусто. Некоторые пользователи резервных копий могут активно использовать табличное пространство через свой параметр 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 не будут увеличены.

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

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

Справочник по параметрам горячего резерва

Различные параметры были упомянуты выше в разделе «Обработка конфликтов запросов» и разделе «Обзор административной части».

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

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

Меры предосторожности

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

• Для создания снимков требуется полное знание выполняемых транзакций. Транзакции, использующие большое количество под транзакций (в настоящее время более 64), будут задерживать начало соединений только для чтения до завершения самой длительной записи транзакции. Если возникает такая ситуация, пояснительные сообщения отправляются в журнал сервера.
• Точки начала для запросов резервного копирования генерируются при каждой контрольной точке на основном сервере. Если резервный сервер выключается во время выключения основного сервера, может быть невозможно вернуться к горячему резервному режиму до тех пор, пока основной сервер не будет запущен снова, чтобы он мог сгенерировать дополнительные точки начала в журналах WAL. Эта ситуация не является проблемой в большинстве распространенных ситуаций, когда это может произойти. В общем случае, если основной сервер выключен и больше недоступен, скорее всего, это связано со серьезной неисправностью, которая требует преобразования резервного сервера в новый основной сервер в любом случае. И в ситуациях, когда основной сервер намеренно отключают, стандартная процедура также включает координацию для обеспечения плавного перехода резервного сервера на роль нового основного сервера.
• В конце восстановления транзакций, находящихся в состоянии подготовки, потребуется вдвое больше записей таблицы блокировки, чем обычно. Если планируется выполнять либо большое количество одновременных подготовленных транзакций, которые обычно занимают AccessExclusiveLocks, либо планируется иметь одну большую транзакцию, занимающую много AccessExclusiveLocks, рекомендуется выбрать большее значение параметра AccessExclusiveLocks, возможно, в два раза превышающее значение этого параметра на основном сервере. Не нужно учитывать этот параметр, если значение max_locks_per_transaction равно 0.
• Уровень изоляции транзакций с сериализацией пока недоступен в горячем резерве. (См. разделы 13.2.3 и 13.4.1 для получения подробной информации.) Попытка установить уровень изоляции транзакции на уровне сериализации в режиме горячего резерва приведет к ошибке.