CREATE SUBSCRIPTION

CREATE SUBSCRIPTION

CREATE SUBSCRIPTION
Назад	Наверх	SQL Команды	Начало	Далее

CREATE SUBSCRIPTION — определить новую подписку

Синтаксис

CREATE SUBSCRIPTION subscription_name
    CONNECTION 'conninfo'
    PUBLICATION publication_name [, ...]
    [ WITH ( subscription_parameter [= value] [, ... ] ) ]

Описание

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

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

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

Чтобы иметь возможность создать подписку, вы должны обладать привилегиями роли pg_create_subscription, а также привилегиями CREATE в текущей базе данных.

Дополнительная информация о подписках и логической репликации в целом доступна по ссылкам Раздел 29.2 и Глава 29.

Параметры

subscription_name #

Имя новой подписки.

CONNECTION 'conninfo' #

Строка подключения libpq, определяющая, как подключиться к базе данных издателя. Подробности см. в разделе Раздел 31.1.1.

PUBLICATION publication_name [, ...] #

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

WITH ( subscription_parameter [= value] [, ... ] ) #

Это предложение определяет необязательные параметры для подписки.

Следующие параметры управляют тем, что происходит при создании подписки:

connect (boolean) #

Определяет, должна ли команда CREATE SUBSCRIPTION вообще подключаться к издателю. По умолчанию значение равно true. Если установить значение false, то значения create_slot, enabled и copy_data будут принудительно установлены в false. (Нельзя установить значение connect в false и одновременно установить значения create_slot, enabled или copy_data в true).

Поскольку соединение не устанавливается, когда этот параметр false, таблицы не подписываются. Чтобы инициировать репликацию, необходимо вручную создать слот репликации, включить подписку и обновить подписку. См. Раздел 29.2.3 для примеров.

create_slot (boolean) #

Указывает, должна ли команда создать слот репликации на издателе. По умолчанию true.

Если установлено значение false, вы несете ответственность за создание слота издателя другим способом. См. Раздел 29.2.3 для примеров.

enabled (boolean) #

Определяет, должна ли подписка активно тиражировать или просто быть настроенной, но пока не запущенной. По умолчанию true.

slot_name (string) #

Имя слота репликации издателя, которое будет использоваться. По умолчанию используется имя подписки в качестве имени слота.

Установка slot_name в NONE означает, что с подпиской не будет связано ни одного слота репликации. Такие подписки также должны иметь оба параметра enabled и create_slot установлены в false. Используйте это, когда вы будете создавать слот репликации вручную позже. См. Раздел 29.2.3 для примеров.

Следующие параметры управляют поведением репликации подписки после ее создания:

binary (boolean) #

Указывает, будет ли подписка запрашивать у издателя отправку данных в бинарном формате (в отличие от текстового). По умолчанию значение false. Любое начальное копирование синхронизации таблицы (см. copy_data) также использует тот же формат. Бинарный формат может быть быстрее текстового, но он менее портативен между архитектурами машин и версиями Tantor BE. Бинарный формат очень специфичен для типа данных; например, он не позволит копировать из столбца smallint в столбец integer, хотя это прекрасно работает в текстовом формате. Даже когда эта опция включена, только те типы данных, которые имеют функции отправки и получения в бинарном формате, будут передаваться в бинарном формате. Обратите внимание, что начальная синхронизация требует, чтобы все типы данных имели функции отправки и получения в бинарном формате, иначе синхронизация завершится неудачей (см. CREATE TYPE для получения дополнительной информации о функциях отправки/получения).

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

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

copy_data (boolean) #

Определяет, нужно ли копировать существующие данные в публикациях, на которые подписываются при запуске репликации. По умолчанию true.

Если публикации содержат предложения WHERE, это повлияет на то, какие данные будут скопированы. См. Notes для получения подробной информации.

См. Notes для подробностей о том, как copy_data = true может взаимодействовать с параметром origin.

streaming (enum) #

Указывает, следует ли включать потоковую передачу незавершенных транзакций для этой подписки. Значение по умолчанию — off, что означает, что все транзакции полностью декодируются на издателе и только затем отправляются подписчику целиком.

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

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

synchronous_commit (enum) #

Значение этого параметра переопределяет настройку synchronous_commit в рамках процессов рабочего процесса применения этой подписки. Значение по умолчанию - off.

Безопасно использовать off для логической репликации: Если подписчик потеряет транзакции из-за отсутствия синхронизации, данные будут отправлены снова от издателя.

Синхронная логическая репликация может потребовать других настроек. Рабочие процессы логической репликации сообщают издателю позиции записей и сбросы, и при использовании синхронной репликации издатель будет ожидать фактического сброса. Это означает, что установка параметра synchronous_commit для подписчика в значение off при использовании подписки для синхронной репликации может увеличить задержку для команды COMMIT на издателе. В этом сценарии может быть выгодно установить параметр synchronous_commit в значение local или выше.

two_phase (boolean) #

Определяет, включен ли двухфазный коммит для этой подписки. По умолчанию false.

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

Реализация двухфазного коммита требует успешного завершения фазы синхронизации исходной таблицы репликации. Таким образом, даже когда two_phase включен для подписки, внутреннее состояние двухфазного коммита остается временно “ожидающим”, пока не завершится фаза инициализации. Смотрите столбец subtwophasestate в pg_subscription, чтобы узнать фактическое состояние двухфазного коммита.

