hot standby
Смотреть что такое «hot standby» в других словарях:
Hot Standby — Failover bezeichnet eine Technologie aus der Informationstechnik, mit deren Hilfe Daten und Dienste hochverfügbar gehalten werden können. Unter einem Failover ist der ungeplante Wechsel von einem Primärserver zu einem zweiten Standby System zu… … Deutsch Wikipedia
hot standby — In a redundant hardware configuration, the practice of maintaining backup equipment in operational mode to permit emergency switchover without service interruption … IT glossary of terms, acronyms and abbreviations
Hot Standby Routing Protocol — Hot Standby Router Protocol Le protocole Hot Standby Router Protocol (HSRP) est un protocole propriétaire de Cisco implémenté sur les routeurs permettant une continuité de service. Chaque routeur utilisant le protocole HSRP appartient à un groupe … Wikipédia en Français
Hot Standby Router Protocol — (HSRP) est un protocole propriétaire de Cisco implémenté sur les routeurs et les commutateurs de niveau 3 permettant une continuité de service. HSRP est principalement utilisé pour assurer la disponibilité de la passerelle par défaut dans un sous … Wikipédia en Français
Hot Standby Router Protocol — (HSRP) is a Cisco proprietary redundancy protocol for establishing a fault tolerant default gateway, and has been described in detail in RFC 2281. The Virtual Router Redundancy Protocol (VRRP) is a standards based alternative to HSRP defined in… … Wikipedia
Hot Standby Router Protocol — HSRP (Hot Standby Router Protocol) Familie: Internetprotokollfamilie Einsatzgebiet: Steigerung der Verfügbarkeit von Gateways HSRP im TCP/IP Protokollstapel Anwendung HSRP Transport … Deutsch Wikipedia
Standby (telecommunications) — Standby, in telecommunications, has the following meanings: #In computer and communications systems operations, pertaining to a power saving condition or status of operation of equipment that is ready for use but not in use. (e.g. see Sleep mode) … Wikipedia
Hot spare — A hot spare or hot standby is used as a failover mechanism to provide reliability in system configurations. The hot spare is active and connected as part of a working system. When a key component fails, the hot spare is switched into operation.… … Wikipedia
Hot tub — dablink|This article is about the pool. For the Seinfeld epidsode see The Hot Tub for the Drawn Together episode see Hot Tub (Drawn Together episode)A hot tub is a large home made or manufactured tub or small pool full of heated water and used… … Wikipedia
Cold Standby — nennt man eine Verhaltensweise redundanter Komponenten (Ersatzserver) in einem IT System. Bei einem Ausfall einer Komponente wird nicht automatisch wie beim Hot Standby die Ersatzkomponente aktiviert, sondern diese wird manuell durch einen… … Deutsch Wikipedia
Your Old Standby — Infobox Single Name = Your Old Standby Artist = Mary Wells from Album = Mary Wells Greatest Hits Format = 7 single B side = What Love Has Joined Together Released = 1963 Recorded = 1963, Hitsville USA Genre = Soul Label = Motown M 1042 Writer =… … Wikipedia
Эволюция отказоустойчивости в PostgreSQL: фаза репликации
Мы продолжаем публиковать серию переводов Gulcin Yildirim, разработчика компании 2ndQuadrant, об отказоустойчивости PostgreSQL и сегодня предлагаем вашему вниманию второй пост из серии.
Gulcin приедет на PG Day’17 и лично ответит на вопросы участников, а также расскажет более подробно не только о репликации в PG, но и об автоматизации апгрейдов Постгреса в облаке и не только. Готовьте свои вопросы!
PostgreSQL — это потрясающий проект, который развивается с удивительной скоростью. В этой серии статей мы сфокусируемся на эволюции возможностей отказоустойчивости в PostgreSQL на протяжении всех его версий. Это вторая статья серии, в которой мы поговорим о репликации и её значении для отказоустойчивости и надежности Постгреса.
Если вы хотите проследить за процессом эволюции с самого начала, рекомендую вам прочитать первую статью серии: Эволюция отказоустойчивости в PostgreSQL.
Репликация в PostgreSQL
Репликация базы данных — это понятие, которое мы используем для описания технологии создания копии набора данных на удаленной системе. Хранение надежной копии действующей системы — одна из наиболее важных задач резервирования, ведь все мы хотим, чтобы копии наших данных были просты в обслуживании и использовании, а также стабильны.
Посмотрим на базовую архитектуру. Как правило, отдельные сервера баз данных называются узлами. Вся группа серверов баз данных, задействованных в репликации, известна как кластер. Сервер БД, позволяющий пользователю вносить изменения называется основным (master) или первичным (primary), или может быть описан как источник изменений. Сервер БД, разрешающий доступ только в режиме чтения, называется Горячий резерв или Hot Standby (термин Hot Standby подробно объясняется в разделе Режимы Standby).
Ключевой аспект репликации заключается в том, что изменения данных фиксируются на основном сервере, а затем передаются другим узлам. В некоторых случаях узел может отправить изменения данных другим узлам, и этот процесс известен, как каскадирование (cascading) или эстафета (relay). Таким образом, основной сервер является передающим узлом, но передающий узел не обязательно является основным сервером. Репликацию часто делят на категории, исходя из того, разрешено ли иметь более одного основного узла. В этом случае имеет место мультимастер репликация.
Давайте посмотрим, как PostgreSQL справлялся с репликацией на протяжении всего своего существования и каково текущее состояние отказоустойчивости в разрезе репликации.
История репликации в PostgreSQL
Когда-то (около 2000-2005 гг.) Постгрес поддерживал только отказоустойчивость/восстановление отдельного узла, что достигалось, в основном, с помощью WAL — журнала транзакций. Частично отказоустойчивость обеспечивается MVCC (системой управления параллельным доступом с помощью многоверсионности), но это по большей части оптимизация.
WAL (write ahead logging) был и остается основным методом обеспечения отказоустойчивости в PostgreSQL. Его суть в том, что у вас есть файлы WAL, в которые вы всё записываете, и, в случае отказа системы, можете воспроизвести их и всё восстановить. Этого было достаточно для архитектур, состоящих из одного узла, а для достижения отказоустойчивости множества узлов лучшим решением считается репликация.
Сообщество Postgres долгое время было уверено, что репликация внутри Постгреса ни к чему, и её можно выполнять внешними инструментами, поэтому появились такие инструменты, как Slony и Londiste. (Мы поговорим о триггерных решениях для репликации в следующих статьях этой серии).
В конце концов стало понятно, что устойчивости одного сервера недостаточно, и всё больше людей стали требовать полноценной отказоустойчивости аппаратных средств, а также способ переключения, встроенные в Постгрес. Тогда и появилась физическая репликация, в то время известная как physical streaming.
Мы пройдемся по всем методам репликации в этой статье, но для начала давайте проследим хронологию событий истории репликации в PostgreSQL по основным релизам:
Физическая репликация
PostgreSQL решил ключевую проблему с необходимостью репликации так же, как и большинство реляционных баз данных: взял WAL и сделал возможным отправлять его по сети. Затем эти WAL файлы загружаются в отдельный инстанс Postgres, который работает в режиме чтения.
Резервный инстанс в режиме чтения просто применяет изменения (из WAL), а единственные операции записи приходят всё из того же журнала WAL. В целом, именно так работает механизм потоковой репликации. Изначально репликацией считалась исходная отправка всех файлов (log shipping), но позднее она превратилась в потоковую.
В log shipping мы отправляли целые файлы с помощью команды archive_command. Логика там была довольно простая: вы просто отправляете архив и куда-то его регистрируете — например, целый WAL файл на 16MБ — а затем применяете его где-то, запрашиваете следующий, применяете его и так далее. Позднее это было поставлено на поток через сеть, благодаря использованию протокола libpq в версии PostgreSQL 9.0.
Нынешняя репликация более известна как физическая потоковая репликация, так как мы передаём ряд физических изменений от одного узла другому. Это значит, что когда мы вставляем строку в таблицу, мы генерируем записи изменений для вставки и всех записей индекса.
Когда мы применяем к таблице VACUUM, также генерируются записи изменений.
Кроме того, физическая потоковая репликация записывает все изменения на уровне byte/block, так что сделать что-либо, кроме как воспроизвести их на реплике, практически невозможно.
Рис.1 показывает, как физическая репликация работает всего с двумя узлами. Клиент выполняет запросы на главном узле, изменения записываются в журнал транзакций (WAL) и копируются по сети в WAL на резервном узле. Процесс восстановления на узле в режиме ожидания читает изменения из WAL и применяет их к файлам данных, совсем как в случае аварийного восстановления. Если резервный узел находится в режиме hot standby, клиенты могут выполнять запросы на чтение, пока всё это происходит.
Примечание: Физическая репликация — это просто отправка файлов WAL по сети от основного узла к резервному. Файлы могут отправляться разными протоколами, например, scp, rsync, ftp… Разница между физической и физической потоковой репликацией заключается в том, что потоковая репликация использует внутренний протокол для отправки WAL файлов (процессы отправителя и получателя).
Режимы Standby
Несколько узлов обеспечивают высокий уровень доступности. По этой причине современные архитектуры обычно имеют резервные узлы. Существуют разные режимы резервных узлов (“теплый” и “горячий” резерв, warm & hot standby). Далее мы поясним основные различия между режимами резервных узлов и рассмотрим случай с мультимастер архитектурой.
Может быть активирован немедленно, но не может выполнять полезную работу до момента активации. Если мы непрерывно передаем последовательность WAL файлов на другую машину, на которую была загружена базовая резервная копия той же базы, то у нас система warm standby: в любой момент мы можем активировать вторую машину, и на ней будет почти актуальная копия базы данных. Warm standby не позволяет делать запросы в режиме чтения, что наглядно продемонстрировано на Рис.2.
Восстановление в режиме warm stanby происходит настолько быстро, что резервный сервер обычно становится полностью доступен через несколько мгновений после активации. Именно поэтому такой режим называется “теплой” (warm) резервной конфигурацией с высоким уровнем доступности.
Hot standby — термин для описания возможности обращаться к серверу и выполнять запросы на чтение, пока сервер находится в режиме восстановления или ожидания. Это полезно как в целях репликации, так и для восстановления резервной копии до желаемого состояния с большой точностью.
Понятие «hot standby» также относится к способности сервера перейти от восстановления к нормальной работе, в то время как пользователи продолжают выполнять запросы и/или держат свои соединения открытыми. На Рис.3 видно, что этот резервный режим разрешает запросы на чтение.
Все узлы могут выполнять задачи по чтению/записи. (Мы рассмотрим мультимастер архитектуры в следующих статьях этой серии.)
Параметр WAL Level
Есть связь между настройкой параметра wal_level в файле postgresql.conf и тем, для чего подходит эта настройка. В таблице ниже показана эта связь в PostgreSQL версии 9.6.
| WAL Level | Подходит для |
| Минимальный (minimal) | Аварийное восстановление |
| Реплика (replica) | Физическая репликация Архивирование, основанное на файлах |
| Логический (logical) | Логическая репликация |
Небольшое примечание: параметр wal_level определяет, сколько информации записывается в WAL. Значение по умолчанию — minimal, при котором записывается только информация, необходимая для восстановления после аварии или внезапного отключения. replica добавляет логирование, необходимое для архивирования WAL, а также информацию, необходимую для выполнения запросов на чтение на резервном сервере. И наконец logical добавляет информацию, необходимую для поддержки логического декодирования. Каждый уровень включает в себя информацию, записываемую на всех низких уровнях.
В версиях до 9.6 этот параметр также позволял значения archive и hot_standby. Они по-прежнему принимаются, но отображаются на уровень replica.
Failover и Switchover
При репликации с одним основным узлом, если этот узел умрет, один из резервных должен занять его место (повышение, promotion). В противном случае мы не сможем принимать новые операции записи. Таким образом, названия «основной» и «резервный» — это просто роли, которые могут быть назначены любому узлу в определенный момент времени. Чтобы передать роль основного другому узлу, мы выполняем процедуру под названием Switchover.
Если основной узел умирает и не восстанавливается, происходит более серьезная смена ролей, известная как Failover. Эти две процедуры схожи во многих отношениях, но удобнее использовать разные термины для каждого события. (Знание понятий failover и switchover поможет нам разобраться с вопросами хронологии в следующей статье.)
Заключение
В этой статье мы обсудили репликацию в PostgreSQL и её важность для обеспечения отказоустойчивости и надежности. Мы рассмотрели физическую потоковую репликацию и поговорили о режимах standby в PostgreSQL. Также были упомянуты Failover и Switchover. Мы продолжим тему разговором о временных шкалах (timelines) в PostgreSQL в следующей статье.
Помимо выступления Gulcin, мы готовим для вас серию докладов о репликации и проблемах организации отказоустойчивости различных систем хранения данных от таких докладчиков как Света Смирнова, Colin Charles, Николай Мациевский и многих других. Голосуйте за наиболее актуальные для вас темы, мы обязательно учтем все пожелания при составлении финальной программы конференции!
Hot standby что это
Термин «горячий резерв» используется для описания возможности подключаться к серверу и выполнять запросы на чтение, в то время как сервер находится в режиме резерва или восстановления архива. Это полезно и для целей репликации, и для восстановления желаемого состояния из резервной копии с высокой точностью. Так же термин «горячий резерв» описывает способность сервера переходить из режима восстановления к обычной работе, в то время как пользователи продолжают выполнять запросы и/или их соединения остаются открытыми.
В режиме горячего резерва запросы выполняются примерно так же, как и в обычном режиме, с некоторыми отличиями в использовании и администрировании, описанными ниже.
25.5.1. Обзор на уровне пользователя
Когда параметр hot_standby на резервном сервере установлен в true, то он начинает принимать соединения сразу как только система придёт в согласованное состояние в процессе восстановления. Для таких соединений будет разрешено только чтение, запись невозможна даже во временные таблицы.
Для того, чтобы данные с ведущего сервера были получены на резервном, требуется некоторое время. Таким образом, имеется измеряемая задержка между ведущим и резервным серверами. Поэтому запуск одинаковых запросов примерно в одно время на ведущем и резервном серверах может вернуть разный результат. Можно сказать, что данные на резервном сервере в конечном счёте согласуются с ведущим. После того как запись о зафиксированной транзакции воспроизводится на резервном сервере, изменения, совершённые в этой транзакции, становится видны в любых последующих снимках данных на резервном сервере. Снимок может быть сделан в начале каждого запроса или в начале каждой транзакции в зависимости от уровня изоляции транзакции. Более подробно см. Раздел 13.2.
Транзакции, запущенные в режиме горячего резерва, могут выполнять следующие команды:
Команды явного управления транзакциями
Блок EXCEPTION и другие внутренние подчиненные транзакции
Дополнения и расширения — LOAD
Транзакции, запущенные в режиме горячего резерва, никогда не получают ID транзакции и не могут быть записаны в журнал предзаписи. Поэтому при попытке выполнить следующие действия возникнут ошибки:
Команды управления транзакциями, которые в явном виде требуют режим не только для чтения
SET transaction_read_only = off
При обычной работе транзакции « только для чтения » могут использовать команды LISTEN и NOTIFY ; таким образом, сеансы горячего резерва работают с несколько большими ограничениями, чем обычные только читающие сеансы. Возможно, что некоторые из этих ограничений будут ослаблены в следующих выпусках.
В режиме горячего резерва параметр transaction_read_only всегда имеет значение true и изменить его нельзя. Но если не пытаться модифицировать содержимое БД, подключение к серверу в этом режиме не отличается от подключений к обычным базам данных. При отработке отказа или переключении ролей база данных переходит в обычный режим работы. Когда сервер меняет режим работы, установленные сеансы остаются подключёнными. После выхода из режима горячего резерва становится возможным запускать пишущие транзакции (даже в сеансах, начатых ещё в режиме горячего резерва).
25.5.2. Обработка конфликтов запросов
Ведущий и резервный серверы связаны между собой многими слабыми связями. События на ведущем сервере оказывают влияние на резервный. В результате имеется потенциальная возможность отрицательного влияния или конфликта между ними. Наиболее простой для понимания конфликт — быстродействие: если на ведущем происходит загрузка очень большого объёма данных, то происходит создание соответствующего потока записей WAL на резервный сервер. Таким образом, запросы на резервном конкурируют за системные ресурсы, например, ввод-вывод.
Удаление табличного пространства на ведущем сервере приводит к конфликту на резервном когда запросы используют это пространство для хранения временных рабочих файлов.
Удаление базы данных на ведущем сервере конфликтует с сессиями, подключёнными к этой БД на резервном.
Приложение очистки устаревших транзакций из WAL конфликтует с транзакциями на резервном сервере, которые используют снимок данных, который всё ещё видит какие-то из очищенных на ведущем строк.
Приложение очистки устаревших транзакций из WAL конфликтует с запросами к целевой странице на резервном сервере вне зависимости от того, являются ли данные удалёнными или видимыми.
В этих случаях на ведущем сервере просто происходит ожидание; пользователю следует выбрать какую их конфликтующих сторон отменить. Тем не менее на резервном нет выбора: действия из WAL уже произошли на ведущем, поэтому резервный обязан применить их. Более того, позволять обработчику WAL ожидать неограниченно долго может быть крайне нежелательно, так как отставание резервного сервера от ведущего может всё возрастать. Таким образом, механизм обеспечивает принудительную отмену запросов на резервном сервере, которые конфликтуют с применяемыми записями WAL.
Если конфликтный запрос короткий, обычно желательно разрешить ему завершиться, ненадолго задержав применение записей 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 обрывается вся конфликтная сессия. Так же, если конфликт произошел при блокировке, вызванной транзакцией в состоянии IDLE, конфликтная сессия разрывается (это поведение может изменить в будущем).
Отменённые запросы могут быть немедленно повторены (конечно после старта новой транзакции). Так как причина отмены зависит от природы проигрываемых записей WAL, запрос, который был отменён, может быть успешно выполнен вновь.
Следует учесть, что параметры задержки отсчитываются от времени получения резервным сервером данных WAL. Таким образом, период дозволенной работы для запроса на резервном сервере никогда не может быть длиннее параметра задержки и может быть существенно короче, если резервный уже находится в режиме задержки в результате ожидания предыдущего запроса или результат не доступен из-за высокой нагрузки обновлений.
Наиболее частой причиной конфликтов между запросами на резервном сервере и проигрыванием WAL является преждевременная очистка. Обычно Postgres Pro допускает очистку старых версий записей при условии что ни одна из транзакций их не видит согласно правилам видимости данных для MVCC. Тем не менее эти правила применяются только для транзакций, выполняемых на главном сервере. Таким образом, допустима ситуация, когда на главном запись уже очищена, но эта же запись всё ещё видна для транзакций на резервном сервере.
Для опытных пользователей следует отметить, что как очистка старых версий строк, так и заморозка версии строки могут потенциально вызвать конфликт с запросами на резервном сервере. Ручной запуск команды VACUUM FREEZE может привести к конфликту, даже в таблице без обновленных и удалённых строк.
Количество отменённых запросов и причины отмены можно просмотреть через системное представление pg_stat_database_conflicts на резервном сервере. Системное представление pg_stat_database так же содержит итоговую информацию.
25.5.3. Обзор административной части
Пишущая транзакция имеет более 64 подтранзакций
Очень длительные пишущие транзакции
Если вы применяете файловую репликацию журналов («тёплый резерв»), возможно, придётся ожидать прибытия следующего файла WAL (максимальное время ожидания задаётся параметром archive_timeout на ведущем сервере).
Значения некоторых параметров на резервном сервере необходимо изменить при модификации их на ведущем. Для таких параметров значения на резервном сервере должны быть равны или больше значений на ведущем. Если параметр имеет недостаточно большое значение, резервный сервер не сможет начать работу. Следует увеличить значение и повторить попытку восстановления ещё раз. Это касается следующих параметров:
Вспомогательные биты статуса транзакций, записанные на ведущем, не попадают в WAL, так что они, скорее всего, будут перезаписаны на нём при работе с данными. Таким образом, резервный сервер будет производить запись на диск, даже если все пользователи только читают данные, ничего не меняя. Кроме того, пользователи будут записывать временные файлы при сортировке больших объёмов и обновлять файлы кеша. Поэтому в режиме горячего резерва ни одна часть базы данных фактически не работает в режиме «только чтение». Следует отметить, что также возможно выполнить запись в удалённую базу данных с помощью модуля dblink и другие операции вне базы данных с применением PL-функций, несмотря на то, что транзакции по-прежнему смогут только читать данные.
Следующие типы административных команд недоступны в течение режима восстановления:
Команды определения данных (DDL) — например, CREATE INDEX
Ещё раз следует отметить, что некоторые из этих команд фактически доступны на ведущем сервере для транзакций в режиме только для чтения.
В результате нельзя создать дополнительные индексы или статистику, чтобы они существовали только на резервном. Если подобные административные команды нужны, то их следует выполнить на ведущем сервере, затем эти изменения будут распространены на резервные серверы.
Функции pg_cancel_backend() и pg_terminate_backend() работают на стороне пользователя, но не для процесса запуска, который обеспечивает восстановление. Представление pg_stat_activity не показывает восстанавливаемые транзакции как активные. Поэтому представление pg_prepared_xacts всегда пусто в ходе восстановления. Если требуется разобрать сомнительные подготовленные транзакции, следует обратиться к pg_prepared_xacts на ведущем и выполнить команды для разбора транзакций там либо разобрать их по окончании восстановления.
Модуль check_pgsql для Nagios будет работать, так как сервер выдаёт простую информацию, наличие которой он проверяет. Скрипт мониторинга check_postgres так же работает, хотя для некоторых выдаваемых показателей результаты могут различаться или вводить в заблуждение. Например, нельзя отследить время последней очистки, так как очистка не производится на резервном сервере. Очистка запускается на ведущем сервере и результаты её работы передаются резервному.
Рекомендательная блокировка работает обычно при восстановлении, включая обнаружение взаимных блокировок. Следует отметить, что рекомендательная блокировка никогда не попадает в WAL, таким образом для рекомендательной блокировки как на ведущем сервере, так и на резервном, невозможен конфликт с проигрыванием WAL. Но возможно получение рекомендательной блокировки на ведущем сервере, а затем получение подобной рекомендательной блокировки на резервном. Рекомендательная блокировка относится только к серверу, на котором она получена.
В настоящий момент создание временных таблиц недопустимо при транзакции только для чтения, в некоторых случаях существующий скрипт будет работать неверно. Это ограничение может быть ослаблено в следующих выпусках. Это одновременно требование SQL стандарта и техническое требование.
Если вы в обычном режиме (не в режиме восстановления) выполните DROP USER или DROP ROLE для роли с возможностью подключения, в момент, когда этот пользователь подключён, на данном пользователе это никак не отразится — он останется подключённым. Однако переподключиться он уже не сможет. Это же поведение действует в режиме восстановления — если выполнить DROP USER на ведущем сервере, пользователь не будет отключён от резервного.
Сборщик статистики работает во время восстановления. Все операции сканирования, чтения, блоки, использование индексов и т. п. будут записаны обычным образом на резервном сервере. Действия, происходящие при проигрывании, не будут дублировать действия на ведущем сервере, то есть проигрывание команды вставки не увеличит значение столбца Inserts в представлении pg_stat_user_tables. Файлы статистики удаляются с началом восстановления, таким образом, статистика на ведущем сервере и резервном будет разной. Это является особенностью, не ошибкой.
Автоматическая очистка не работает во время восстановления. Она запустится в обычном режиме после завершения восстановления.
25.5.4. Ссылки на параметры горячего резерва
Различные параметры были упомянуты выше в Подразделе 25.5.2 и Подразделе 25.5.3.
На ведущем могут применяться параметры wal_level и vacuum_defer_cleanup_age. Параметры max_standby_archive_delay и max_standby_streaming_delay на ведущем не действуют.
На резервном сервере могут применяться параметры hot_standby, max_standby_archive_delay и max_standby_streaming_delay. Параметр vacuum_defer_cleanup_age на нём не действует, пока сервер остаётся в режиме резервного сервера. Но если он станет ведущим, его значение вступит в силу.
25.5.5. Ограничения
Имеются следующие ограничения горячего резерва. Они могут и скорее всего будут исправлены в следующих выпусках:
Требуется информация о всех запущенных транзакциях перед тем как будет создан снимок данных. Транзакции, использующие большое количество подтранзакций (в настоящий момент больше 64), будут задерживать начало соединения только для чтения до завершения самой длинной пишущей транзакции. При возникновении этой ситуации поясняющее сообщение будет записано в журнал сервера.
Подходящие стартовые точки для запросов на резервном сервере создаются при каждой контрольной точке на главном. Если резервный сервер отключается, в то время как главный был в отключённом состоянии, может оказаться невозможным возобновить его работу в режиме горячего резерва, до того, как запустится ведущий и добавит следующие стартовые точки в журналы WAL. Подобная ситуация не является проблемой для большинства случаев, в которых она может произойти. Обычно, если ведущий сервер выключен и больше не доступен, это является следствием серьёзного сбоя и в любом случае требует преобразования резервного в новый ведущий. Так же в ситуации, когда ведущий отключён намеренно, проверка готовности резервного к преобразованию в ведущий тоже является обычной процедурой.
Уровень изоляции транзакции Serializable в настоящее время недоступен в горячем резерве. (За подробностями обратитесь к Подразделу 13.2.3 и Подразделу 13.4.1) Попытка выставить для транзакции такой уровень изоляции в режиме горячего резерва вызовет ошибку.
