Как правило, рекомендуется настраивать основной и резервный серверы таким образом, чтобы они были максимально идентичны, по крайней мере, с точки зрения сервера базы данных. В частности, пути к каталогам, связанные с табличными пространствами, передаются без изменений, поэтому и основной, и резервный серверы должны иметь одинаковые пути монтирования для табличных пространств, если используется данная функция. Следует учитывать, что если CREATE TABLESPACE выполняется на основном узле, любые необходимые для этого новые точки монтирования должны быть созданы на основном и всех резервных серверах до момента выполнения команды. Аппаратное обеспечение не обязательно должно быть полностью идентичным, однако опыт показывает, что обслуживание двух одинаковых систем проще, чем поддержка двух различных конфигураций в течение жизненного цикла приложения и системы. В любом случае архитектура оборудования должна быть одинаковой — передача журналов, например, с 32-разрядной системы на 64-разрядную, функционировать не будет.

Как правило, передача журналов между серверами с различными основными Digital Q.DataBase версиями выпусков невозможна. Политика PostgreSQL Global Development Group состоит в том, чтобы не вносить изменения в дисковые форматы при обновлении минорных версий, поэтому функционирование основного и резервного серверов с разными минорными версиями выпуска, скорее всего, будет успешным. Тем не менее, официальная поддержка таких конфигураций не предоставляется, и рекомендуется по возможности поддерживать основной и резервный серверы на одном уровне версии выпуска. При переходе на новую минорную версию наиболее безопасным сценарием является первоначальное обновление резервных серверов — новая минорная версия с большей вероятностью сможет прочитать файлы WAL предыдущей минорной версии, чем наоборот.

Сервер переходит в режим ожидания, если standby.signal файл присутствует в каталоге данных при запуске сервера.

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

При запуске резервный узел начинает восстановление всех записей журнала WAL, доступных в месте расположения архива, вызывая функцию restore_command. Как только процесс достигает конца доступных в архиве записей журнала WAL и restore_command завершается сбоем, система пытается восстановить любые записи журнала WAL, доступные в pg_wal каталоге. Если данная операция завершается неудачно и настроена потоковая репликация, резервный узел пытается установить соединение с основным сервером для запуска потоковой передачи журнала WAL с последней корректной записи, найденной в архиве или pg_wal. Если данная операция завершается ошибкой, потоковая репликация не настроена или соединение впоследствии разрывается, резервный узел возвращается к шагу 1 и повторно пытается восстановить файл из архива. Данный цикл повторных попыток получения данных из архива, pg_wal, и посредством потоковой репликации продолжается до тех пор, пока работа сервера не будет завершена или он не будет переведен в основной режим.

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

Настройте механизм непрерывного архивирования на основном узле в каталог архива, доступный с резервного узла, как описано в Раздел 3.10.3. Хранилище архива должно быть доступно с резервного узла даже при отказе основного сервера; таким образом, оно должно располагаться на самом резервном сервере или другом доверенном сервере, а не на основном сервере.

Для использования механизма потоковой репликации необходимо настроить аутентификацию на основном сервере, разрешив подключения для репликации со стороны резервных серверов; в частности, следует создать роль и добавить соответствующие записи в файл pg_hba.conf с указанием значения в поле базы данных репликация. Также убедитесь, что параметр max_wal_senders установлено достаточно большое значение в конфигурационном файле основного сервера. Если будут использоваться слоты репликации, необходимо убедиться, что max_replication_slots также является достаточно высоким.

Создайте базовую резервную копию согласно инструкциям в Раздел 3.10.3.2 для инициализации резервного сервера.

Для настройки резервного сервера выполните восстановление из базовой резервной копии, полученной с основного сервера (см. Раздел 3.10.3.5). Создайте файл standby.signal в каталоге данных кластера резервного узла. Задайте в качестве значения параметра restore_command команду для копирования файлов из архива WAL. Если в целях обеспечения отказоустойчивости планируется развертывание нескольких резервных серверов, убедитесь, что параметр recovery_target_timeline принимает значение latest (значение по умолчанию), чтобы резервный сервер переходил на новую линию времени, возникающую при отработке отказа на другой резервный узел.

Для использования потоковой репликации укажите в параметре primary_conninfo с помощью строки подключения libpq, включающей имя узла (или IP-адрес) и любые дополнительные параметры, необходимые для подключения к основному серверу. Если для аутентификации на основном сервере требуется пароль, его также необходимо указать в primary_conninfo as well.

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

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

Простой пример конфигурации:

primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass options=''-c wal_sender_timeout=5000'''
restore_command = 'cp /path/to/archive/%f %p'
archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'

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

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

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

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

Для использования потоковой репликации настройте резервный сервер с функцией файловой передачи журналов, как описано в Раздел 3.11.2. Операцией, преобразующей резервный узел с файловой передачей журналов в резервный узел с потоковой репликацией, является настройка параметра primary_conninfo параметр для указания на основной сервер. Установите listen_addresses и параметры аутентификации (см. pg_hba.conf) на основном узле, чтобы резервный сервер мог подключиться к репликация псевдобазе данных на основном сервере (см. Раздел 3.11.2.5.1).

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

Установите максимальное количество одновременных подключений со стороны резервных серверов (подробности см. в max_wal_senders for details).

Когда резервный узел запущен и параметр primary_conninfo настроен корректно, резервный узел подключится к основному узлу после воспроизведения всех файлов WAL, доступных в архиве. Если соединение установлено успешно, на резервном узле появится процесс walreceiver , а на основном узле — соответствующий ему процесс walsender process in the primary.

# Разрешить пользователю "foo" с хоста 192.168.1.100 подключаться к основному узлу
# в качестве резервного узла репликации при условии корректного указания пароля.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     foo             192.168.1.100/32        md5

# Резервный узел подключается к основному узлу, запущенному на хосте 192.168.1.50
# и порту 5432, под пользователем "foo" с паролем "foopass".
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'

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

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

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

postgres=# SELECT * FROM pg_create_physical_replication_slot('node_a_slot');
  slot_name  | lsn
-------------+-----
 node_a_slot |

postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;
  slot_name  | slot_type | active
-------------+-----------+--------
 node_a_slot | physical  | f
(1 строка)

primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
primary_slot_name = 'node_a_slot'

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

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

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

Каскадная репликация в настоящее время является асинхронной. Параметры механизма «Синхронная репликация» (см. Раздел 3.11.2.8) в настоящее время не влияют на работу каскадной репликации.

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

Если вышестоящий резервный сервер назначается новым основным узлом, нижестоящие серверы продолжат принимать поток данных от нового основного узла, если параметр recovery_target_timeline имеет значение 'latest' (по умолчанию).

Для использования каскадной репликации настройте каскадный резервный узел на прием соединений репликации (то есть установите параметр max_wal_senders и hot_standby, и настройте идентификацию на основе сетевого адреса узла). Вам также потребуется установить значение параметра primary_conninfo на нижестоящем резервном узле таким образом, чтобы он указывал на каскадный резервный узел.

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

Синхронная репликация позволяет подтвердить, что все изменения, внесенные транзакцией, были переданы на один или несколько синхронных резервных серверов. Это расширяет стандартный уровень долговечности, обеспечиваемый механизмом фиксации транзакции. В теории вычислительных систем данный уровень защиты классифицируется как репликация типа 2-safe, а также group-1-safe (group-safe и 1-safe), когда synchronous_commit принимает значение remote_write.

При использовании режима синхронной репликации каждая фиксация транзакции записи ожидает получения подтверждения того, что запись о фиксации была внесена в журнал упреждающей записи на дисках как основного, так и резервного сервера. Единственная возможность потери данных заключается в одновременном сбое основного и резервного узлов. Данный механизм обеспечивает значительно более высокий уровень долговечности при условии, что системный администратор ответственно подходит к размещению и управлению обоими серверами. Ожидание подтверждения повышает уверенность пользователя в сохранности изменений в случае сбоя сервера, однако это неизбежно увеличивает время отклика запрашивающей транзакции. Минимальное время ожидания определяется временем кругового обхода (round-trip time) между основным и резервным узлами.

Транзакции в режиме «только чтение» и операции отката транзакций не требуют ожидания подтверждения от резервных серверов. При фиксации подтранзакций ожидания ответов от резервных серверов не происходит; оно требуется только для фиксации транзакций верхнего уровня. Длительные операции, такие как загрузка данных или создание индексов, не требуют ожидания до момента отправки финального сообщения о фиксации транзакции. Все действия в рамках протокола двухфазной фиксации требуют ожидания подтверждения, включая этапы подготовки (prepare) и фиксации транзакции (commit).

Синхронным резервным узлом может являться узел физической репликации или подписчик логической репликации. Роль такого узла может выполнять любой другой потребитель потока репликации WAL (физического или логического), поддерживающий отправку соответствующих сообщений обратной связи. Помимо встроенных механизмов физической и логической репликации, сюда относятся специализированные программы, такие как pg_receivewal и pg_recvlogical а также некоторые сторонние системы репликации и пользовательские приложения. Для получения подробных сведений о поддержке синхронной репликации обратитесь к соответствующей документации.

synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'

synchronous_standby_names = 'ANY 2 (s1, s2, s3)'

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

Если archive_mode имеет значение on, то механизм архивирования не задействуется в процессе восстановления или в режиме ожидания. Если роль резервного сервера повышается до основного, он начнет архивирование после смены роли, но не будет архивировать те файлы WAL или файлы истории линий времени, которые он не генерировал самостоятельно. Чтобы получить полную серию файлов WAL в архиве, необходимо убедиться, что все данные WAL заархивированы до того, как они попадут на резервный узел. Это условие по умолчанию выполняется при файловой передаче журналов, так как резервный узел может восстанавливать только те файлы, которые находятся в архиве; однако при использовании потоковой репликации это не так. Когда сервер не находится в режиме восстановления, разницы между on и always режимами нет.