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

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

Поддерживает ли MySQL ClickPipe MariaDB?​

Да, MySQL ClickPipe поддерживает MariaDB версии 10.0 и выше. Настройка для MariaDB очень похожа на MySQL, по умолчанию используется репликация GTID.

Поддерживает ли MySQL ClickPipe PlanetScale, Vitess или TiDB?​

Нет, эти системы не поддерживают API двоичного лога (binlog) MySQL.

Как управляется репликация?​

Мы поддерживаем репликацию как по GTID, так и по FilePos. В отличие от Postgres, здесь нет слота для управления смещением. Вместо этого вы должны настроить достаточный период хранения binlog на сервере MySQL. Если наше смещение в binlog становится недействительным (например, зеркало было приостановлено слишком надолго или произошёл failover базы данных при использовании репликации по FilePos), то вам потребуется повторно синхронизировать конвейер ClickPipe. Обязательно оптимизируйте materialized views в зависимости от целевых таблиц, так как неэффективные запросы могут настолько замедлить ингестию, что она начнёт отставать от периода хранения.

Также возможно, что неактивная база данных будет ротировать файл журнала, не давая ClickPipes продвинуться к более свежему смещению. Возможно, вам потребуется настроить таблицу heartbeat с регулярными обновлениями.

В начале начальной загрузки мы фиксируем смещение binlog, с которого следует стартовать. Это смещение должно оставаться действительным к моменту завершения начальной загрузки, чтобы CDC (фиксация изменений данных) могла продолжиться. Если вы осуществляете приём большого объёма данных, обязательно настройте соответствующий период хранения binlog. При настройке таблиц вы можете ускорить начальную загрузку, сконфигурировав параметр Use a custom partitioning key for initial load для крупных таблиц в расширенных настройках, чтобы мы могли загружать одну таблицу параллельно.

Почему при подключении к MySQL возникает ошибка проверки TLS-сертификата?​

При подключении к MySQL вы можете столкнуться с ошибками сертификатов, такими как x509: certificate is not valid for any names или x509: certificate signed by unknown authority. Они возникают, потому что ClickPipes по умолчанию включает шифрование TLS.

У вас есть несколько вариантов решения этих проблем:

  1. Укажите значение поля TLS Host — если имя хоста в вашем подключении отличается от имени в сертификате (что часто бывает при использовании AWS PrivateLink через Endpoint Service). Установите значение "TLS Host (optional)" так, чтобы оно совпадало с Common Name (CN) или Subject Alternative Name (SAN) сертификата.

  2. Загрузите ваш Root CA — для серверов MySQL, использующих внутренние удостоверяющие центры (Certificate Authorities), или Google Cloud SQL в конфигурации по умолчанию с отдельным CA на инстанс. Дополнительную информацию о том, как получить сертификаты Google Cloud SQL, см. в этом разделе.

  3. Настройте сертификат сервера — обновите SSL-сертификат вашего сервера так, чтобы он включал все имена хостов, по которым выполняется подключение, и был выдан доверенным удостоверяющим центром (Certificate Authority).

  4. Отключите проверку сертификата — для самостоятельно развернутых (self-hosted) MySQL или MariaDB, чьи конфигурации по умолчанию создают самоподписанный сертификат, который мы не можем проверить (MySQL, MariaDB). Использование такого сертификата шифрует данные при передаче, но создает риск подмены сервера. Мы рекомендуем использовать корректно подписанные сертификаты для продуктивных (production) сред, но этот вариант полезен для одноразового тестирования или подключения к легаси-инфраструктуре.

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

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

Поддерживается ли репликация каскадных удалений внешних ключей MySQL ON DELETE CASCADE?​

Из-за особенностей того, как MySQL обрабатывает каскадные удаления, они не записываются в binlog. Поэтому ClickPipes (как и любой инструмент CDC) не может реплицировать такие операции. Это может привести к несогласованным данным. Для обеспечения каскадных удалений рекомендуется использовать триггеры.

Почему я не могу реплицировать таблицу, в имени которой есть точка?​

В PeerDB в данный момент есть ограничение: точки в идентификаторах исходных таблиц — то есть либо в имени схемы, либо в имени таблицы — не поддерживаются для репликации, так как в этом случае PeerDB разделяет идентификатор по точке и не может однозначно определить, где схема, а где таблица. Ведётся работа по добавлению поддержки раздельного ввода схемы и таблицы, чтобы обойти это ограничение.

Могу ли я включить столбцы, которые были изначально исключены из репликации?​

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