> ## Documentation Index > Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt > Use this file to discover all available pages before exploring further. > Часто задаваемые вопросы о ClickPipes для MySQL. # FAQ по ClickPipes для MySQL
### Поддерживает ли MySQL ClickPipe MariaDB?
Да, MySQL ClickPipe поддерживает MariaDB 10.0 и выше. Его конфигурация очень похожа на конфигурацию MySQL, при этом по умолчанию используется GTID-репликация.
### Почему мой пайп завершился сбоем из-за неподдерживаемого события частичных строк MariaDB?
MariaDB 12.3 и более поздние версии могут записывать в binlog [события частичных строк](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log/row-binlog-events#partial_rows_log_event), которые мы пока не поддерживаем. Чтобы восстановить работу, выполните повторную синхронизацию пайпа. Чтобы снизить вероятность повторного возникновения этой проблемы, можно также увеличить значение параметра `binlog_row_event_fragment_threshold` на источнике, чтобы фрагментировалось меньше изменений строк. Значение должно быть меньше `max_allowed_packet`, поскольку одно нефрагментированное событие binlog размером больше `max_allowed_packet` вместо этого приведёт к сбою потока репликации (см. [Почему мой пайп завершается сбоем из-за ошибки binlog max\_allowed\_packet?](#binlog-event-exceeded-max-allowed-packet)).
### Почему мой пайп завершился ошибкой из-за неподдерживаемого столбца COMPRESSED в MariaDB?
Если ваш пайп завершается с ошибкой, похожей на следующую: ```text theme={null} table . has MariaDB COMPRESSED column(s) [], which cannot be replicated via CDC; convert them to a non-compressed type or remove the table from the mirror ``` это означает, что в таблице есть один или несколько столбцов с [сжатием столбцов](https://mariadb.com/kb/en/storage-engine-independent-column-compression/) MariaDB (`COLUMN_FORMAT COMPRESSED`). Мы не можем распаковать эти значения из binlog, поэтому такую таблицу нельзя реплицировать через CDC (фиксация изменений данных). Чтобы это исправить: * **Преобразуйте сжатые столбцы в несжатый тип** в исходной БД (или удалите таблицу из пайпа): ```sql theme={null} ALTER TABLE
MODIFY ; -- без COLUMN_FORMAT COMPRESSED ``` * повторно синхронизируйте таблицу или пайп
### Поддерживает ли MySQL ClickPipe PlanetScale, Vitess или TiDB?
Нет, они не поддерживают binlog API MySQL.
### Как управляется репликация?
Мы поддерживаем репликацию как через `GTID`, так и через `FilePos`. В отличие от Postgres, здесь нет слота для управления смещением. Вместо этого нужно настроить сервер MySQL с достаточным периодом хранения binlog. Если наше смещение в binlog станет недействительным *(например, если mirror был слишком долго приостановлен или при использовании репликации `FilePos` произошло аварийное переключение базы данных)*, вам потребуется повторно синхронизировать пайп. Обязательно оптимизируйте materialized view, зависящие от целевых таблиц, поскольку неэффективные запросы могут замедлить ингестию так, что она начнёт отставать и выйдет за пределы периода хранения. Также возможно, что неактивная база данных выполнит ротацию файла журнала, не давая ClickPipes перейти к более новому смещению. В этом случае может потребоваться настроить таблицу heartbeat с регулярными обновлениями по расписанию. В начале начальной загрузки мы фиксируем смещение binlog, с которого нужно начинать. Это смещение должно оставаться действительным к моменту завершения начальной загрузки, чтобы CDC (фиксация изменений данных) мог продолжиться. Если вы выполняете приём большого объёма данных, обязательно настройте подходящий период хранения binlog. При настройке таблиц вы можете ускорить начальную загрузку, включив параметр *Use a custom partitioning key for initial load* для больших таблиц в расширенных настройках, чтобы мы могли загружать одну таблицу параллельно.
### Почему мой пайп завершается из-за ошибки max\_allowed\_packet binlog?
Если ваш пайп завершается с ошибкой, похожей на: ```text theme={null} MySQL execute error: ERROR 1236 (HY000): log event entry exceeded max_allowed_packet; Increase max_allowed_packet on source ``` это означает, что одно событие binlog (соответствующее изменению одной строки) больше, чем значение [`max_allowed_packet`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_allowed_packet) на вашем сервере MySQL. Поскольку сервер не может отправить событие, превышающее этот лимит, чтение потока binlog прерывается, и CDC (фиксация изменений данных) не может продвигаться дальше. Чаще всего это происходит из-за строк с большими значениями `BLOB`, `TEXT` или `JSON`. Чтобы устранить проблему: * **Увеличьте `max_allowed_packet` на источнике.** Установите значение больше размера самого крупного изменения строки — обычно безопасно задать максимальное значение `1G`: ```sql theme={null} SET GLOBAL max_allowed_packet = 1073741824; -- 1 GiB ``` Также задайте его в конфигурации сервера (например, в `my.cnf` или в DB Parameter Group), чтобы значение сохранялось после перезапуска. * **Если одна строка больше 1G:** выполните повторную синхронизацию пайпа.
### Почему мой пайп завершается с ошибкой частичного JSON binlog?
Если пайп завершается ошибкой, подобной следующей: ```text theme={null} Received a partial JSON update event while processing .
; binlog_row_value_options must be disabled (set to '') ``` это означает, что на исходном сервере MySQL для [`binlog_row_value_options`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_row_value_options) задано значение `PARTIAL_JSON`. При включении этой опции MySQL записывает обновления в столбцах `JSON` как частичные изменения (только изменённые пути), а не как полный документ. ClickPipes не может применить такие частичные изменения, поэтому CDC не может продолжить работу. Чтобы устранить проблему: * **Отключите `PARTIAL_JSON` на источнике.** Сбросьте значение до пустого: ```sql theme={null} SET GLOBAL binlog_row_value_options = ''; ``` Также удалите эту настройку из конфигурации сервера (например, `my.cnf` или DB Parameter Group), чтобы она не восстанавливалась после перезапуска. * **Выполните повторную синхронизацию пайпа**, чтобы репликация возобновилась с чистого смещения.
### Почему мой пайп завершается с ошибкой require\_secure\_transport?
Если ваш пайп завершается с ошибкой, похожей на: ```text theme={null} MySQL execute error: handleAuthResult: ERROR 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON. ``` это означает, что на исходном сервере включен [`require_secure_transport`](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_require_secure_transport) — он отклоняет любые незашифрованные подключения, — тогда как в ClickPipe TLS отключен. В RDS for MySQL это задается в [группе параметров БД](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-ssl-connections.require-ssl.html) экземпляра. В Aurora MySQL это настройка [группы параметров кластера БД](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Security.html#AuroraMySQL.Security.SSL.RequireSSL), которая вообще недоступна в группах параметров экземпляров. Ни одна из этих настроек не требует перезагрузки для вступления в силу. В Aurora MySQL 8.4 по умолчанию задано значение `ON`, тогда как в версиях 2 и 3 по умолчанию используется `OFF`. Поэтому пайп, который ранее успешно выполнял репликацию, может начать завершаться с ошибкой после изменения параметра или обновления версии, даже если настройки пайпа не менялись. Чтобы устранить проблему: * **Снова включите TLS в пайпе.** В разделе **Settings** пайпа откройте настройки подключения и выключите переключатель **Disable TLS**. Если при сохранении появится ошибка сертификата, см. [Почему при подключении к MySQL возникает ошибка проверки TLS-сертификата?](#tls-certificate-validation-error), чтобы узнать, как указать TLS-хост, загрузить корневой CA или пропустить проверку сертификата. * **Или отключите `require_secure_transport` в источнике** — в группе параметров БД для RDS или в группе параметров кластера БД для Aurora — если в вашей среде допустимы незашифрованные подключения. После успешного подключения репликация возобновится с места остановки. Если пайп завершался с ошибкой дольше периода хранения binlog (см. [Как управляется репликация?](#how-is-replication-managed)), потребуется выполнить его повторную синхронизацию.
### Почему при подключении к 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. **Загрузите свой корневой CA** — для серверов MySQL, использующих внутренние центры сертификации, или Google Cloud SQL со стандартной конфигурацией CA на instance. Подробнее о том, как получить доступ к сертификатам Google Cloud SQL, см. [в этом разделе](/docs/ru/integrations/clickpipes/mysql/source/gcp#download-root-ca-certificate-gcp-mysql). 3. **Настройте сертификат сервера** — обновите SSL-сертификат сервера так, чтобы он включал все имена хостов, используемые для подключения, и был подписан доверенным центром сертификации. 4. **Отключите проверку сертификата** — для самоуправляемого MySQL или MariaDB, в конфигурации по умолчанию которых создаётся самоподписанный сертификат, который мы не можем проверить ([MySQL](https://dev.mysql.com/doc/refman/8.4/en/creating-ssl-rsa-files-using-mysql.html#creating-ssl-rsa-files-using-mysql-automatic), [MariaDB](https://mariadb.com/kb/en/securing-connections-for-client-and-server/#enabling-tls-for-mariadb-server)). Использование такого сертификата шифрует данные при передаче, но создаёт риск подмены сервера. Для промышленных сред мы рекомендуем использовать корректно подписанные сертификаты, однако этот вариант удобен для разового тестирования или при подключении к устаревшей инфраструктуре.
### Поддерживаются ли изменения схемы?
Подробнее см. на странице [ClickPipes for MySQL: Поддержка передачи изменений схемы](/docs/ru/integrations/clickpipes/mysql/schema-changes).
### Поддерживается ли репликация каскадных удалений по внешним ключам MySQL `ON DELETE CASCADE`?
Из-за особенностей [обработки каскадных удалений](https://dev.mysql.com/doc/refman/8.0/en/innodb-and-mysql-replication.html) в MySQL они не записываются в binlog. Поэтому ClickPipes (как и любой инструмент CDC (фиксация изменений данных)) не может их реплицировать. Это может привести к несогласованности данных. Для поддержки каскадных удалений рекомендуется использовать триггеры.
### Почему я не могу реплицировать таблицу, если в её имени есть точка?
В PeerDB пока есть ограничение: если в идентификаторе исходной таблицы — то есть в имени схемы или имени таблицы — есть точки, репликация не поддерживается. Это связано с тем, что PeerDB разделяет идентификатор по точке и в таком случае не может понять, где схема, а где таблица. Сейчас ведётся работа над тем, чтобы поддержать отдельный ввод схемы и таблицы и тем самым обойти это ограничение.
### Можно ли включить столбцы, которые я изначально исключил из репликации?
Пока это не поддерживается. В качестве альтернативы можно [повторно синхронизировать таблицу](/docs/ru/integrations/clickpipes/mysql/table-resync), столбцы из которой вы хотите включить.