18.6. Репликация#

18.6. Репликация

18.6. Репликация
Назад	Наверх	Глава 18. Конфигурация сервера	Начало	Далее

18.6. Репликация #

18.6.1. Отправляющие серверы
18.6.2. Основной сервер
18.6.3. Резервные серверы
18.6.4. Подписчики

Эти настройки управляют поведением встроенной функции потоковой репликации (см. Раздел 25.2.5), и встроенной функции логической репликации (см. Глава 28).

Для потоковой репликации серверы будут либо основными, либо резервными. Основные серверы могут отправлять данные, в то время как резервные всегда являются получателями реплицированных данных. Когда используется каскадная репликация (см. Раздел 25.2.7), резервные серверы могут быть как отправителями, так и получателями. Параметры в основном предназначены для отправляющих и резервных серверов, хотя некоторые параметры имеют значение только на основном сервере. Настройки могут различаться в кластере без проблем, если это необходимо.

Для логической репликации, издатели (серверы, которые выполняют CREATE PUBLICATION) реплицируют данные на подписчиков (серверы, которые выполняют CREATE SUBSCRIPTION). Серверы могут быть одновременно и издателями, и подписчиками. Обратите внимание, что в следующих разделах издатели упоминаются как "отправители". Для получения дополнительной информации о настройках конфигурации логической репликации обратитесь к Раздел 28.12.

18.6.1. Отправляющие серверы #

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

max_wal_senders (integer) #

Определяет максимальное количество одновременных соединений от серверов-реплик или клиентов потокового резервного копирования базы данных (т.е. максимальное количество одновременно работающих процессов отправки WAL). Значение по умолчанию - 10. Значение 0 означает отключение репликации. Внезапное отключение потокового клиента может оставить за собой неиспользуемый слот подключения до достижения тайм-аута, поэтому этот параметр должен быть установлен немного выше максимального количества ожидаемых клиентов, чтобы отключенные клиенты могли сразу же повторно подключиться. Этот параметр может быть установлен только при запуске сервера. Кроме того, параметр wal_level должен быть установлен на значение replica или выше, чтобы разрешить подключения от серверов-реплик.

При работе с резервным сервером необходимо установить этот параметр на такое же или более высокое значение, чем на основном сервере. В противном случае запросы на резервном сервере не будут разрешены.

max_replication_slots (integer) #

Определяет максимальное количество слотов репликации (см. Раздел 25.2.6) , которое сервер может поддерживать. По умолчанию значение равно 10. Этот параметр может быть установлен только при запуске сервера. Установка значения меньше количества существующих слотов репликации приведет к невозможности запуска сервера. Кроме того, параметр wal_level должен быть установлен на значение replica или выше, чтобы использовать слоты репликации.

wal_keep_size (integer) #

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

Это устанавливает только минимальный размер сегментов, сохраняемых в pg_wal; система может потребоваться сохранить больше сегментов для архивирования WAL или для восстановления после контрольной точки. Если wal_keep_size равно нулю (по умолчанию), система не сохраняет дополнительные сегменты для целей ожидания, поэтому количество старых сегментов WAL, доступных для серверов ожидания, является функцией расположения предыдущей контрольной точки и статуса архивирования WAL. Если это значение указано без единиц измерения, оно принимается в мегабайтах. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

max_slot_wal_keep_size (integer) #

Укажите максимальный размер файлов журнала предзаписи, которые разрешено сохранять слотам репликации в каталоге pg_wal во время контрольной точки. Если max_slot_wal_keep_size равно -1 (по умолчанию), слоты репликации могут сохранять неограниченное количество файлов журнала предзаписи. В противном случае, если restart_lsn слота репликации отстает от текущего LSN на более чем заданный размер, стендбай, использующий этот слот, может больше не иметь возможности продолжать репликацию из-за удаления необходимых файлов журнала предзаписи. Вы можете увидеть доступность файлов журнала предзаписи для слотов репликации в представлении pg_replication_slots. Если это значение указано без единиц измерения, оно считается заданным в мегабайтах. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

