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

Часто задаваемые вопросы о 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-туннелирование

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

  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 (журнал предшествующих изменений) не потребляются (или "воспроизводятся") достаточно быстро вашим конвейером 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), так и нормализации (из «сырой» таблицы в целевую таблицу) будут прерваны. Тем не менее, они сохраняют состояние, необходимое для надежного возобновления.

  • Для синхронизации, если она была прервана, подтвержденный 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 на полученное значение в MB или GB.

Пример:​

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

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

Единственный способ восстановить 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.

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

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

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

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