FAQ по ClickPipes для Postgres

Как режим простоя (idling) влияет на мой Postgres CDC ClickPipe?

Если ваш сервис ClickHouse Cloud находится в режиме простоя, ваш Postgres CDC ClickPipe продолжит синхронизацию данных: сервис будет «просыпаться» на каждом интервале синхронизации для обработки входящих данных. Как только синхронизация завершится и снова будет достигнут порог простоя, ваш сервис вернётся в режим ожидания.

Например, если интервал синхронизации установлен на 30 минут, а время простоя сервиса — на 10 минут, ваш сервис будет «просыпаться» каждые 30 минут, работать 10 минут, а затем снова переходить в режим ожидания.

Как в ClickPipes для Postgres обрабатываются столбцы TOAST?

См. раздел Handling TOAST Columns для получения дополнительной информации.

Как в ClickPipes для Postgres обрабатываются вычисляемые столбцы (generated columns)?

См. раздел Postgres Generated Columns: Gotchas and Best Practices для получения дополнительной информации.

Должны ли таблицы иметь первичные ключи, чтобы участвовать в Postgres CDC?

Чтобы таблица могла реплицироваться с использованием ClickPipes для Postgres, в ней должен быть определён либо первичный ключ, либо REPLICA IDENTITY.

• Primary Key (первичный ключ): Самый простой подход — определить первичный ключ для таблицы. Он предоставляет уникальный идентификатор для каждой строки, что критично для отслеживания обновлений и удалений. В этом случае вы можете оставить REPLICA IDENTITY равным DEFAULT (поведение по умолчанию).

• Replica Identity: Если в таблице нет первичного ключа, вы можете настроить replica identity. Значение replica identity можно установить в FULL, что означает, что для идентификации изменений будет использоваться вся строка. Либо вы можете указать использовать уникальный индекс, если он существует в таблице, а затем установить REPLICA IDENTITY в USING INDEX index_name.

  Чтобы установить replica identity в FULL, вы можете использовать следующую SQL-команду:

ALTER TABLE your_table_name REPLICA IDENTITY FULL;

REPLICA IDENTITY FULL также позволяет реплицировать неизменённые TOAST‑столбцы. Подробнее об этом здесь.

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

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

Поддерживаются ли секционированные таблицы в рамках Postgres CDC?

Да, секционированные таблицы поддерживаются «из коробки», при условии, что для них определён PRIMARY KEY или REPLICA IDENTITY. PRIMARY KEY и REPLICA IDENTITY должны присутствовать как в родительской таблице, так и во всех её секциях. Подробнее об этом можно прочитать здесь.

Могу ли я подключить базы данных Postgres без публичного IP‑адреса или в частных сетях?

Да! ClickPipes для Postgres предлагает два способа подключения к базам данных в частных сетях:

1. SSH‑туннелирование

   • Хорошо подходит для большинства сценариев
   • Инструкции по настройке см. здесь
   • Работает во всех регионах

2. AWS PrivateLink

   • Доступен в трёх регионах AWS:
     • us-east-1
     • us-east-2
     • eu-central-1
   • Подробные инструкции по настройке см. в нашей документации по PrivateLink
   • В регионах, где PrivateLink недоступен, используйте SSH‑туннелирование

Как вы обрабатываете UPDATE и DELETE?

ClickPipes for Postgres регистрирует как INSERT, так и UPDATE из Postgres в виде новых строк с разными версиями (с использованием столбца версии _peerdb_) в ClickHouse. Движок таблиц ReplacingMergeTree периодически выполняет дедупликацию в фоновом режиме на основе ключа упорядочивания (столбцов ORDER BY), сохраняя только строку с последней версией _peerdb_.

DELETE из Postgres передаются как новые строки, помеченные как удалённые (с использованием столбца _peerdb_is_deleted). Поскольку процесс дедупликации асинхронный, вы можете временно видеть дубликаты. Чтобы избежать этого, необходимо обрабатывать дедупликацию на уровне запросов.

