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

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

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

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

При обычных условиях через логический слот каждое изменение передаётся только один раз. Текущая позиция в каждом слоте сохраняется только в контрольной точке, так что в случае сбоя слот мог вернуться к предыдущему LSN, вследствие чего последние изменения могут быть переданы повторно при перезапуске сервера. За исключение нежелательных эффектов от повторной обработки одного и того же сообщения отвечают клиенты логического декодирования. Клиенты могут запоминать при декодировании, какой последний LSN они уже получали, и пропускать повторяющиеся данные или (при использовании протокола репликации) запрашивать, чтобы декодирование начиналось с этого LSN, а не с позиции, выбираемой сервером. Для этого разработан механизм отслеживания репликации, о котором можно узнать подробнее в описании источников репликации.

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

Слот логической репликации ничего не знает о состоянии получателя(ей). Возможно даже иметь несколько различных потребителей одного слота в разные моменты времени; они просто будут получать изменения с момента, когда их перестал получать предыдущий потребитель. Но в любой определённый момент получать изменения может только один потребитель.

Логический слот репликации также можно создать на сервере горячего резерва. Чтобы запретить VACUUM удалять требуемые строки из системных каталогов, на резервном сервере необходимо установить параметр hot_standby_feedback. Несмотря на это, если какие-либо требуемые строки будут удалены, слот станет аннулирован. Настоятельно рекомендуется использовать физический слот между ведущим и резервным сервером. В противном случае hot_standby_feedback будет работать только пока соединение активно (например, перезапуск узла может разорвать соединение). Затем ведущий сервер может удалить строки системного каталога, которые могут потребоваться для логического декодирования на резервном сервере (поскольку ведущий сервер не знает о catalog_xmin на резервном сервере). Существующие логические слоты в режиме ожидания также становятся недействительными, если значение wal_level на основном сервере становится ниже logical. Это происходит, как только резервный сервер обнаруживает такое изменение в потоке WAL и означает, что для отстающих процессов walsender (если таковые имеются) некоторые записи WAL до изменения параметра wal_level на ведущем сервере не будут декодированы.

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

Слоты логической репликации на главном сервере можно синхронизировать с горячим резервом, если для создания слотов использовать функцию pg_create_logical_replication_slot с параметром failover или команду CREATE SUBSCRIPTION с параметром failover. Кроме того, на резервном сервере необходимо включить параметр sync_replication_slots. Если параметр sync_replication_slots на резервном сервере включён, слоты аварийного переключения будут периодически синхронизироваться рабочим процессом slotsync. Чтобы синхронизация проходила корректно, между главным и резервным сервером необходим слот физической репликации (для резервного сервера должен быть задан параметр primary_slot_name), а также на резервном сервере необходимо включить параметр hot_standby_feedback. Также необходимо указать действительное значение dbname в параметре primary_conninfo. Настоятельно рекомендуется внести слот физической репликации в список synchronized_standby_slots на главном сервере, чтобы подписчики не получали изменения раньше горячего резерва. Даже с правильной настройкой будет заметна некоторая задержка при отправке изменений подписчикам логической репликации из-за ожидания слотов, перечисленных в списке synchronized_standby_slots. При использовании списка synchronized_standby_slots главный сервер не отключится полностью, пока резервные серверы, связанные с перечисленными в этом списке слотами, не подтвердят получение последних обновлений WAL.

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

LOG:  could not synchronize replication slot "failover_slot" (не удалось синхронизировать слот репликации "failover_slot")
DETAIL:  Synchronization could lead to data loss, because the remote slot needs WAL at LSN 0/3003F28 and catalog xmin 754, but the standby has LSN 0/3003F28 and catalog xmin 756 (Синхронизация может привести к потере данных, поскольку удалённый слот запрашивает запись WAL от LSN 0/3003F28 и каталог xmin 754, но у резервного сервера уже есть запись WAL от LSN 0/3003F28 и каталог xmin 754).

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

Возможность возобновить процесс логической репликации после отказа зависит от значения pg_replication_slots.synced для слотов, синхронизированных на резервном сервере на момент отработки отказа. Для логической репликации после отказа могут использоваться только постоянные слоты, которые были синхронизированы на резервном сервере до отказа. Временные синхронизированные слоты для этого использовать нельзя, то есть возобновить логическую репликацию для таких слотов невозможно. Например, если синхронизированный слот не может стать постоянным на резервном из-за того, что подписка отключена, то подписка не будет возобновлена после отказа, даже если её включить.

Чтобы возобновить логическую репликацию из синхронизированных логических слотов после отработки отказа, необходимо в строке conninfo подписки указать главный сервер. Это можно сделать командой ALTER SUBSCRIPTION ... CONNECTION. Рекомендуется отключить подписки до повышения резерва и включить после изменения строки подключения.

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

Когда новый слот репликации создаётся через интерфейс потоковой репликации, экспортируется снимок (см. CREATE_REPLICATION_SLOT), который будет показывать ровно то состояние базы данных, изменения после которого будут включаться в поток изменений. Используя его, можно создать новую реплику, воспользовавшись командой SET TRANSACTION SNAPSHOT, чтобы получить состояние базы в момент создания слота. После этого данную транзакцию можно использовать для выгрузки состояния базы на момент экспорта снимка, а затем изменять это состояние, применяя содержимое слота, так что никакие изменения не будут потеряны.

Приложения, которым не требуется экспорт снимка, могут подавить его, воспользовавшись указанием SNAPSHOT 'nothing'.