Часто задаваемые вопросы о ClickPipes для Postgres

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

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

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

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

Дополнительные сведения см. в разделе Обработка столбцов TOAST.

Как обрабатываются генерируемые столбцы в ClickPipes для Postgres?

За дополнительной информацией обратитесь к странице Postgres Generated Columns: Gotchas and Best Practices.

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

Чтобы таблица могла реплицироваться с помощью ClickPipes for 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 for 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 для Postgres CDC?

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

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

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

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

   • Крупные пакетные обновления, массовые вставки или значимые изменения схемы могут очень быстро сгенерировать большой объем данных WAL.
   • Replication slot будет удерживать эти записи 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 будут накапливаться в слоте.
   • Убедитесь, что ваш конвейер работает непрерывно, и проверьте логи на наличие ошибок соединения или аутентификации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для Postgres версии 13 и ниже диапазонное сканирование по CTID выполняется очень медленно, поэтому ClickPipes их не использует. Вместо этого мы читаем всю таблицу как одну партицию, фактически выполняя загрузку в одном потоке (таким образом, игнорируя и число строк на партицию, и настройки количества параллельных потоков). Чтобы ускорить начальную загрузку в этом случае, вы можете увеличить параметр snapshot number of tables in parallel или задать пользовательский индексированный столбец партиционирования для больших таблиц.

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

Вы можете позволить ClickPipes управлять вашими публикациями (для этого требуются дополнительные привилегии) или создавать их самостоятельно. В случае публикаций, управляемых ClickPipes, мы автоматически обрабатываем добавление и удаление таблиц по мере редактирования pipe. При самостоятельном управлении тщательно задавайте область действия публикаций так, чтобы включать только те таблицы, которые нужно реплицировать, — включение лишних таблиц замедлит декодирование WAL в PostgreSQL.

Если вы включаете какую-либо таблицу в публикацию, убедитесь, что у неё есть либо первичный ключ, либо 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: Создайте публикацию только с таблицами, у которых есть первичный ключ:

   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 <...>, <...>;
   

Совет

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

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

Примечание

Если вы реплицируете данные из реплики только для чтения (read replica) / hot standby Postgres, вам потребуется создать собственную публикацию на основном (primary) инстансе, которая автоматически распространится на standby. В этом случае ClickPipe не сможет управлять публикацией, так как на standby невозможно создавать публикации.

Рекомендуемые настройки 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 — запустить повторную синхронизацию (resync), что можно сделать на странице Settings.

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

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

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

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

Другая наблюдаемая нами причина — наличие downstream materialized view с потенциально неоптимизированными JOIN:

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

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

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

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

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

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

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

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

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

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

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

При желании вы можете создать совершенно новый pipe.

Обратите внимание, что если вы работаете с партиционированными таблицами, обязательно создавайте 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, когда эта патч-версия будет доступна для обновления. Если обновление невозможно выполнить немедленно, потребуется повторная синхронизация pipe после возникновения этой ошибки.

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

Да! Перед созданием Postgres ClickPipe создайте публикацию без операций DELETE. Например:

CREATE PUBLICATION <pub_name> FOR TABLES IN SCHEMA <schema_name> WITH (publish = 'insert,update');

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я заметил, что мой ClickPipe перешёл в состояние Snapshot, но данные не поступают. В чём может быть проблема?

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

Параллельное создание snapshot занимает много времени из‑за получения партиций

Параллельное создание snapshot выполняет несколько начальных шагов, чтобы получить логические партиции для ваших таблиц. Если ваши таблицы небольшие, этот процесс завершится за несколько секунд, однако для очень больших таблиц (порядка терабайт) он может занять больше времени. Вы можете отслеживать запросы, выполняемые на исходной базе Postgres, на вкладке Source, чтобы проверить, есть ли длительно выполняющиеся запросы, связанные с получением партиций для snapshot. После того как партиции будут получены, данные начнут поступать.

Создание слота репликации заблокировано транзакцией

На вкладке Source в разделе Activity вы увидите, что запрос CREATE_REPLICATION_SLOT находится в состоянии Lock. Это может происходить из‑за другой транзакции, удерживающей блокировки на объектах, которые Postgres использует при создании слотов репликации. Чтобы увидеть блокирующие запросы, вы можете выполнить следующий запрос на исходном сервере Postgres:

SELECT
  blocked.pid AS blocked_pid,
  blocked.query AS blocked_query,
  blocking.pid AS blocking_pid,
  blocking.query AS blocking_query,
  blocking.state AS blocking_state
FROM pg_locks blocked_lock
JOIN pg_stat_activity blocked
  ON blocked_lock.pid = blocked.pid
JOIN pg_locks blocking_lock
  ON blocking_lock.locktype = blocked_lock.locktype
  AND blocking_lock.database IS NOT DISTINCT FROM blocked_lock.database
  AND blocking_lock.relation IS NOT DISTINCT FROM blocked_lock.relation
  AND blocking_lock.page IS NOT DISTINCT FROM blocked_lock.page
  AND blocking_lock.tuple IS NOT DISTINCT FROM blocked_lock.tuple
  AND blocking_lock.virtualxid IS NOT DISTINCT FROM blocked_lock.virtualxid
  AND blocking_lock.transactionid IS NOT DISTINCT FROM blocked_lock.transactionid
  AND blocking_lock.classid IS NOT DISTINCT FROM blocked_lock.classid
  AND blocking_lock.objid IS NOT DISTINCT FROM blocked_lock.objid
  AND blocking_lock.objsubid IS NOT DISTINCT FROM blocked_lock.objsubid
  AND blocking_lock.pid != blocked_lock.pid
JOIN pg_stat_activity blocking
  ON blocking_lock.pid = blocking.pid
WHERE NOT blocked_lock.granted;

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