Перейти к основному содержимому
Перейти к основному содержимому

ClickPipes для Postgres FAQ

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

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

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

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

Пожалуйста, обратитесь к странице Обработка столбцов TOAST для получения дополнительной информации.

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

Пожалуйста, обратитесь к странице Сгенерированные столбцы Postgres: подводные камни и лучшие практики для получения дополнительной информации.

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

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

  • Первичный ключ: Наиболее простой подход — это определить первичный ключ в таблице. Это обеспечивает уникальный идентификатор для каждой строки, что имеет решающее значение для отслеживания обновлений и удалений. В этом случае можно установить REPLICA IDENTITY на DEFAULT (значение по умолчанию).
  • Replica Identity: Если у таблицы нет первичного ключа, можно установить идентичность реплики. Идентичность реплики можно установить на FULL, что означает, что вся строка будет использоваться для идентификации изменений. Альтернативно, можно установить использование уникального индекса, если он существует в таблице, а затем установить REPLICA IDENTITY на USING INDEX index_name. Чтобы установить идентичность реплики на FULL, вы можете использовать следующую SQL команду:
ALTER TABLE your_table_name REPLICA IDENTITY FULL;

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

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

Важно отметить, что если ни первичный ключ, ни идентичность реплики не определены, 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 как новые строки с различными версиями (используя столбец _peerdb_ версии) в ClickHouse. Двигатель таблиц ReplacingMergeTree периодически выполняет дедупликацию в фоновом режиме на основе ключа сортировки (ORDER BY) колонок, оставляя только строку с последней версией _peerdb_.

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

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

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

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

предупреждение

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

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

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

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

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

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

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

Каковы затраты на ClickPipes для Postgres CDC?​

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

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

Если вы замечаете, что размер вашего слота репликации 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;

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

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

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

  2. VACUUM и VACUUM ANALYZE

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

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

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

Для отличного глубокого анализа этой темы, ознакомьтесь с нашей статьей в блоге: Преодоление трудностей логической декодировки Postgres.

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

ClickPipes для Postgres стремится сопоставить типы данных Postgres максимально естественно на стороне ClickHouse. Этот документ содержит исчерпывающий список каждого типа данных и его сопоставление: Матрица типов данных.

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

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

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

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

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

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

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

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

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

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

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

Как мне ускорить свою первичную загрузку?​

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

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

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

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

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

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

  • Минимум: Установите 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 на полученное значение в MB или GB.
Пример​

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

max_slot_wal_keep_size = 200GB

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

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

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

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

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

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

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

Наиболее частая причина недействительности слота репликации — это низкая настройка 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.

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

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

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

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

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

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

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

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

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

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

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

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

Кроме того, вы можете создать совершенно новый канал, если это предпочтительнее.

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

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

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

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

Cannot parse type Decimal(XX, YY), expected non-empty binary data with size equal to or less than ...​

NUMERIC в Postgres имеет действительно высокую точность (до 131072 цифр перед десятичной точкой; до 16383 цифр после десятичной точки), а тип Decimal в ClickHouse позволяет максимум (76 цифр, 39 знаков после запятой). Система предполагает, что обычно размер не будет столь высоким и выполняет оптимистичное преобразование для данного типа, так как исходная таблица может иметь большое количество строк, или строка может поступить в течение фазы CDC.

Текущий обходной путь заключается в том, чтобы сопоставить тип NUMERIC со строкой в ClickHouse. Чтобы включить это, пожалуйста, создайте заявку в службу поддержки, и это будет включено для ваших ClickPipes.

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

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

Мне нужно поддерживать полную историческую запись в 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 отсутствуют данные, возможно, у вас включены политики RLS (безопасность на уровне строк) на ваших исходных таблицах Postgres. Также стоит проверить:

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

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

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

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