idle_replication_slot_timeout (integer) #

Аннулирует слоты репликации, которые оставались неактивными (не использовались подключением для репликации) дольше указанного времени. Если это значение указано без единиц измерения, оно принимается в секундах. Значение ноль (по умолчанию) отключает механизм аннулирования по тайм-ауту простоя. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

Аннулирование слота из-за тайм-аута простоя выполняется во время контрольной точки. Поскольку контрольные точки запускаются с интервалом checkpoint_timeout, может возникать некоторая задержка между моментом превышения значения idle_replication_slot_timeout, и аннулированием слота в следующей контрольной точке. Чтобы избежать таких задержек, можно принудительно аннулировать неактивный слот в контрольной точке. Длительность неактивности слота вычисляется с использованием значения pg_replication_slots.inactive_since слота.

Обратите внимание, что механизм аннулирования по тайм-ауту простоя не применяется к слотам, которые не резервируют WAL, и к слотам на резервном сервере, которые синхронизируются с основным сервером (т.е. резервные слоты, у которых в представлении pg_replication_slots поле.synced установлено в значение true). Синхронизированные слоты всегда считаются неактивными, потому что они не выполняют логическое декодирование для формирования изменений.

wal_sender_timeout (integer) #

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

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

track_commit_timestamp (boolean) #

Записывает время фиксации транзакций. Этот параметр можно установить только при запуске сервера. Значение по умолчанию — off.

18.6.2. Основной сервер #

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

synchronous_standby_names (string) #

Определяет список резервных серверов, которые могут поддерживать синхронную репликацию, как описано в Раздел 25.2.8. Будет один или более активных синхронных резервов; транзакции, ожидающие коммита, будут разрешены к выполнению после того, как эти резервные серверы подтвердят получение их данных. Синхронные резервные серверы будут назнаечены, чьи имена указаны в этом списке и которые в настоящее время подключены и передают данные в режиме реального времени (как показано состоянием streaming в представлении pg_stat_replication). Указание более одного синхронного резервного сервера может обеспечить очень высокую доступность и надежную защиту от потери данных.

В качестве имени сервера-резерва для этой цели используется параметр application_name на стенде, установленный в информации о подключении стенда. В случае физической репликации стенда это должно быть установлено в параметре primary_conninfo; по умолчанию используется значение параметра cluster_name, если оно установлено, иначе walreceiver. Для логической репликации это может быть установлено в информации о подписке, и по умолчанию используется имя подписки. Для других потребителей потока репликации обратитесь к их документации.

Этот параметр определяет список резервных серверов с использованием одного из следующих синтаксисов:

[FIRST] num_sync ( standby_name [, ...] )
ANY num_sync ( standby_name [, ...] )
standby_name [, ...]

где num_sync — это количество синхронных резервных серверов, от которых нужно получить ответ для завершения транзакций, а standby_name — это имя резервного сервера. num_sync должно быть целым числом больше нуля. FIRST и ANY определяют способ выбора синхронных резервных серверов из перечисленных серверов.

Ключевое слово FIRST, в сочетании с num_sync, определяет приоритетную синхронную репликацию и заставляет коммит транзакций ожидать, пока их записи WAL не будут тиражированы на num_sync синхронных стендбай, выбранных на основе их приоритетов. Например, установка FIRST 3 (s1, s2, s3, s4) заставит каждый коммит ожидать ответов от трех стендбай с более высоким приоритетом, выбранных из стендбай-серверов s1, s2, s3 и s4. Стендбай, имена которых появляются раньше в списке, имеют более высокий приоритет и считаются синхронными. Другие стендбай-серверы, появляющиеся позже в этом списке, являются потенциальными синхронными стендбай. Если какой-либо из текущих синхронных стендбай отключается по какой-либо причине, он будет немедленно заменен следующим стендбай с более высоким приоритетом. Ключевое слово FIRST является необязательным.

