FAQ по ClickPipes для Postgres

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

​

Реплицируются ли в ClickHouse откаты транзакций?

Нет. CDC реплицирует только подтверждённые транзакции. Откаченные транзакции в ClickHouse не отправляются.

​

Могу ли я хранить данные в ClickHouse дольше, чем в исходном Postgres?

Да. Для исходного Postgres и ClickHouse как пункта назначения сроки хранения настраиваются независимо. Например, в Postgres можно хранить данные только за 3 месяца, а в ClickHouse — сохранять всю историю. Удаление старых строк в Postgres создает события DELETE, которые реплицируются в ClickHouse, поэтому, если вы хотите сохранить исторические данные, вам следует либо исключить DELETE из публикации, либо обрабатывать их на уровне запроса.

​

Как обогащать данные при их передаче из Postgres в ClickHouse?

Используйте materialized views поверх таблиц назначения CDC. Materialized views в ClickHouse работают как триггеры на вставку, поэтому каждую строку, реплицируемую из Postgres, можно преобразовать, объединить через JOIN с lookup-таблицами или обогатить дополнительными столбцами перед записью в конечную целевую таблицу.

​

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

Да. Вы можете создать отдельные ClickPipes из разных экземпляров Postgres (в том числе из разных регионов AWS) в один или несколько сервисов ClickHouse. Например, можно отправлять данные из регионального Postgres в локальный кластер ClickHouse для низколатентной аналитики, а также одновременно в централизованный кластер ClickHouse в другом регионе для сводной отчетности. Имейте в виду, что межрегиональные конфигурации влекут за собой расходы AWS на передачу данных между регионами и дополнительную сетевую задержку.

​

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

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

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

​

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

Подробнее см. на странице Обработка столбцов TOAST.

​

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

Подробнее см. на странице Вычисляемые столбцы в Postgres: подводные камни и рекомендации.

​

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

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

• Первичный ключ: Самый простой вариант — задать для таблицы первичный ключ. Он обеспечивает уникальный идентификатор для каждой строки, что крайне важно для отслеживания обновлений и удалений. В этом случае для 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 для Postgres фиксирует и INSERT, и UPDATE из Postgres как новые строки с разными версиями в ClickHouse (с использованием столбца версий _peerdb_). Движок таблицы 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, поскольку первичные ключи предполагаются неизменяемыми идентификаторами. Большинство приложений изначально строятся так, чтобы избегать обновлений первичного ключа, поэтому в типичных сценариях это ограничение встречается редко.

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

Если в вашем сценарии необходимо обновлять столбцы первичного ключа в PostgreSQL и корректно отражать эти изменения в ClickHouse, свяжитесь с нашей службой поддержки по адресу [e-mail], чтобы обсудить ваши требования и возможные решения.

​

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

Дополнительные сведения см. на странице ClickPipes для Postgres: поддержка распространения изменений схемы.

​

Сколько стоит ClickPipes для Postgres CDC?

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

​

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

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

​

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

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

​

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

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

​

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

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

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

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

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

​

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

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

​

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

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

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

​

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

Вы можете поручить ClickPipes управление публикациями (для этого потребуются дополнительные разрешения) или создать их самостоятельно. Если публикациями управляет ClickPipes, мы автоматически добавляем и удаляем таблицы по мере редактирования пайпа. Если вы управляете ими самостоятельно, внимательно определяйте состав публикаций, чтобы включать только те таблицы, которые нужно реплицировать, — лишние таблицы замедляют декодирование 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: Создайте публикацию только для таблиц, у которых есть первичный ключ:

   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, вам потребуется создать собственную публикацию на основном экземпляре, и она автоматически распространится на 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 генерируется за 24 часа.
• Умножьте это число на 2 или 3, чтобы обеспечить достаточный запас хранения.
• Установите для max_slot_wal_keep_size полученное значение в МБ или ГБ.

Пример

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

max_slot_wal_keep_size = 200GB

​

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

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

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

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

• Проблемы с сетью: Временные сбои в сети могут привести к разрыву соединения.
• Перезапуск сервера Postgres: Если сервер Postgres перезапускается или аварийно завершает работу, соединение будет потеряно.

​

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

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

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

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

​

В ClickHouse возникают ошибки нехватки памяти (OOM) во время ингестии данных через мой 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, пока идет начальная загрузка, а также убедиться, что сетевое соединение с базой данных стабильно.

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

​

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

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

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

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

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

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

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

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> во время репликации/создания slot

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

​

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

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

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

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

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

​

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

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

​

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

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

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

​

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

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

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

​

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

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

​

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

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

​

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

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

​

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

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

​

Параллельное создание снимка: получение партиций может занять время

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

​

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

На вкладке 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;

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