Реплицируются ли в ClickHouse откаты транзакций?
Могу ли я хранить данные в ClickHouse дольше, чем в исходном Postgres?
Как обогащать данные при их передаче из Postgres в ClickHouse?
Можно ли реплицировать данные из нескольких экземпляров Postgres в один или несколько сервисов ClickHouse?
Как режим бездействия влияет на мой Postgres CDC ClickPipe?
Как в ClickPipes для Postgres обрабатываются столбцы TOAST?
Как в ClickPipes для Postgres обрабатываются вычисляемые столбцы?
Нужен ли таблицам первичный ключ, чтобы участвовать в Postgres CDC?
- Первичный ключ: Самый простой вариант — задать для таблицы первичный ключ. Он обеспечивает уникальный идентификатор для каждой строки, что крайне важно для отслеживания обновлений и удалений. В этом случае для 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 может влиять на производительность, а также ускорять рост WAL, особенно для таблиц без первичного ключа и с частыми обновлениями или удалениями, поскольку в этом случае для каждого изменения требуется записывать больше данных. Если у вас есть вопросы или вам нужна помощь с настройкой первичных ключей или replica identity для ваших таблиц, обратитесь в нашу службу поддержки.
Важно отметить, что если не задан ни первичный ключ, ни replica identity, ClickPipes не сможет реплицировать изменения для этой таблицы, и в процессе репликации вы можете столкнуться с ошибками. Поэтому перед настройкой ClickPipe рекомендуется проверить схемы таблиц и убедиться, что они соответствуют этим требованиям.
Поддерживаются ли партиционированные таблицы в Postgres CDC?
Можно ли подключать базы данных Postgres без публичного IP-адреса или в частных сетях?
-
SSH-туннелирование
- Подходит для большинства сценариев
- Инструкции по настройке смотрите здесь
- Работает во всех регионах
-
AWS PrivateLink
- Доступно в трёх регионах AWS:
- us-east-1
- us-east-2
- eu-central-1
- Подробные инструкции по настройке см. в нашей документации по PrivateLink
- В регионах, где PrivateLink недоступен, используйте SSH-туннелирование
Как обрабатываются UPDATE и DELETE?
_peerdb_). Движок таблицы ReplacingMergeTree периодически выполняет дедупликацию в фоновом режиме на основе ключа сортировки (столбцов ORDER BY), оставляя только строку с последней версией _peerdb_.
DELETE из Postgres передаются как новые строки с пометкой об удалении (с использованием столбца _peerdb_is_deleted). Поскольку дедупликация выполняется асинхронно, временно вы можете видеть дубликаты. Чтобы это исправить, дедупликацию нужно учитывать на уровне запроса.
Также обратите внимание: по умолчанию Postgres не отправляет значения столбцов, которые не входят в первичный ключ или replica identity, при операциях DELETE. Если вы хотите фиксировать полные данные строки при DELETE, можно установить REPLICA IDENTITY в значение FULL.
Подробнее см.:
Можно ли обновлять столбцы первичного ключа в PostgreSQL?
По умолчанию обновления первичного ключа в PostgreSQL не могут корректно применяться в ClickHouse.Это ограничение связано с тем, что дедупликация в ReplacingMergeTree работает на основе столбцов ORDER BY (которые обычно соответствуют первичному ключу). Когда первичный ключ обновляется в PostgreSQL, в ClickHouse это выглядит как новая строка с другим ключом, а не как обновление существующей строки. В результате в таблице ClickHouse могут одновременно присутствовать старые и новые значения первичного ключа.
Поддерживаются ли изменения схемы?
Сколько стоит ClickPipes для Postgres CDC?
Размер моего слота репликации растет или не уменьшается; в чем может быть причина?
-
Внезапные всплески активности в базе данных
- Крупные пакетные обновления, массовые вставки или существенные изменения схемы могут быстро сгенерировать большой объем WAL-данных.
- Слот репликации будет удерживать эти записи WAL, пока они не будут потреблены, что приведет к временному увеличению его размера.
-
Длительные транзакции
- Открытая транзакция заставляет 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;
-
Операции обслуживания или служебные утилиты (например,
pg_repack)
- Такие инструменты, как
pg_repack, могут полностью переписывать таблицы, создавая большой объем WAL-данных за короткое время.
- Планируйте такие операции на периоды низкой нагрузки или внимательно отслеживайте использование WAL во время их выполнения.
-
VACUUM и VACUUM ANALYZE
- Хотя эти операции необходимы для нормальной работы базы данных, они могут создавать дополнительный WAL-трафик, особенно при сканировании больших таблиц.
- Рассмотрите возможность настройки параметров autovacuum или планируйте ручные операции VACUUM на часы минимальной нагрузки.
-
Потребитель репликации не читает слот
- Если ваш CDC-конвейер (например, ClickPipes) или другой потребитель репликации останавливается, ставится на паузу или аварийно завершается, WAL-данные будут накапливаться в слоте.
- Убедитесь, что ваш конвейер работает непрерывно, и проверьте журналы на наличие ошибок подключения или аутентификации.
Чтобы подробнее разобраться в этой теме, ознакомьтесь с нашей статьей в блоге: Overcoming Pitfalls of Postgres Logical Decoding.
Как типы данных Postgres сопоставляются с типами данных ClickHouse?
Могу ли я задать собственное сопоставление типов данных при репликации данных из Postgres в ClickHouse?
Как реплицируются столбцы JSON и JSONB из Postgres?
Что происходит со вставками, когда mirror приостановлен?
- Для sync: если процесс отменяется в середине, значение confirmed_flush_lsn в Postgres не продвигается, поэтому следующий sync начнется с той же позиции, что и прерванный, обеспечивая согласованность данных.
- Для normalize: порядок вставки в ReplacingMergeTree обеспечивает дедупликацию.
Итог: хотя при приостановке процессы sync и normalize завершаются, делать это безопасно, поскольку они могут возобновиться без потери данных и нарушений согласованности.
Можно ли автоматизировать создание ClickPipe или выполнять его через API или CLI?
Как ускорить начальную загрузку?
snapshot number of tables in parallel или указать собственный индексированный столбец партиционирования для больших таблиц.
Как следует определять состав публикаций при настройке репликации?
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');
-
Исключить таблицы без первичного ключа из ClickPipes:
Создайте публикацию только для таблиц, у которых есть первичный ключ:
CREATE PUBLICATION clickpipes_publication FOR TABLE table_with_primary_key1, table_with_primary_key2, ...;
-
Включить таблицы без первичного ключа в 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.
- Для сред с ограниченным объёмом хранилища: настраивайте этот параметр осторожно, чтобы избежать переполнения диска и при этом обеспечить стабильность репликации.
Как рассчитать нужное значение
Для 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 перезапускается или аварийно завершает работу, соединение будет потеряно.
Мой слот репликации стал недействительным. Что делать?
max_slot_wal_keep_size в вашей базе данных PostgreSQL (например, всего несколько гигабайт). Мы рекомендуем увеличить это значение. Подробнее о настройке max_slot_wal_keep_size см. в этом разделе. В идеале следует установить значение не менее 200 ГБ, чтобы слот репликации не становился недействительным.
В редких случаях мы наблюдали эту проблему даже тогда, когда max_slot_wal_keep_size не был настроен. Это может быть связано со сложной и редкой ошибкой в PostgreSQL, хотя точная причина по-прежнему неясна.
В ClickHouse возникают ошибки нехватки памяти (OOM) во время ингестии данных через мой ClickPipe. Можете помочь?
-
Распространённый способ оптимизации JOIN — если у вас есть
LEFT JOIN, в котором таблица справа очень велика. В этом случае перепишите запрос, используя RIGHT JOIN, и переместите более крупную таблицу в левую часть. Это позволит планировщику запросов эффективнее использовать память.
-
Ещё один способ оптимизации JOIN — явно отфильтровать таблицы с помощью
subqueries или CTEs, а затем выполнить JOIN между этими подзапросами. Это даёт планировщику подсказки о том, как эффективнее фильтровать строки и выполнять JOIN.
Во время начальной загрузки я вижу ошибку invalid snapshot identifier. Что делать?
invalid snapshot identifier возникает, когда между ClickPipes и вашей базой данных Postgres происходит разрыв соединения. Это может случиться из-за тайм-аутов шлюза, перезапусков базы данных или других временных проблем.
Рекомендуется не выполнять никаких операций, способных нарушить работу, таких как обновления или перезапуски базы данных Postgres, пока идет начальная загрузка, а также убедиться, что сетевое соединение с базой данных стабильно.
Чтобы устранить эту проблему, вы можете запустить повторную синхронизацию из интерфейса ClickPipes. Это перезапустит процесс начальной загрузки с самого начала.
Что произойдет, если я удалю публикацию в Postgres?
- Создайте в Postgres новую публикацию с тем же именем и нужными таблицами
- Нажмите кнопку ‘Resync tables’ на вкладке Settings в вашем ClickPipe
Повторная синхронизация необходима, потому что заново созданная публикация будет иметь другой идентификатор объекта (OID) в Postgres, даже если ее имя совпадает. В процессе повторной синхронизации обновляются ваши целевые таблицы и восстанавливается подключение.
При желании вместо этого можно создать новый пайп.
Обратите внимание: если вы работаете с партиционированными таблицами, обязательно создавайте публикацию с соответствующими настройками:
CREATE PUBLICATION clickpipes_publication
FOR TABLE <...>, <...>
WITH (publish_via_partition_root = true);
Что делать, если возникают ошибки Unexpected Datatype или Cannot parse type XX ...
Появляются ошибки вида invalid memory alloc request size <XXX> во время репликации/создания slot
Мне нужно хранить в ClickHouse полную историю данных, даже если они удаляются из исходной базы данных Postgres. Могу ли я полностью игнорировать операции DELETE и TRUNCATE из Postgres в ClickPipes?
CREATE PUBLICATION <pub_name> FOR TABLES IN SCHEMA <schema_name> WITH (publish = 'insert,update');
Почему не удаётся реплицировать таблицу, в имени которой есть точка?
Начальная загрузка завершилась, но в ClickHouse нет данных или отсутствует часть данных. В чем может быть проблема?
- Есть ли у пользователя достаточные разрешения на чтение исходных таблиц.
- Нет ли на стороне ClickHouse политик на уровне строк, из-за которых часть строк может отфильтровываться.
Может ли ClickPipe создать слот репликации с включённым failover?
Advanced Settings при создании ClickPipe. Обратите внимание: для использования этой возможности требуется Postgres версии 17 или выше.
Если источник настроен соответствующим образом, слот сохраняется после переключения на read replica Postgres, обеспечивая непрерывную репликацию данных. Подробнее здесь.
Я вижу ошибки вида Internal error encountered during logical decoding of aborted sub-transaction
ReorderBufferPreserveLastSpilledSnapshot, это означает, что logical decoding не может прочитать снимок, выгруженный на диск. Возможно, стоит увеличить logical_decoding_work_mem до большего значения.
Я вижу ошибки вроде error converting new tuple to map или error parsing logical message во время CDC-репликации
Могу ли я включить столбцы, которые изначально исключил из репликации?
Я вижу, что мой ClickPipe перешел в состояние Snapshot, но данные не поступают — в чем может быть причина?
Параллельное создание снимка: получение партиций может занять время
Создание слота репликации заблокировано транзакцией
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;
Последнее изменение 10 июня 2026 г.
