Ограничения

примечание

Эта страница переведена при помощи нейросети GigaChat.

В настоящее время логическая репликация имеет следующие ограничения или отсутствующую функциональность. Эти вопросы могут быть решены в будущих выпусках.

База данных и команды DDL не реплицируются. Начальная схема может быть скопирована вручную с использованием pg_dump --schema-only. Последующие изменения схемы должны будут поддерживаться вручную (однако нет необходимости, чтобы схемы были абсолютно одинаковыми на обеих сторонах). Логическая репликация устойчива при изменении определений схемы в рабочей базе данных: когда схема изменяется на издателя и реплицированные данные начинают поступать к подписчику, но не соответствуют схеме таблицы, репликация будет выдавать ошибку до тех пор, пока схема не будет обновлена. Во многих случаях можно избежать периодических ошибок, применив дополнительные изменения схемы к подписчику первым.
Последовательные данные не реплицируются. Данные в последовательных или идентифицирующих столбцах, поддерживаемых последовательностями, будут реплицированы как часть таблицы, но сама последовательность все равно будет показывать начальное значение на подписчике. Если подписчик используется в качестве базы данных только для чтения, то обычно это не должно быть проблемой. Однако если предполагается какой-то вид переключения или отказа на базу данных подписчика, то последовательности должны быть обновлены до последних значений либо путем копирования текущих данных с издателя (возможно, с использованием pg_dump), либо путем определения достаточно высокого значения из самих таблиц.
Поддерживается репликация команд TRUNCATE, но следует соблюдать осторожность при усечении групп таблиц, связанных внешними ключами. При репликации действия усечения подписчик будет усекать ту же группу таблиц, которая была усечена на издателе, либо явно указанную, либо неявно собранную через CASCADE, за исключением таблиц, которые не являются частью подписки. Это будет работать правильно, если все затронутые таблицы входят в одну и ту же подписку. Но если некоторые таблицы, которые должны быть усечены на подписчике, имеют внешние ключи к таблицам, которые не входят в ту же самую (или любую) подписку, то применение действия усечения на подписчике завершится сбоем.
Большие объекты (см. раздел «Большие объекты») не реплицируются. Для этого нет обходного пути, кроме хранения данных в обычных таблицах.
При репликации между партиционированными таблицами фактическое происхождение репликации происходит, по умолчанию, от листовых партиций на издателях, поэтому партиции на издателях также должны существовать на подписчиках в качестве допустимых целевых таблиц. (Они могут быть сами листовыми партициями, или они могут быть дополнительно разделены на подпартиции, или даже быть независимыми таблицами.) Публикации также могут указывать, что изменения должны реплицироваться с использованием идентификатора и схемы корневой партиционированной таблицы вместо идентификаторов отдельных листовых партиций, где фактически происходят изменения (см. параметр publish_via_partition_root команды CREATE PUBLICATION).
Если использовать REPLICA IDENTITY FULL на публикуемых таблицах, важно отметить, что операции UPDATE и DELETE нельзя применять к подписчикам, если таблицы содержат атрибуты с типами данных (например, точка или прямоугольник), у которых нет класса операторов по умолчанию для B-tree или хеша. Тем не менее, эту проблему можно обойти, убедившись, что таблица имеет первичный ключ или идентификатор реплики, определенный для нее.