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

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

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

  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 на этих таблицах.

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

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

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

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

подсказка

Если вы создаете публикацию вручную вместо того, чтобы позволить ClickPipes управлять ею, мы не рекомендуем создавать публикацию FOR ALL TABLES, это приведет к большему трафику от Postgres к ClickPipes (для отправки изменений для других таблиц, не входящих в конвейер), и снизит общую эффективность.

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

  • Минимум: Установите 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 (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, даже если она имеет то же имя. Процесс повторной синхронизации обновляет ваши целевые таблицы и восстанавливает соединение.

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

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

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

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

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

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

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