disable_on_error (boolean) #

Определяет, должна ли подписка автоматически отключаться, если подписочные процессы обнаруживают ошибки при репликации данных с издателя. По умолчанию значение равно false.

password_required (boolean) #

Если установлено значение true, подключения к издателю, выполненные в результате этой подписки, должны использовать аутентификацию по паролю, и пароль должен быть указан как часть строки подключения. Этот параметр игнорируется, если подписка принадлежит суперпользователю. Значение по умолчанию — true. Только суперпользователи могут установить это значение в false.

run_as_owner (boolean) #

Если true, все действия репликации выполняются от имени владельца подписки. Если false, рабочие репликации будут выполнять действия на каждой таблице от имени владельца этой таблицы. Последняя конфигурация, как правило, гораздо более безопасна; для получения подробной информации см. Раздел 29.9. По умолчанию значение false.

origin (string) #

Определяет, будет ли подписка запрашивать у издателя только изменения без указания их происхождения или отправлять изменения независимо от их происхождения. Установка значения origin в none означает, что подписка будет запрашивать у издателя только отправку изменений без указания их происхождения. Установка значения origin в any означает, что издатель отправляет изменения независимо от их происхождения. По умолчанию используется значение any.

См. Notes для подробностей о том, как copy_data = true может взаимодействовать с параметром origin.

При указании параметра типа boolean, часть = value может быть опущена, что эквивалентно указанию TRUE.

Примечания

См. Раздел 29.9 для получения подробной информации о настройке контроля доступа между подпиской и экземпляром публикации.

При создании слота репликации (поведение по умолчанию) команда CREATE SUBSCRIPTION не может быть выполнена внутри блока транзакции.

Создание подписки, которая подключается к тому же кластеру базы данных (например, для репликации между базами данных в одном кластере или для репликации в пределах одной базы данных), будет успешным только в том случае, если слот репликации не создается как часть той же команды. В противном случае вызов CREATE SUBSCRIPTION зависнет. Чтобы это работало, создайте слот репликации отдельно (используя функцию pg_create_logical_replication_slot с именем плагина pgoutput) и создайте подписку, используя параметр create_slot = false. См. Раздел 29.2.3 для примеров. Это ограничение реализации, которое может быть снято в будущих выпусках.

Если в какой-либо таблице публикации есть предложение WHERE, строки, для которых expression оценивается как ложное или null, не будут опубликованы. Если подписка имеет несколько публикаций, в которых одна и та же таблица опубликована с разными предложениями WHERE, строка будет опубликована, если любое из выражений (относящихся к этой операции публикации) удовлетворено. В случае различных предложений WHERE, если одна из публикаций не имеет предложения WHERE (относящихся к этой операции публикации) или публикация объявлена как FOR ALL TABLES или FOR TABLES IN SCHEMA, строки всегда публикуются независимо от определения других выражений. Если подписчик использует версию Tantor BE до 15, то любое фильтрование строк игнорируется во время начальной фазы синхронизации данных. В этом случае пользователь может рассмотреть возможность удаления любых изначально скопированных данных, которые будут несовместимы с последующим фильтрованием. Поскольку начальная синхронизация данных не учитывает параметр публикации publish при копировании существующих данных таблицы, некоторые строки могут быть скопированы, которые не будут реплицироваться с использованием DML. См. Раздел 29.2.2 для примеров.

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

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

При использовании комбинации параметров подписки copy_data = true и origin = NONE, исходные данные таблицы копируются непосредственно с издателя, что означает, что знание истинного происхождения этих данных невозможно. Если у издателя также есть подписки, то скопированные данные таблицы могут происходить из более верхнего уровня. Этот сценарий обнаруживается, и пользователю выводится ПРЕДУПРЕЖДЕНИЕ, но предупреждение является лишь указанием на потенциальную проблему; ответственность за проведение необходимых проверок для обеспечения того, что происхождение скопированных данных действительно соответствует желаемому, лежит на пользователе.

Чтобы найти таблицы, которые могут потенциально включать нелокальные источники (из-за других подписок, созданных на издателе), попробуйте этот SQL-запрос:

# substitute <pub-names> below with your publication name(s) to be queried
SELECT DISTINCT PT.schemaname, PT.tablename
FROM pg_publication_tables PT,
     pg_subscription_rel PS
     JOIN pg_class C ON (C.oid = PS.srrelid)
     JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE N.nspname = PT.schemaname AND
      C.relname = PT.tablename AND
      PT.pubname IN (<pub-names>);

Примеры

Создать подписку на удаленный сервер, который реплицирует таблицы в публикациях mypublication и insert_only и начинает тиражировать немедленно после коммита:

CREATE SUBSCRIPTION mysub
         CONNECTION 'host=192.168.1.50 port=5432 user=foo dbname=foodb'
        PUBLICATION mypublication, insert_only;

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

CREATE SUBSCRIPTION mysub
         CONNECTION 'host=192.168.1.50 port=5432 user=foo dbname=foodb'
        PUBLICATION insert_only
               WITH (enabled = false);

Совместимость

CREATE SUBSCRIPTION - это расширение Tantor BE.

См. также

ALTER SUBSCRIPTION, DROP SUBSCRIPTION, CREATE PUBLICATION, ALTER PUBLICATION

Назад	Наверх	Далее
CREATE STATISTICS	Начало	CREATE TABLE

CREATE SUBSCRIPTION

CREATE SUBSCRIPTION#