Также учтите, что по умолчанию Postgres не отправляет значения столбцов, не входящих в первичный ключ или replica identity, при операциях DELETE. Если вы хотите фиксировать полные данные строки при DELETE, вы можете установить REPLICA IDENTITY в значение FULL.

Для получения дополнительной информации см.:

• Рекомендации по использованию движка таблиц ReplacingMergeTree
• Блог о внутренних механизмах CDC для репликации Postgres в ClickHouse

Могу ли я обновлять столбцы первичного ключа в PostgreSQL?

Примечание

Обновления первичного ключа в PostgreSQL по умолчанию не могут быть корректно воспроизведены в ClickHouse.

Это ограничение существует, потому что дедупликация в ReplacingMergeTree работает на основе столбцов ORDER BY (которые, как правило, соответствуют первичному ключу). Когда первичный ключ обновляется в PostgreSQL, в ClickHouse это выглядит как новая строка с другим ключом, а не как обновление существующей строки. В результате в таблице ClickHouse могут одновременно присутствовать как старое, так и новое значения первичного ключа.

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

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

Если в вашем случае необходимо обновлять столбцы первичного ключа в PostgreSQL и корректно отражать эти изменения в ClickHouse, свяжитесь с нашей командой поддержки по адресу db-integrations-support@clickhouse.com, чтобы обсудить ваши конкретные требования и возможные решения.

Поддерживаются ли изменения схемы?

См. страницу ClickPipes for Postgres: поддержка распространения изменений схемы для получения дополнительной информации.

Какова стоимость ClickPipes for Postgres CDC?

Подробную информацию о ценах см. в разделе с ценами на ClickPipes for Postgres CDC на нашей основной странице обзора биллинга.

Размер моего replication slot растёт или не уменьшается; в чём может быть проблема?

Если вы замечаете, что размер replication slot в Postgres продолжает увеличиваться или не уменьшается, это обычно означает, что записи WAL (Write-Ahead Log) недостаточно быстро потребляются (или «воспроизводятся») вашим CDC-конвейером или процессом репликации. Ниже приведены наиболее распространённые причины и способы их устранения.

1. Резкие всплески активности базы данных

   • Крупные пакетные обновления, массовые вставки или значимые изменения схемы могут быстро сгенерировать большой объём данных WAL.
   • Репликационный слот будет удерживать эти записи WAL до тех пор, пока они не будут потреблены, что вызывает временный скачок размера.

2. Долго работающие транзакции

   • Открытая транзакция вынуждает Postgres сохранять все сегменты WAL, сгенерированные с момента начала транзакции, что может сильно увеличить размер слота.
   • Установите statement_timeout и idle_in_transaction_session_timeout в разумные значения, чтобы не допускать бесконечно долгих транзакций:

     SELECT
         pid,
         state,
         age(now(), xact_start) AS transaction_duration,
         query AS current_query
     FROM
         pg_stat_activity
     WHERE
         xact_start IS NOT NULL
     ORDER BY
         age(now(), xact_start) DESC;
     
     Используйте этот запрос, чтобы выявить необычно долго работающие транзакции.

3. Операции обслуживания или служебные операции (например, pg_repack)

   • Такие инструменты, как pg_repack, могут переписывать целые таблицы, создавая большие объёмы данных WAL за короткое время.
   • Планируйте эти операции в периоды низкой нагрузки или внимательно отслеживайте использование WAL во время их выполнения.

4. VACUUM и VACUUM ANALYZE

   • Хотя эти операции необходимы для поддержания работоспособности базы данных, они могут создавать дополнительный трафик WAL — особенно при сканировании больших таблиц.
   • Рассмотрите возможность настройки параметров autovacuum или планирования ручных операций VACUUM в непиковые часы.

5. Потребитель репликации не читает слот активно

   • Если ваш конвейер CDC (например, ClickPipes) или другой потребитель репликации останавливается, приостанавливается или аварийно завершается, данные WAL будут накапливаться в слоте.
   • Убедитесь, что ваш конвейер работает непрерывно, и проверьте логи на предмет ошибок подключения или аутентификации.

