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

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



# ClickPipes для Postgres FAQ

### Как простои влияют на мой Postgres CDC ClickPipe? \{#how-does-idling-affect-my-postgres-cdc-clickpipe}

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

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

### Как обрабатываются столбцы TOAST в ClickPipes для Postgres? \{#how-are-toast-columns-handled-in-clickpipes-for-postgres}

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

### Как обрабатываются сгенерированные столбцы в ClickPipes для Postgres? \{#how-are-generated-columns-handled-in-clickpipes-for-postgres}

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

### Должны ли таблицы иметь первичные ключи, чтобы стать частью Postgres CDC? \{#do-tables-need-to-have-primary-keys-to-be-part-of-postgres-cdc}

Да, для CDC таблицы должны иметь либо первичный ключ, либо [REPLICA IDENTITY](https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-REPLICA-IDENTITY). REPLICA IDENTITY может быть установлен в FULL или настроен для использования уникального индекса.

### Поддерживаете ли вы партиционированные таблицы как часть Postgres CDC? \{#do-you-support-partitioned-tables-as-part-of-postgres-cdc}

Да, партиционированные таблицы поддерживаются "из коробки", если они имеют определенный ПЕРВИЧНЫЙ КЛЮЧ или REPLICA IDENTITY. ПЕРВИЧНЫЙ КЛЮЧ и REPLICA IDENTITY должны присутствовать как на родительской таблице, так и на её партициях. Вы можете прочитать об этом [здесь](https://blog.peerdb.io/real-time-change-data-capture-for-postgres-partitioned-tables).

### Могу ли я подключить базы данных Postgres, у которых нет публичного IP или они находятся в частных сетях? \{#can-i-connect-postgres-databases-that-dont-have-a-public-ip-or-are-in-private-networks}

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

1. **SSH-туннелирование**
   - Хорошо работает для большинства вариантов использования
   - Просмотрите инструкции по настройке [здесь](/integrations/clickpipes/postgres#adding-your-source-postgres-database-connection)
   - Работает во всех регионах

2. **AWS PrivateLink**
   - Доступно в трех регионах AWS:
     - us-east-1
     - us-east-2
     - eu-central-1
   - Для подробных инструкций по настройке смотрите нашу [документацию по PrivateLink](/knowledgebase/aws-privatelink-setup-for-clickpipes)
   - Для регионов, где PrivateLink недоступен, пожалуйста, используйте SSH-туннелирование.

### Как вы обрабатываете UPDATE и DELETE? \{#how-do-you-handle-updates-and-deletes}

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

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

Для получения дополнительных сведений обратитесь к:

* [Рекомендуемые практики для движка таблиц ReplacingMergeTree](https://docs.peerdb.io/bestpractices/clickhouse_datamodeling#replacingmergetree-table-engine)
* [Блог о внутреннем устройстве Postgres-to-ClickHouse CDC](https://clickhouse.com/blog/postgres-to-clickhouse-data-modeling-tips)

### Поддерживаете ли вы изменения схемы? \{#do-you-support-schema-changes}

Пожалуйста, обратитесь к странице [ClickPipes для Postgres: Поддержка распространения изменений схемы](./schema-changes) для получения дополнительной информации.

### Каковы расходы на ClickPipes для Postgres CDC? \{#what-are-the-costs-for-clickpipes-for-postgres-cdc}

Во время превью ClickPipes бесплатен. После выпуска GA цены еще предстоит определить. Цель состоит в том, чтобы сделать цены разумными и высококонкурентными по сравнению с внешними инструментами ETL.

### Мой размер репликационного слота растет или не уменьшается; в чем может быть проблема? \{#my-replication-slot-size-is-growing-or-not-decreasing-what-might-be-the-issue}

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

1. **Внезапные всплески активности базы данных**  
   - Большие пакетные обновления, массовые вставки или значительные изменения схемы могут быстро генерировать много данных WAL.  
   - Репликационный слот будет сохранять эти записи WAL, пока они не будут потреблены, что приведет к временным всплескам размера.

2. **Долгие транзакции**  
   - Открытая транзакция заставляет Postgres сохранять все сегменты WAL, сгенерированные с момента начала транзакции, что может значительно увеличить размер слота.  
   - Установите `statement_timeout` и `idle_in_transaction_session_timeout` на разумные значения, чтобы предотвратить бесконечное открытие транзакций:
     ```sql
     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 для создания Postgres ClickPipes.

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

Вы не можете ускорить уже работающую первоначальную загрузку. Однако вы можете оптимизировать будущие первоначальные загрузки, изменив определенные настройки. По умолчанию настройки настроены на 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, ...;

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

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

  • Минимум: Установите 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

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

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

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

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

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

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

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

Ошибка недействительный идентификатор снимка возникает, когда происходит сбой соединения между 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);

Что делать, если я вижу ошибки Неожиданный тип данных или Не удается разобрать тип XX ...​

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

Не удается разобрать тип Decimal(XX, YY), требуется ненулевая двоичная информация размером не более ...​

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

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