Ключевое слово ANY, в сочетании с num_sync, определяет кворумную синхронную репликацию и заставляет коммит транзакций ожидать, пока их записи WAL не будут тиражированы как минимум на num_sync указанных резервных серверах. Например, установка ANY 3 (s1, s2, s3, s4) приведет к тому, что каждый коммит будет выполняться, как только как минимум три резервных сервера s1, s2, s3 и s4 ответят.

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

Третий синтаксис использовался до версии PostgreSQL 9.6 и до сих пор поддерживается. Он аналогичен первому синтаксису с FIRST и num_sync, равными 1. Например, FIRST 1 (s1, s2) и s1, s2 имеют одно и то же значение: либо выбирается s1, либо s2 в качестве синхронного резервного сервера.

Специальная запись * соответствует любому имени резервного сервера.

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

Примечание

Каждое имя standby_name должно иметь форму допустимого идентификатора SQL, если только оно не является *. При необходимости можно использовать двойные кавычки. Однако следует отметить, что имена standby_name сравниваются с именами standby-приложений без учета регистра, независимо от наличия двойных кавычек.

Если здесь не указаны имена синхронных резервных копий, то синхронная репликация не включена и коммит транзакций не будет ожидать репликации. Это конфигурация по умолчанию. Даже когда синхронная репликация включена, отдельные транзакции могут быть настроены не ожидать репликации, установив параметр synchronous_commit в значение local или off.

Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

synchronized_standby_slots (string) #

Список имен слотов резервных серверов потоковой репликации, разделенных запятыми, которых процессы логической отправки WAL будут ожидать. Процессы логической отправки WAL будут отправлять декодированные изменения в плагины только после того, как указанные слоты репликации подтвердят получение WAL. Это гарантирует, что слоты логической репликации для аварийного переключения не потребляют изменения до тех пор, пока эти изменения не будут получены и сброшены на соответствующие физические резервные копии. Если логическое соединение репликации предназначено для переключения на физическую резервную копию после повышения резервной копии, физический слот репликации для резервной копии должен быть указан здесь. Обратите внимание, что логическая репликация не будет продолжаться, если слоты, указанные в synchronized_standby_slots, не существуют или аннулированы. Кроме того, функции управления репликацией pg_replication_slot_advance, pg_logical_slot_get_changes и pg_logical_slot_peek_changes, при использовании с логическими слотами аварийного переключения, будут блокироваться до тех пор, пока все физические слоты, указанные в synchronized_standby_slots, не подтвердят получение WAL.

Резервные серверы, соответствующие физическим слотам репликации в synchronized_standby_slots, должны настроить sync_replication_slots = true, чтобы они могли получать изменения логических слотов переключения с основного сервера.

18.6.3. Резервные серверы #

Эти настройки управляют поведением резервного сервера, который предназначен для получения данных репликации. Их значения на основном сервере не имеют значения.

primary_conninfo (string) #

Указывает строку подключения, которая будет использоваться для резервного сервера для подключения к отправляющему серверу. Эта строка имеет формат, описанный в Раздел 30.1.1. Если какая-либо опция не указана в этой строке, то проверяется соответствующая переменная среды (см. Раздел 30.15). Если переменная среды также не установлена, то используются значения по умолчанию.

Строка подключения должна указывать имя хоста (или адрес) отправляющего сервера, а также номер порта, если он отличается от порта по умолчанию резервного сервера. Также укажите имя пользователя, соответствующее роли с подходящими привилегиями на отправляющем сервере (см. Раздел 25.2.5.1). Пароль также должен быть предоставлен, если отправитель требует аутентификацию по паролю. Он может быть указан в строке primary_conninfo или в отдельном файле ~/.pgpass на резервном сервере (используйте replication в качестве имени базы данных).

Для синхронизации слотов репликации (см. Раздел 45.2.3), также необходимо указать допустимый dbname в строке primary_conninfo. Это будет использоваться только для синхронизации слотов. Для потоковой передачи это игнорируется.

Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера. Если этот параметр изменяется во время работы приемника WAL, этот процесс получает сигнал о завершении работы и ожидается, что он перезапустится с новыми настройками (за исключением случая, когда primary_conninfo является пустой строкой). Эта настройка не работает, если сервер не находится в режиме ожидания.