Для детального разбора этой темы ознакомьтесь с нашей публикацией в блоге: Overcoming Pitfalls of Postgres Logical Decoding.

Как сопоставляются типы данных Postgres с типами ClickHouse?

ClickPipes для Postgres стремится сопоставлять типы данных Postgres максимально нативно на стороне ClickHouse. В этом документе представлен исчерпывающий список каждого типа данных и его соответствия: Data Type Matrix.

Могу ли я задать собственное сопоставление типов данных при репликации данных из Postgres в ClickHouse?

В настоящий момент мы не поддерживаем задание пользовательских сопоставлений типов данных как части pipe. Однако обратите внимание, что сопоставление типов данных по умолчанию, используемое ClickPipes, является максимально нативным. Большинство типов столбцов в Postgres реплицируются максимально близко к их нативным эквивалентам в ClickHouse. Например, целочисленные массивы в Postgres реплицируются как целочисленные массивы в ClickHouse.

Как реплицируются столбцы JSON и JSONB из Postgres?

Столбцы JSON и JSONB реплицируются как тип String в ClickHouse. Поскольку ClickHouse поддерживает нативный тип JSON, вы можете создать материализованное представление поверх таблиц ClickPipes, чтобы при необходимости выполнить преобразование. В качестве альтернативы вы можете использовать JSON-функции напрямую над столбцами типа String. Мы активно работаем над функцией, которая будет реплицировать столбцы JSON и JSONB напрямую в тип JSON в ClickHouse. Ожидается, что эта возможность станет доступна в течение нескольких месяцев.

Что происходит с вставками, когда mirror приостановлен?

Когда вы приостанавливаете mirror, сообщения ставятся в очередь в replication slot на исходном Postgres, что гарантирует их буферизацию и отсутствие потерь. Однако приостановка и возобновление работы mirror приводит к повторному установлению подключения, что может занять некоторое время в зависимости от источника.

В ходе этого процесса обе операции — sync (чтение данных из Postgres и потоковая загрузка в raw-таблицу ClickHouse) и normalize (от raw-таблицы к целевой таблице) — прерываются. Однако они сохраняют состояние, необходимое для надёжного возобновления.

• Для sync, если он отменяется в середине выполнения, confirmed_flush_lsn в Postgres не продвигается, поэтому следующий sync начнётся с той же позиции, что и прерванный, обеспечивая согласованность данных.
• Для normalize порядок вставок в ReplacingMergeTree обрабатывает дедупликацию.

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

Можно ли автоматизировать создание ClickPipe или выполнять его через API или CLI?

Postgres ClickPipe также может быть создан и управляться через OpenAPI endpoints. Эта возможность находится в бета-версии, а ссылку на справочник по API можно найти здесь. Мы активно работаем над поддержкой Terraform для создания Postgres ClickPipes.

Как ускорить начальную загрузку?

Невозможно ускорить уже запущенную начальную загрузку. Однако вы можете оптимизировать будущие начальные загрузки, настроив определённые параметры. По умолчанию заданы 4 параллельных потока и снимок с числом строк на раздел, равным 100 000. Это расширенные настройки, и в большинстве случаев их достаточно.

Для версий Postgres 13 и ниже сканирование диапазонов CTID работает медленнее, и эти настройки становятся более критичными. В таких случаях рассмотрите следующий процесс повышения производительности:

1. Удалите существующий ClickPipe: Это необходимо для применения новых настроек.
2. Удалите целевые таблицы в ClickHouse: Убедитесь, что таблицы, созданные предыдущим ClickPipe, удалены.
3. Создайте новый ClickPipe с оптимизированными настройками: Обычно следует увеличить число строк в снимке на раздел до значения от 1 миллиона до 10 миллионов в зависимости от ваших требований и нагрузки, которую может выдержать ваш экземпляр Postgres.

Эти изменения должны существенно повысить производительность начальной загрузки, особенно для старых версий Postgres. Если вы используете Postgres 14 или новее, влияние этих настроек меньше благодаря улучшенной поддержке сканирования диапазонов CTID.

Как правильно задать область действия публикаций при настройке репликации?

