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

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

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

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

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

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

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

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

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

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

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

Поддерживаете ли вы разделенные таблицы как часть Postgres CDC?​

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

Могу ли я подключить базы данных Postgres, которые не имеют общедоступного IP или находятся в частных сетях?​

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

  1. SSH Tunneling

    • Хорошо подходит для большинства случаев использования
    • Смотрите инструкции по настройке здесь
    • Работает во всех регионах

  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). Поскольку процесс дедупликации асинхронен, вы можете временно видеть дубликаты. Чтобы решить эту проблему, вам нужно обрабатывать дедупликацию на уровне запроса.

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

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

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

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

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

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

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

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

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

  2. Долгосрочные транзакции

    • Открытая транзакция заставляет Postgres хранить все сегменты WAL, сгенерированные с начала транзакции, что может значительно увеличить размер слота.
    • Установите statement_timeout и idle_in_transaction_session_timeout на разумные значения, чтобы предотвратить бесконечное открытие транзакций:
      Используйте этот запрос, чтобы выявить необычно долгие транзакции.

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

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

  4. VACUUM и VACUUM ANALYZE

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

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

    • Если ваш конвейер 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 только через интерфейс пользователя. Однако мы активно работаем над открытием конечных точек OpenAPI и Terraform. Мы ожидаем, что это будет выпущено в ближайшие месяцы (в течение месяца). Если вы заинтересованы в том, чтобы стать партнером по дизайну для этой функции, пожалуйста, свяжитесь с db-integrations-support@clickhouse.com.

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

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

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

У вас есть два варианта при работе с таблицами без первичных ключей:

  1. Исключить таблицы без первичных ключей из ClickPipes: Создайте публикацию только с таблицами, которые имеют первичный ключ:

  2. Включить таблицы без первичных ключей в ClickPipes: Если вы хотите включить таблицы без первичного ключа, вам нужно изменить их репликационную идентичность на FULL. Это гарантирует, что операции UPDATE и DELETE работают корректно:

  • Минимум: Установите max_slot_wal_keep_size для хранения как минимум двух дней данных WAL.
  • Для больших баз данных (высокий объем транзакций): Храните как минимум в 2-3 раза больше пикового объема генерации WAL в день.
  • Для сред с ограниченной памятью: Настройте это консервативно, чтобы избежать исчерпания диска, обеспечивая при этом устойчивость репликации.

Как рассчитать правильное значение​

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

Для PostgreSQL 10+:​

Для PostgreSQL 9.6 и ниже:​

  • Запускайте этот запрос в различные часы дня, особенно в периоды высокой транзакционной активности.
  • Рассчитайте, сколько WAL генерируется за 24-часовой период.
  • Умножьте это число на 2 или 3 для обеспечения достаточного хранения.
  • Установите max_slot_wal_keep_size на полученное значение в МБ или ГБ.

Пример:​

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

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

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

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

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

Я наблюдаю Out Of Memory (OOMs) на ClickHouse во время загрузки данных в мой ClickPipe. Можете помочь?​

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

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

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

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

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

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

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

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