primary_slot_name (string) #

Параметр, который опционально указывает существующий слот репликации, который будет использоваться при подключении к отправляющему серверу через потоковую репликацию для контроля удаления ресурсов на узле-источнике (см. Раздел 25.2.6). Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера. Если этот параметр изменяется во время работы приемника WAL, этот процесс получает сигнал о завершении работы и ожидается его перезапуск с новыми настройками. Эта настройка не активируется, если primary_conninfo не установлен или сервер не находится в режиме ожидания.

hot_standby (boolean) #

Определяет, можете ли вы подключаться и выполнять запросы во время восстановления, как описано в Раздел 25.4. Значение по умолчанию - on. Этот параметр может быть установлен только при запуске сервера. Он имеет эффект только во время восстановления из архива или в режиме ожидания.

enable_temp_table_on_replica (boolean) #

Позволяет создавать и использовать временные таблицы на физической реплике с поддержкой транзакций и корректной видимости строк временных таблиц на реплике. По умолчанию — false.

Когда этот параметр включен, Tantor SE-1C автоматически включает параметр enable_temp_memory_catalog, потому что метаданные временных таблиц на репликах требуют инфраструктуру каталога в памяти.

replica_xid_window_size (integer) #

Устанавливает размер окна битовой карты, используемого для отслеживания последних локальных идентификаторов транзакций реплики при проверках видимости временных таблиц. Допустимые значения — от 128 до 1048576. Значение по умолчанию — 65536.

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

Параметр связан с параметром enable_temp_table_on_replica.

max_standby_archive_delay (integer) #

Когда горячий режим ожидания активен, этот параметр определяет, как долго резервный сервер должен ждать, прежде чем отменить запросы резервного режима, которые конфликтуют с записями WAL, которые собираются примениться, как описано в Раздел 25.4.2. max_standby_archive_delay применяется, когда данные WAL считываются из архива WAL (и, следовательно, не являются актуальными). Если это значение указано без единиц измерения, оно считается заданным в миллисекундах. По умолчанию установлено значение 30 секунд. Значение -1 позволяет резервному серверу ждать бесконечно долго, пока конфликтующие запросы не завершатся. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

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

max_standby_streaming_delay (integer) #

Когда горячий резервный сервер активен, этот параметр определяет, как долго резервный сервер должен ждать, прежде чем отменить запросы резервного сервера, которые конфликтуют с записями WAL, которые собираются примениться, как описано в Раздел 25.4.2. max_standby_streaming_delay применяется, когда данные WAL принимаются через потоковую репликацию. Если это значение указано без единиц измерения, оно считается заданным в миллисекундах. По умолчанию установлено значение 30 секунд. Значение -1 позволяет резервному серверу ждать бесконечно долго, чтобы завершить конфликтующие запросы. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

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

wal_receiver_create_temp_slot (boolean) #

Определяет, должен ли процесс получения WAL создавать временный слот репликации на удаленном экземпляре, когда не настроен постоянный слот репликации (с использованием primary_slot_name). По умолчанию отключено. Этот параметр можно установить только в файле postgresql.conf или в командной строке сервера. Если этот параметр изменяется во время работы приемника WAL, этот процесс получает сигнал о завершении работы и ожидается, что он перезапустится с новыми настройками.

wal_receiver_start_at (enum) #

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

Допустимые значения:

exhaust — запускается только после воспроизведения всех записей WAL из архива и pg_wal. Это стандартное поведение PostgreSQL, обратная совместимость полностью сохранена.
consistency — запускается после достижения точки консистентности (consistent recovery state). Это момент, когда реплика может принимать read-only подключения.
При достижении консистентности процесс запуска сканирует pg_wal, находит последний валидный WAL-сегмент и запрашивает потоковую передачу с его начала. Воспроизведение более ранних записей продолжается параллельно с потоковой передачей. Рекомендуемое значение для большинства сценариев раннего запуска.
startup — запускается немедленно при старте резервного сервера, до достижения консистентности. Точка начала потоковой передачи определяется так же, как и для consistency.
Это полезно в ситуациях, когда даже достижение консистентности занимает значительное время (большой бэклог в pg_wal).