Вы можете позволить ClickPipes управлять вашими публикациями (требуются дополнительные разрешения) или создать их самостоятельно. В случае публикаций, управляемых ClickPipes, мы автоматически обрабатываем добавление и удаление таблиц по мере редактирования ClickPipe. Если вы управляете ими самостоятельно, тщательно задайте область действия публикаций, включая только те таблицы, которые нужно реплицировать: добавление лишних таблиц замедлит декодирование WAL в Postgres.

Если вы включаете таблицу в публикацию, убедитесь, что у неё есть либо первичный ключ, либо REPLICA IDENTITY FULL. Если у вас есть таблицы без первичного ключа, создание публикации для всех таблиц приведёт к сбоям операций DELETE и UPDATE для этих таблиц.

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

SELECT table_schema, table_name
FROM information_schema.tables
WHERE
    (table_catalog, table_schema, table_name) NOT IN (
        SELECT table_catalog, table_schema, table_name
        FROM information_schema.table_constraints
        WHERE constraint_type = 'PRIMARY KEY') AND
    table_schema NOT IN ('information_schema', 'pg_catalog', 'pgq', 'londiste');

У вас есть два варианта работы с таблицами без первичных ключей:

1. Исключить таблицы без первичных ключей из ClickPipes: Создайте publication, включив в неё только таблицы с первичным ключом:

   CREATE PUBLICATION clickpipes_publication FOR TABLE table_with_primary_key1, table_with_primary_key2, ...;
   

2. Включить таблицы без первичных ключей в ClickPipes: Если вы хотите включить таблицы без первичного ключа, нужно изменить их replica identity на значение FULL. Это гарантирует корректную работу операций UPDATE и DELETE:

   ALTER TABLE table_without_primary_key1 REPLICA IDENTITY FULL;
   ALTER TABLE table_without_primary_key2 REPLICA IDENTITY FULL;
   CREATE PUBLICATION clickpipes_publication FOR TABLE <...>, <...>;
   

Совет

Если вы создаёте publication вручную вместо того, чтобы позволить ClickPipes управлять ей, мы не рекомендуем создавать publication FOR ALL TABLES, так как это приводит к большему объёму трафика из Postgres в ClickPipes (к отправке изменений для других таблиц, не входящих в pipe) и снижает общую эффективность.

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

Примечание

Если вы реплицируете данные из реплики только для чтения / hot standby-сервера Postgres, вам нужно создать собственную publication на первичном экземпляре, которая будет автоматически распространяться на standby. В этом случае ClickPipe не сможет управлять publication, так как на standby невозможно создавать publications.

Рекомендуемые настройки max_slot_wal_keep_size

• Минимум: Установите max_slot_wal_keep_size так, чтобы сохранялся объём WAL-данных как минимум за двое суток.
• Для крупных баз данных (с высоким объёмом транзакций): Храните как минимум 2–3-кратный объём максимальной суточной генерации WAL.
• Для сред с ограниченным хранилищем: Настраивайте этот параметр консервативно, чтобы избежать исчерпания дискового пространства, при этом сохраняя стабильность репликации.

Как вычислить корректное значение

Чтобы определить подходящую настройку, измерьте скорость генерации WAL:

Для PostgreSQL 10+

SELECT pg_wal_lsn_diff(pg_current_wal_insert_lsn(), '0/0') / 1024 / 1024 AS wal_generated_mb;

Для PostgreSQL 9.6 и более ранних версий:

SELECT pg_xlog_location_diff(pg_current_xlog_insert_location(), '0/0') / 1024 / 1024 AS wal_generated_mb;

• Запустите приведённый выше запрос в разное время суток, особенно в периоды высокой транзакционной активности.
• Рассчитайте, какой объём WAL генерируется за сутки.
• Умножьте это число на 2 или 3, чтобы обеспечить достаточный срок хранения.
• Установите max_slot_wal_keep_size равным полученному значению в МБ или ГБ.

Пример

Если ваша база данных генерирует 100 ГБ WAL в день, установите:

max_slot_wal_keep_size = 200GB

