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

В Tantor SE-1C логическое декодирование реализуется путем декодирования содержимого журнала предварительной записи, который описывает изменения на уровне хранения, в прикладной форме, такую как поток кортежей или SQL-запросов.

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

Репликационный слот имеет идентификатор, который является уникальным во всех базах данных в кластере Tantor SE-1C. Слоты сохраняются независимо от соединения, использующего их, и являются надежными при сбоях.

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

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

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

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

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

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

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

Создание снимка не всегда возможно. В частности, оно не выполнится при подключении к горячему резервному экземпляру. Приложения, которым не требуется экспорт снимка, могут подавить его с помощью опции NOEXPORT_SNAPSHOT.