Значение по умолчанию — exhaust.

Традиционно процесс WAL-приёмника запускается только после того, как резервный сервер исчерпал весь WAL из архива WAL и локального каталога pg_wal. В некоторых средах может оставаться значительный объём локального WAL для воспроизведения, а также большой объём WAL, который ещё предстоит получить по сети. В таких случаях может быть полезно установить wal_receiver_start_at в значение startup или consistency. Эти значения приведут к более раннему запуску WAL-приёмника — с конца локально доступного WAL. Сеть будет использоваться для одновременной передачи WAL и его воспроизведения, что значительно повысит производительность.

Исключение: ранний запуск WAL receiver пропускается, если настроено архивное восстановление (задан restore_command). Причины:

Одновременная работа WAL receiver и процесса восстановления из архива создает условия для состояния гонки между WAL receiver и checkpointer. Эта проблема ранее была ранее исправлена в upstream и не воспроизводится только при условии, что WAL receiver не запускается во время архивного восстановления.
Восстановление из архива, как правило, быстрее потоковой репликации для тех же сегментов, поэтому ранний запуск в этом случае не приносит пользы.

Сценарии использования:

Синхронная репликация с отставанием. При synchronous_commit = on и перезапуске реплики заблокированные коммиты на основном сервере разблокируются сразу после запуска WAL receiver и подтверждения flush, без ожидания полного воспроизведения.
Высокое значение recovery_min_apply_delay. При настроенной задержке применения (например, 2 часа), WAL receiver начинает потоковую передачу немедленно. WAL накапливается локально, и в случае сбоя основной базы реплика содержит все необходимые записи для быстрого промоутинга.
Восстановление после сетевого сбоя. После кратковременного разрыва сети реплика возобновляет потоковую передачу раньше, сокращая окно, в течение которого существует только одна копия WAL.
Восстановление без архива. Для реплик без restore_command восстановление ускоряется за счет параллельной потоковой передачи и воспроизведения.

Ограничения:

Требуется перезапуск — параметр имеет контекст PGC_POSTMASTER, изменение через pg_reload_conf() невозможно.
Не работает при архивном восстановлении — при наличии restore_command, ранний запуск пропускается.
Смена timeline — при обнаружении WAL-сегментов с разными timeline ранний запуск отменяется.
Нет проверки на "дыры" в "pg_wal" — если в каталоге отсутствуют промежуточные сегменты (например, из-за некорректной резервной копии), потоковая передача может начаться с более позднего сегмента. Этот вопрос обсуждался в теме, но пока не реализован.
Пустые сегменты — WAL-файлы с нулевыми байтами вызывают WALReadRaiseError() вместо пропуска. Отмечено в патче как известная проблема.

Пример настройки:

# postgresql.conf on the replica
wal_receiver_start_at = 'consistency'
primary_conninfo = 'host=primary port=5432 user=replicator'

Перезапуск реплики:

pg_ctl restart -D /path/to/standby/data

Ожидаемые сообщения в логе:

LOG:  requesting stream from beginning of: "000000010000000000000042"
LOG:  started streaming WAL from primary at 0/42000000 on timeline 1

wal_receiver_status_interval (integer) #

Определяет минимальную частоту, с которой приемник WAL на резервном сервере отправляет информацию о ходе репликации на основной сервер или на другой резервный сервер, где она может быть просмотрена с помощью представления pg_stat_replication. Резервный сервер будет сообщать о последней записанной позиции журнала предварительной записи, последней позиции, которая была записана на диск, и последней позиции, которая была применена. Значение этого параметра является максимальным временным интервалом между отчетами. Обновления отправляются каждый раз, когда изменяются позиции записи или сброса, или так часто, как указано в этом параметре, если он установлен в ненулевое значение. Есть дополнительные случаи, когда обновления отправляются, игнорируя этот параметр; например, когда обработка существующего WAL завершается или когда synchronous_commit установлено в remote_apply. Таким образом, позиция применения может немного отставать от реальной позиции. Если это значение указано без единиц измерения, оно считается заданным в секундах. Значение по умолчанию - 10 секунд. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