В логах появляется ошибка ReceiveMessage EOF. Что она означает?

ReceiveMessage — это функция в протоколе логического декодирования Postgres, которая читает сообщения из потока репликации. Ошибка EOF (End of File) указывает на то, что соединение с сервером Postgres было неожиданно закрыто во время попытки чтения из потока репликации.

Это восстанавливаемая ошибка, она не является фатальной. ClickPipes автоматически попытается переподключиться и возобновить процесс репликации.

Это может происходить по нескольким причинам:

• Низкий wal_sender_timeout: Убедитесь, что wal_sender_timeout установлен на 5 минут или выше. Этот параметр определяет, как долго сервер ждёт ответа от клиента, прежде чем закрыть соединение. Если таймаут слишком мал, это может привести к преждевременным разрывам соединения.
• Проблемы с сетью: Временные сетевые сбои могут вызвать обрыв соединения.
• Перезапуск сервера Postgres: Если сервер Postgres перезапущен или упал, соединение будет потеряно.

Мой слот репликации был признан недействительным. Что делать?

Единственный способ восстановить ClickPipe — запустить повторную синхронизацию, что можно сделать на странице Settings.

Наиболее распространённая причина аннулирования слота репликации — слишком низкое значение max_slot_wal_keep_size в вашей базе данных PostgreSQL (например, несколько гигабайт). Мы рекомендуем увеличить это значение. Обратитесь к этому разделу по настройке max_slot_wal_keep_size. В идеале оно должно быть установлено как минимум на 200GB, чтобы предотвратить аннулирование слота репликации.

В редких случаях мы наблюдали эту проблему даже при отсутствии настройки max_slot_wal_keep_size. Это может быть связано с тонкой и редкой ошибкой в PostgreSQL, хотя причина остаётся неясной.

Я вижу out of memory (OOM) на ClickHouse во время приёма данных моим ClickPipe. Можете помочь?

Одна из распространённых причин OOM на ClickHouse — недостаточный размер сервиса. Это означает, что текущая конфигурация сервиса не располагает достаточными ресурсами (например, памятью или CPU) для эффективной обработки нагрузки на ингестию. Мы настоятельно рекомендуем масштабировать сервис, чтобы соответствовать требованиям по ингестии данных вашего ClickPipe.

Другая причина, которую мы наблюдали, — наличие зависимых материализованных представлений (Materialized Views) с потенциально неоптимальными соединениями (JOIN):

• Распространённый приём оптимизации JOIN заключается в следующем: если у вас есть LEFT JOIN, где правая таблица очень большая, перепишите запрос, используя RIGHT JOIN, и перенесите большую таблицу в левую часть. Это позволяет оптимизатору запросов эффективнее использовать память.

• Другая оптимизация для JOIN — явно отфильтровать таблицы через subqueries или CTEs, а затем выполнять JOIN поверх этих подзапросов. Это даёт оптимизатору подсказки о том, как эффективно фильтровать строки и выполнять JOIN.

Во время начальной загрузки я вижу invalid snapshot identifier. Что делать?

Ошибка invalid snapshot identifier возникает, когда происходит обрыв соединения между ClickPipes и вашей базой данных Postgres. Это может случиться из-за таймаутов на шлюзе, перезапусков базы данных или других временных сбоёв.

Рекомендуется не выполнять никаких разрушительных операций, таких как обновления или перезапуски базы данных Postgres, пока выполняется начальная загрузка (Initial Load), а также обеспечить стабильность сетевого соединения с вашей базой данных.

Чтобы решить эту проблему, вы можете запустить повторную синхронизацию (Resync) из интерфейса ClickPipes. Это перезапустит процесс первоначальной загрузки с самого начала.

Что произойдет, если я удалю publication в Postgres?

Удаление publication в Postgres нарушит подключение вашего ClickPipe, поскольку publication требуется для того, чтобы ClickPipe мог забирать изменения из источника. В этом случае вы, как правило, получите уведомление об ошибке, указывающее, что publication больше не существует.

Чтобы восстановить ClickPipe после удаления publication:

