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

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

• Лучшие практики для табличного движка ReplacingMergeTree
• Блог о внутренних механизмах постгреса в ClickHouse CDC

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

Пожалуйста, обратитесь к странице 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. Ожидаем, что это будет выпущено в ближайшем будущем (в течение месяца). Если вас интересует возможность стать партнером по дизайну для этой функции, пожалуйста, свяжитесь с [email protected].

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

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

• Минимально: Установите 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 является недостаточный размер вашего сервиса. Это означает, что текущая конфигурация вашего сервиса не имеет достаточных ресурсов (например, памяти или ЦП), чтобы эффективно справляться с нагрузкой по загрузке данных. Мы настоятельно рекомендуем увеличить мощность сервиса, чтобы соответствовать требованиям вашей загрузки данных ClickPipe.

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

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

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

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

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

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

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