hot_standby_feedback (boolean) #

Определяет, будет ли горячий резервный экземпляр отправлять обратную связь основному или вторичному резервному экземпляру о текущих выполняющихся запросах на резервном экземпляре. Этот параметр может использоваться для предотвращения отмены запросов, вызванных записями очистки, но может вызывать раздутие базы данных на основном экземпляре для некоторых рабочих нагрузок. Сообщения обратной связи не будут отправляться чаще, чем один раз за интервал wal_receiver_status_interval. Значение по умолчанию - off. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

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

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

wal_receiver_timeout (integer) #

Прекращайте подключения для репликации, которые неактивны в течение времени, превышающего эту величину. Это полезно для приемного сервера резервной копии для обнаружения сбоя основного узла или сбоя сети. Если это значение указано без единиц измерения, оно принимается в качестве миллисекунд. Значение по умолчанию - 60 секунд. Значение нуль отключает механизм тайм-аута. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

wal_retrieve_retry_interval (integer) #

Указывает, как долго резервный сервер должен ждать, когда данные WAL недоступны из любых источников (потоковая репликация, локальный файл pg_wal или архив WAL), прежде чем повторно попытаться получить данные WAL. Если это значение указано без единиц измерения, оно считается заданным в миллисекундах. Значение по умолчанию - 5 секунд. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

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

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

recovery_min_apply_delay (integer) #

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

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

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

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

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

Этот параметр предназначен для использования в развертываниях потоковой репликации; однако, если параметр указан, он будет учитываться во всех случаях, кроме восстановления после сбоя. hot_standby_feedback будет задерживаться при использовании этой функции, что может привести к раздутию на основном сервере; используйте оба параметра вместе с осторожностью.

Предупреждение

Синхронная репликация зависит от этой настройки, когда значение synchronous_commit установлено в remote_apply; каждый COMMIT будет ожидать применения.

Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

sync_replication_slots (boolean) #

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

Он отключен по умолчанию. Этот параметр можно установить только в postgresql.conf файле или в командной строке сервера.

18.6.4. Подписчики #

Эти настройки управляют поведением подписчика логической репликации. Их значения на издателе не имеют значения. См. Раздел 28.12 для получения дополнительных сведений.

max_active_replication_origins (integer) #

Определяет, сколько источников репликации (см. Глава 46) может отслеживаться одновременно, фактически ограничивая количество подписок на логическую репликацию, которые могут быть созданы на сервере. Если установлено значение ниже текущего количества отслеживаемых источников репликации (отражается в pg_replication_origin_status) сервер не запустится. По умолчанию установлено значение 10. Этот параметр можно задать только при запуске сервера. max_active_replication_origins должен быть установлен как минимум равным количеству подписок, добавляемых подписчику, плюс некоторый резерв для синхронизации таблиц.

max_logical_replication_workers (integer) #

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

Рабочие процессы логической репликации берутся из пула, определенного параметром max_worker_processes.

Значение по умолчанию равно 4. Этот параметр может быть установлен только при запуске сервера.

max_sync_workers_per_subscription (integer) #

Максимальное количество рабочих процессов синхронизации на подписку. Этот параметр контролирует объем параллельной обработки данных при копировании начальных данных во время инициализации подписки или при добавлении новых таблиц.

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

Рабочие процессы синхронизации берутся из пула, определенного параметром max_logical_replication_workers.

Значение по умолчанию равно 2. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

max_parallel_apply_workers_per_subscription (integer) #

Максимальное количество параллельных рабочих процессов применения изменений для каждой подписки. Этот параметр контролирует объем параллельной обработки данных для потоковой передачи незавершенных транзакций с параметром подписки streaming = parallel.

Параллельные рабочие процессы применения изменений берутся из пула, определенного max_logical_replication_workers.

Назад	Наверх	Далее
18.5. Журнал записи перед обработкой	Начало	18.7. Планирование запросов