1. Создайте новый publication с тем же именем и необходимыми таблицами в Postgres.
2. Нажмите кнопку «Resync tables» на вкладке Settings вашего ClickPipe.

Эта повторная синхронизация необходима, поскольку заново созданный publication будет иметь другой идентификатор объекта (OID) в Postgres, даже если у него то же имя. Процесс повторной синхронизации обновляет таблицы в целевом хранилище и восстанавливает подключение.

При желании вы можете вместо этого создать полностью новый ClickPipe.

Обратите внимание, что если вы работаете с секционированными таблицами, убедитесь, что создаете publication с соответствующими настройками:

CREATE PUBLICATION clickpipes_publication
FOR TABLE <...>, <...>
WITH (publish_via_partition_root = true);

Что делать, если я вижу ошибки Unexpected Datatype или Cannot parse type XX ...

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

Я вижу ошибки вида invalid memory alloc request size <XXX> во время репликации/создания слота

В патч-версиях Postgres 17.5/16.9/15.13/14.18/13.21 была допущена ошибка, из-за которой определённые рабочие нагрузки могут вызывать экспоненциальный рост использования памяти, приводящий к запросу на выделение памяти > 1GB, который Postgres считает недопустимым. Эта ошибка была исправлена и войдёт в следующую серию патчей Postgres (17.6...). Пожалуйста, уточните у вашего провайдера Postgres, когда эта патч-версия будет доступна для обновления. Если обновление невозможно в ближайшее время, потребуется повторная синхронизация ClickPipe после возникновения ошибки.

Мне нужно сохранять полную историю данных в ClickHouse, даже когда данные удаляются из исходной базы Postgres. Могу ли я полностью игнорировать операции DELETE и TRUNCATE из Postgres в ClickPipes?

Да! Перед созданием вашего Postgres ClickPipe создайте publication без операций DELETE. Например:

CREATE PUBLICATION <имя_публикации> FOR TABLES IN SCHEMA <имя_схемы> WITH (publish = 'insert,update');

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

Обратите внимание, что операции TRUNCATE игнорируются ClickPipes и не будут реплицированы в ClickHouse.

Почему я не могу реплицировать таблицу, в имени которой есть точка?

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

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

Если первоначальная загрузка завершилась без ошибок, но в целевой таблице ClickHouse отсутствуют данные, возможно, у вас включены политики RLS (Row Level Security, построчная безопасность) на исходных таблицах Postgres. Также стоит проверить:

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

Могу ли я настроить ClickPipe так, чтобы он создавал слот репликации с включённым фейловером?

Да, для Postgres ClickPipe с режимом репликации CDC или Snapshot + CDC вы можете настроить ClickPipes на создание слота репликации с включённым фейловером, переключив тумблер, показанный ниже, в разделе Advanced Settings при создании ClickPipe. Обратите внимание, что версия вашего Postgres должна быть 17 или выше, чтобы использовать эту функцию.

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

Я вижу ошибки вида Internal error encountered during logical decoding of aborted sub-transaction

Эта ошибка указывает на временную проблему при логическом декодировании прерванной подтранзакции и специфична для нестандартных реализаций Aurora Postgres. Поскольку ошибка возникает в процедуре ReorderBufferPreserveLastSpilledSnapshot, это говорит о том, что логическое декодирование не может прочитать снимок, выгруженный на диск. Имеет смысл попробовать увеличить значение параметра logical_decoding_work_mem.

Я вижу ошибки вида error converting new tuple to map или error parsing logical message во время CDC-репликации

Postgres отправляет информацию об изменениях в виде сообщений со строго определённым протоколом. Эти ошибки возникают, когда ClickPipe получает сообщение, которое не удаётся разобрать — либо из‑за повреждения при передаче, либо из‑за отправки некорректных сообщений. Хотя конкретная причина может быть разной, мы наблюдали несколько таких случаев для источников Neon Postgres. Если вы также видите эту проблему с Neon, создайте запрос в их службу поддержки. В остальных случаях свяжитесь с нашей службой поддержки для получения рекомендаций.