Репликация
Эта страница переведена при помощи нейросети GigaChat.
Эти настройки управляют поведением встроенной функции потоковой репликации (см. раздел «Потоковая репликация») и логической репликации. Серверы будут либо основным, либо резервным сервером. Основные серверы могут отправлять данные, тогда как резервные всегда являются получателями реплицируемых данных. При использовании каскадной репликации (см. Раздел «Каскадная репликация») резервные серверы также могут быть отправителями, а также получателями. Параметры предназначены главным образом для отправки и резервных серверов, хотя некоторые параметры имеют значение только на основном сервере. Настройки могут различаться по всему кластеру без проблем, если это требуется.
Для логической репликации публикующие серверы (серверы, выполняющие CREATE PUBLICATION) передают данные репликации подписчикам (серверам, выполняющим CREATE SUBSCRIPTION). Серверы также могут быть публикующими и подписчиками одновременно. Обратите внимание, что в следующих разделах публикующие серверы называются «передающими серверами» или «передатчиками».
Отправляющие серверы
Эти параметры могут быть установлены на любом сервере, который должен отправлять данные репликации одному или нескольким резервным серверам. Первичный всегда является отправляющим сервером, поэтому эти параметры должны всегда устанавливаться на первичном. Роль и значение этих параметров не изменяются после того, как резервный становится основным.
max_wal_senders (integer)
Задает максимальное количество одновременных подключений от резервных серверов или клиентов потокового базового резервного копирования (т.е. максимальное количество одновременно работающих процессов отправителя WAL). По умолчанию используется 10. Значение 0 означает, что репликация отключена. Внезапное отключение клиента потоковой передачи может оставить за собой осиротевший слот подключения до достижения тайм-аута, поэтому этот параметр следует установить немного выше максимального ожидаемого количества клиентов, чтобы отключенные клиенты могли немедленно переподключиться. Этот параметр можно задать только при запуске сервера. Кроме того, wal_level должно быть установлено на replica или выше для разрешения соединений с резервными серверами.
При работе с резервным сервером необходимо установить этот параметр на то же или более высокое значение, что и на основном сервере. В противном случае запросы не будут разрешены на резервном сервере.
max_replication_slots (integer)
Задает максимальное количество слотов репликации (см. раздел «Слоты репликации»), которые может поддерживать сервер. По умолчанию это 10. Этот параметр можно задать только при запуске сервера. Установка его значения ниже количества существующих в данный момент слотов репликации предотвратит запуск сервера. Также wal_level должен быть установлен на replica или выше, чтобы разрешить использование слотов репликации.
Обратите внимание, что этот параметр также применяется на стороне подписчика, но с другим значением.
wal_keep_size (integer)
Указывает минимальный размер сегментов журнала предыдущих записей, хранящихся в каталоге pg_wal, если резервный сервер должен получить их для потоковой репликации. Если подключенный к отправляющему серверу резервный сервер отстает более чем на wal_keep_size мегабайт, отправляющий сервер может удалить сегмент WAL, который все еще нужен резервному серверу, в этом случае соединение репликации будет прекращено. В результате также со временем потерпят неудачу и нисходящие соединения. (Однако резервный сервер может восстановиться, получив сегмент из архива, если используется архивирование WAL.)
Это задает только минимальный размер сегментов, сохраняемых в pg_wal; системе может потребоваться сохранить больше сегментов для архивирования WAL или восстановления после контрольной точки. Если wal_keep_size равен нулю (по умолчанию), система не сохраняет никаких дополнительных сегментов для целей резервного копирования, поэтому количество старых сегментов WAL, доступных для резервных серверов, является функцией местоположения предыдущей контрольной точки и состояния архивации WAL. Если это значение указано без единиц измерения, оно принимается за мегабайты. Этот параметр можно установить только в файле postgresql.conf или в командной строке сервера.
max_slot_wal_keep_size (integer)
Укажите максимальный размер файлов WAL, которые репликационные слоты могут сохранять в каталоге pg_wal во время контрольной точки. Если max_slot_wal_keep_size равен -1 (по умолчанию), репликационные слоты могут хранить неограниченное количество файлов WAL. В противном случае, если restart_lsn репликационного слота отстает от текущего LSN более чем на указанный размер, подчиненный сервер, использующий этот слот, может больше не иметь возможности продолжать репликацию из-за удаления необходимых файлов WAL. Можно увидеть доступность WAL для репликационных слотов в pg_replication_slots. Если это значение указано без единиц измерения, оно принимается за мегабайты. Этот параметр можно задать только в файле postgresql.conf или в командной строке сервера.
wal_sender_timeout (integer)
Прервите соединения репликации, которые неактивны дольше этого времени. Это полезно для отправляющего сервера, чтобы обнаружить сбой подчиненного сервера или сетевой отказ. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Значение по умолчанию составляет 60 секунд. Значение нуля отключает механизм тайм-аута.
При кластере, распределенном по нескольким географическим местоположениям, использование различных значений для каждого местоположения обеспечивает большую гибкость в управлении кластером. Меньшее значение полезно для более быстрого обнаружения сбоев с резервным копированием, имеющим сетевое соединение с низкой задержкой, а большее значение помогает лучше оценить состояние резерва, если он расположен в удаленном месте с высокозадержанным сетевым соединением.
track_commit_timestamp (boolean)
Запись времени фиксации транзакций. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера. Значение по умолчанию равно off.
synchronized_standby_slots (string)
Разделенный запятыми список имен слотов резервных серверов потоковой репликации, которых будут ожидать логические передающие 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, чтобы получать изменения слотов отработки отказа логической репликации от ведущего сервера.
Основной сервер
Эти параметры могут быть установлены на основном сервере, который должен отправлять данные репликации одному или нескольким резервным серверам. Обратите внимание, что помимо этих параметров, wal_level также должна быть установлена соответствующим образом на основном сервере, и дополнительно может быть включена архивация WAL (см. раздел Архивация). Значения этих параметров на резервных серверах не имеют значения, можно установить их там в подготовке к возможности того, что резервный сервер станет основным.
synchronous_standby_names (string)
Задает список резервных серверов, которые могут поддерживать синхронную репликацию, как описано в разделе Синхронная репликация. Будет одно или несколько активных синхронных резервных копий; транзакциям, ожидающим подтверждения, будет разрешено продолжить после того, как эти резервные серверы подтвердят получение своих данных. Синхронными резервными копиями будут те, чьи имена появляются в этом списке, и которые в настоящее время подключены и передают данные в реальном времени (как показано состоянием 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 - это имя резервного сервера. 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*s сравниваются с именами приложений резервного копирования без учета регистра, независимо от того, заключены ли они в двойные кавычки или нет.
Если здесь не указаны имена синхронных резервных копий, то синхронная репликация не включена и фиксация транзакций не будет ожидать репликации. Это конфигурация по умолчанию. Даже когда синхронная репликация включена, отдельные транзакции могут быть настроены так, чтобы не ждать репликации путем установки параметра synchronous_commit на local или off.
Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.
Резервные серверы
Эти настройки управляют поведением резервного сервера, который должен получать реплицируемые данные. Их значения на основном сервере не имеют значения.
primary_conninfo (string)
Задает строку подключения, которая будет использоваться для резервного сервера для подключения к отправляющему серверу. Если какой-либо параметр не указан в этой строке, то проверяется соответствующая переменная окружения. Если переменная окружения также не установлена, используются значения по умолчанию.
Строка подключения должна указывать имя хоста (или адрес) отправляющего сервера, а также номер порта, если он отличается от значения по умолчанию для резервного сервера. Также укажите имя пользователя, соответствующее соответствующей роли с достаточными привилегиями на отправляющем сервере (см. Раздел «Аутентификация»). Необходимо предоставить и пароль, если отправитель требует аутентификации по паролю. Он может быть предоставлен в строке primary_conninfo, или в отдельном файле ~/.pgpass на резервном сервере (используйте replication в качестве имени базы данных).
Для синхронизации слотов репликации также необходимо указать допустимое имя dbname в строке primary_conninfo. Оно используется только для синхронизации слотов и игнорируется при потоковой передаче.
Этот параметр можно задать только в файле postgresql.conf или в командной строке сервера. Если этот параметр изменяется во время работы процесса приемника WAL, этому процессу отправляется сигнал о завершении работы, и ожидается его перезапуск с новым значением (за исключением случая, когда primary_conninfo является пустой строкой). Это настройка не влияет, если сервер не находится в режиме ожидания.
primary_slot_name (string)
Необязательно указывает существующий слот репликации, который будет использоваться при подключении к отправляющему серверу через потоковую репликацию для управления удалением ресурсов на узле вверх по течению (см. раздел Слоты репликации). Этот параметр можно установить только в файле postgresql.conf или в командной строке сервера. Если этот параметр изменяется во время работы процесса приемника WAL, этому процессу отправляется сигнал о завершении работы, и ожидается его перезапуск с новым значением. Эта настройка не действует, если primary_conninfo не установлен или сервер не находится в режиме ожидания.
hot_standby (boolean)
Указывает, можно ли подключаться и выполнять запросы во время восстановления, как описано в разделе Горячее резервное копирование. Значение по умолчанию равно on. Этот параметр может быть установлен только при запуске сервера. Он действует только во время архивного восстановления или в режиме ожидания.
max_standby_archive_delay (integer)
Когда горячее резервное копирование активно, этот параметр определяет, сколько времени серверу ожидания следует ждать перед отменой запросов ожидания, которые конфликтуют с записями WAL, которые вот-вот будут применены, как описано в разделе Обработка конфликтов запросов. max_standby_archive_delay применяется, когда данные WAL читаются из архива WAL (и поэтому они не актуальны). Если это значение указано без единиц измерения, оно принимается за миллисекунды. По умолчанию - 30 секунд. Значение -1 позволяет ожиданию ждать завершения конфликтующих запросов бесконечно долго. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.
Обратите внимание, что max_standby_archive_delay не то же самое, что максимальная длина времени выполнения запроса перед его отменой; скорее это максимальное общее время, разрешенное для применения любых данных одного сегмента WAL. Таким образом, если один запрос привел к значительной задержке ранее в сегменте WAL, последующие конфликтующие запросы будут иметь гораздо меньше времени ожидания.
max_standby_streaming_delay (integer)
Когда горячий резерв активен, этот параметр определяет, сколько времени серверу резерва следует ждать перед отменой запросов резерва, которые конфликтуют с записями WAL, которые вот-вот будут применены, как описано в разделе Обработка конфликтов запросов . 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_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. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Значение по умолчанию равно пяти секундам. Этот параметр можно установить только в файле postgresql.conf или в командной строке сервера.
Этот параметр полезен в конфигурациях, где узел восстановления должен контролировать время ожидания доступности новых данных WAL. Например, при архивном восстановлении возможно сделать восстановление более отзывчивым к обнаружению нового файла журнала WAL путем уменьшения значения этого параметра. В системе с низкой активностью WAL увеличение его уменьшает количество необходимых запросов для доступа к архивам WAL, что полезно, например, в облачных средах, где учитывается количество обращений к инфраструктуре.
В логической репликации этот параметр также ограничивает частоту перезапуска неудачного рабочего процесса применения изменений репликации.
recovery_min_apply_delay (integer)
По умолчанию резервный сервер восстанавливает записи WAL с основного сервера как можно скорее. Может быть полезно иметь копию данных с задержкой по времени, предоставляя возможности для исправления ошибок потери данных. Этот параметр позволяет отложить восстановление на указанное время. Например, если установить этот параметр равным 5min, то резервная копия будет воспроизводить каждое подтверждение транзакции только тогда, когда системное время на резервной копии будет не менее чем на пять минут позже времени подтверждения, о котором сообщает основная система. Если это значение указано без единиц измерения, оно принимается за миллисекунды. По умолчанию равно нулю, добавление задержки отсутствует.
Возможно, что задержка репликации между серверами превышает значение этого параметра, и в этом случае дополнительная задержка не добавляется. Обратите внимание, что расчет задержки производится между меткой времени WAL, записанной на основном устройстве, и текущим временем на резервной копии. Задержки из-за сетевой задержки или каскадных конфигураций репликации могут значительно сократить фактическое время ожидания. Если системные часы на основной и резервной системах не синхронизированы, это может привести к тому, что процесс восстановления начнет применять записи раньше ожидаемого срока; но это не является серьезной проблемой, поскольку полезные настройки этого параметра намного больше типичных отклонений во времени между серверами.
Задержка происходит только для записей WAL для фиксации транзакций. Другие записи воспроизводятся так быстро, насколько это возможно, что не является проблемой, поскольку правила видимости MVCC гарантируют, что их эффекты не будут видны до применения соответствующей записи фиксации.
Задержка возникает после того, как база данных в процессе восстановления достигает согласованного состояния, пока резервная копия не будет повышена или активирована. После этого резервный сервер завершит восстановление без дополнительного ожидания.
Записи WAL должны храниться на резервной копии до тех пор, пока они не будут готовы к применению. Поэтому более длительные задержки приведут к большему накоплению файлов WAL, увеличивая требования к дисковому пространству для каталога pg_wal резервного сервера.
Этот параметр предназначен для использования с развертываниями потоковой репликации; однако, если этот параметр указан, он будет соблюдаться во всех случаях, за исключением восстановления после сбоя. hot_standby_feedback будет задерживаться при использовании этой функции, что может привести к повреждению основной системы; используйте оба параметра вместе с осторожностью.
Синхронная репликация зависит от этого параметра при установке synchronous_commit на remote_apply; каждая COMMIT должна будет дождаться применения.
Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.
sync_replication_slots (boolean)
Позволяет физическому резервному серверу синхронизировать слоты логической репликации для отработки отказа с ведущим сервером, чтобы подписчики логической репликации могли возобновить репликацию с нового ведущего сервера после отработки отказа.
По умолчанию отключен. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера.
Подписчики
Эти настройки управляют поведением подписчика логической репликации. Их значения на издателях не имеют значения.
max_replication_slots (integer)
Указывает, сколько источников репликации можно отслеживать одновременно, по сути ограничивая количество подписок на логическую репликацию, которые могут быть созданы на сервере. Если установленное значение будет меньше, чем текущее количество отслеживаемых источников репликации (показываемое в pg_replication_origin_status), сервер не запустится. Значение параметра max_replication_slots должно быть не менее числа подписок, добавляемого подписчику, плюс некоторый резерв для синхронизации таблиц.
Обратите внимание, что этот параметр также применяется на стороне передающего сервера, но с другим значением.
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.
Значение по умолчанию — 2. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера.