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

Обычно, передача журналов между серверами, работающими на разных основных версиях Tantor BE, невозможна. Политика Глобальной группы разработки PostgreSQL состоит в том, чтобы не вносить изменения в форматы диска во время обновления минорных версий, поэтому вероятно, что работа с разными минорными версиями на основном и резервном серверах будет успешной. Однако, формальная поддержка этого не предоставляется, и вам рекомендуется держать основные и резервные серверы на одном уровне версии насколько это возможно. При обновлении до новой минорной версии, наиболее безопасной политикой является обновление резервных серверов в первую очередь - новая минорная версия, скорее всего, сможет прочитать 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, будет восстановлен, но попыток подключиться к основному серверу не предпринимается.

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

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

Сделайте базовую резервную копию, как описано в Раздел 24.3.2, чтобы настроить резервный сервер.

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

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

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

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

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

Для использования потоковой репликации настройте резервный сервер с доставкой журналов на основе файлов, как описано в разделе Раздел 25.2. Шагом, превращающим резервный сервер с доставкой журналов на основе файлов в резервный сервер с потоковой репликацией, является установка параметра primary_conninfo для указания на основной сервер. На основном сервере установите параметры listen_addresses и параметры аутентификации (см. файл pg_hba.conf), чтобы резервный сервер мог подключиться к псевдо-базе данных replication на основном сервере (см. раздел Раздел 25.2.5.1).

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

Установите максимальное количество одновременных соединений от резервных серверов (см. max_wal_senders для получения подробной информации).

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

# Allow the user "foo" from host 192.168.1.100 to connect to the primary
# as a replication standby if the user's password is correctly supplied.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     foo             192.168.1.100/32        md5

# The standby connects to the primary that is running on host 192.168.1.50
# and port 5432 as the user "foo" whose password is "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, что они заполняют выделенное пространство для pg_wal; параметр max_slot_wal_keep_size ограничивает размер сохраняемых слотами репликации файлов журнала предзаписи.

Аналогично, 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 row)

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

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

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

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

В настоящее время каскадная репликация является асинхронной. Настройки синхронной репликации (см. Раздел 25.2.8) в настоящее время не влияют на каскадную репликацию.

Горячая резервная связь передается вверх по цепочке, независимо от каскадного расположения.

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

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

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

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

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

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

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