> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Preguntas frecuentes sobre ClickPipes para MySQL. # Preguntas frecuentes de ClickPipes para MySQL
### ¿El ClickPipe para MySQL es compatible con MariaDB?
Sí, el ClickPipe para MySQL es compatible con MariaDB 10.0 y versiones posteriores. Su configuración es muy similar a la de MySQL y utiliza replicación GTID de forma predeterminada.
### ¿Por qué falló mi pipe debido a un evento de filas parciales no compatible de MariaDB?
MariaDB 12.3 y versiones posteriores pueden emitir un [evento de filas parciales](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log/row-binlog-events#partial_rows_log_event) en el binlog, que todavía no admitimos. Para recuperarte, resincroniza el pipe. Para reducir la probabilidad de que vuelva a ocurrir, también puedes aumentar la configuración `binlog_row_event_fragment_threshold` en el origen para que se fragmenten menos cambios de filas; mantenla por debajo de `max_allowed_packet`, ya que un único evento del binlog sin fragmentar que supere `max_allowed_packet` hará que falle el stream de replicación (consulta [¿Por qué falla mi pipe con un error de binlog de max\_allowed\_packet?](#binlog-event-exceeded-max-allowed-packet)).
### ¿Por qué falló mi pipe con una columna COMPRESSED no admitida de MariaDB?
Si tu pipe falla con un error similar a: ```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 ``` significa que la tabla tiene una o más columnas que usan la [compresión de columnas](https://mariadb.com/kb/en/storage-engine-independent-column-compression/) de MariaDB (`COLUMN_FORMAT COMPRESSED`). No podemos descomprimir estos valores a partir del binlog, por lo que la tabla afectada no se puede replicar mediante CDC. Para resolverlo: * **Convierta las columnas comprimidas a un tipo no comprimido** en el origen (o elimine una tabla del pipe): ```sql theme={null} ALTER TABLE
MODIFY ; -- sin COLUMN_FORMAT COMPRESSED ``` * vuelva a resincronizar la tabla o el pipe
### ¿El ClickPipe para MySQL es compatible con PlanetScale, Vitess o TiDB?
No, no son compatibles con la API de binlog de MySQL.
### ¿Cómo se gestiona la replicación?
Admitimos la replicación tanto con `GTID` como con `FilePos`. A diferencia de Postgres, no hay ningún slot para gestionar el offset. En su lugar, debe configurar su servidor MySQL con un período de retención del binlog suficiente. Si el offset que usamos en el binlog deja de ser válido *(por ejemplo, si el mirror permanece en pausa demasiado tiempo o si se produce una conmutación por error de la base de datos mientras se usa la replicación `FilePos`)*, tendrá que resincronizar el pipe. Asegúrese de optimizar las vistas materializadas que dependan de las tablas de destino, ya que las consultas ineficientes pueden ralentizar la ingestión y hacer que quede rezagada respecto al período de retención. También es posible que una base de datos inactiva rote el archivo de registro sin permitir que ClickPipes avance a un offset más reciente. Puede que tenga que configurar una tabla de heartbeat con actualizaciones programadas periódicamente. Al inicio de una carga inicial, registramos el offset del binlog desde el que debe comenzar. Este offset debe seguir siendo válido cuando termine la carga inicial para que CDC pueda avanzar. Si va a ingestar una gran cantidad de datos, asegúrese de configurar un período de retención del binlog adecuado. Mientras configura las tablas, puede acelerar la carga inicial configurando *Use a custom partitioning key for initial load* para las tablas grandes en la configuración avanzada, de modo que podamos cargar una sola tabla en paralelo.
### ¿Por qué mi pipe falla con un error de binlog de max\_allowed\_packet?
Si tu pipe falla con un error similar a: ```text theme={null} MySQL execute error: ERROR 1236 (HY000): log event entry exceeded max_allowed_packet; Increase max_allowed_packet on source ``` significa que un único evento del binlog (correspondiente a un cambio en una fila) es más grande que la configuración de [`max_allowed_packet`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_allowed_packet) de tu servidor MySQL. Como el servidor no puede enviar un evento que supere este límite, se interrumpe la lectura del flujo del binlog y CDC no puede avanzar. Esto suele deberse a filas que contienen valores `BLOB`, `TEXT` o `JSON` grandes. Para resolverlo: * **Aumenta `max_allowed_packet` en el origen.** Súbelo por encima del tamaño de tu cambio de fila más grande; normalmente es seguro establecerlo en el máximo de `1G`: ```sql theme={null} SET GLOBAL max_allowed_packet = 1073741824; -- 1 GiB ``` Establécelo también en la configuración del servidor (por ejemplo, `my.cnf` o el grupo de parámetros de la BD) para que persista tras los reinicios. * **Si una sola fila supera 1G:** resincroniza el pipe.
### ¿Por qué falla mi pipe debido a un error de binlog JSON parcial?
Si tu pipe falla con un error similar a: ```text theme={null} Received a partial JSON update event while processing .
; binlog_row_value_options must be disabled (set to '') ``` significa que el servidor MySQL de origen tiene [`binlog_row_value_options`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_row_value_options) establecido en `PARTIAL_JSON`. Con esta opción habilitada, MySQL registra las actualizaciones de columnas `JSON` como diferencias parciales (solo las rutas modificadas) en lugar del documento completo. ClickPipes no puede aplicar estas diferencias parciales, por lo que CDC no puede continuar. Para resolverlo: * **Deshabilite `PARTIAL_JSON` en el origen.** Vuelva a establecer el valor como vacío: ```sql theme={null} SET GLOBAL binlog_row_value_options = ''; ``` Bórrelo también de la configuración del servidor (por ejemplo, `my.cnf` o el grupo de parámetros de la BD) para que el cambio persista tras los reinicios. * **Resincronice el pipe** para que la replicación se reanude desde un offset limpio.
### ¿Por qué falla mi pipe con un error de require\_secure\_transport?
Si tu pipe falla con un error similar a: ```text theme={null} MySQL execute error: handleAuthResult: ERROR 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON. ``` significa que el servidor de origen tiene [`require_secure_transport`](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_require_secure_transport) habilitado — rechaza cualquier conexión que no esté cifrada —, mientras que ClickPipe tiene TLS desactivado. En RDS para MySQL, procede del [grupo de parámetros de la BD](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-ssl-connections.require-ssl.html) de la instancia. En Aurora MySQL, es una configuración del [grupo de parámetros de clúster de la BD](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Security.html#AuroraMySQL.Security.SSL.RequireSSL) y no está disponible en los grupos de parámetros de instancia. Ninguno requiere reiniciarse para que el cambio surta efecto. Además, Aurora MySQL 8.4 lo establece de forma predeterminada en `ON`, mientras que las versiones 2 y 3 lo establecen en `OFF`, por lo que un pipe que se replicaba sin problemas puede empezar a fallar tras un cambio de parámetro o una actualización de versión, sin que haya cambiado nada en el pipe. Para resolverlo: * **Vuelva a habilitar TLS en el pipe.** En **Settings** del pipe, abra la configuración de conexión y desactive el toggle **Disable TLS**. Si al guardar aparece un error de certificado, consulte [¿Por qué recibo un error de validación de certificado TLS al conectarme a MySQL?](#tls-certificate-validation-error) para saber cómo configurar un host TLS, cargar una CA raíz u omitir la verificación de certificados. * **O desactive `require_secure_transport` en el origen** — en el grupo de parámetros de la BD de RDS o en el grupo de parámetros de clúster de la BD de Aurora — si las conexiones no cifradas son aceptables en su entorno. La replicación se reanuda desde el punto en que se detuvo cuando la conexión se establece correctamente. Si el pipe estuvo fallando durante más tiempo que el período de retención del binlog (consulte [¿Cómo se administra la replicación?](#how-is-replication-managed)), deberá resincronizarlo.
### ¿Por qué recibo un error de validación del certificado TLS al conectarme a MySQL?
Al conectarte a MySQL, es posible que encuentres errores de certificado como `x509: certificate is not valid for any names` o `x509: certificate signed by unknown authority`. Esto sucede porque ClickPipes habilita el cifrado TLS de forma predeterminada. Tienes varias opciones para resolver estos problemas: 1. **Configura el campo TLS Host** - Cuando el hostname de tu conexión no coincide con el del certificado (algo habitual con AWS PrivateLink a través de Endpoint Service). Configura "TLS Host (optional)" para que coincida con el nombre común (CN) o el Subject Alternative Name (SAN) del certificado. 2. **Carga tu CA raíz** - Para servidores MySQL que usan autoridades de certificación internas o Google Cloud SQL con la configuración predeterminada de CA por instancia. Para obtener más información sobre cómo acceder a los certificados de Google Cloud SQL, consulta [esta sección](/es/integrations/clickpipes/mysql/source/gcp#download-root-ca-certificate-gcp-mysql). 3. **Configura el certificado del servidor** - Actualiza el certificado SSL de tu servidor para que incluya todos los hostnames de conexión y use una autoridad de certificación de confianza. 4. **Omite la verificación del certificado** - Para MySQL o MariaDB self-hosted, cuyas configuraciones predeterminadas aprovisionan un certificado autofirmado que no podemos validar ([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)). Confiar en este certificado cifra los datos en tránsito, pero conlleva el riesgo de suplantación del servidor. Recomendamos usar certificados correctamente firmados en entornos de producción, pero esta opción resulta útil para hacer pruebas en una instancia aislada o para conectarse a infraestructura heredada.
### ¿Se admiten cambios de esquema?
Consulta la página [ClickPipes for MySQL: Schema Changes Propagation Support](/es/integrations/clickpipes/mysql/schema-changes) para obtener más información.
### ¿Se admite la replicación de eliminaciones en cascada de claves foráneas de MySQL `ON DELETE CASCADE`?
Debido a cómo MySQL [gestiona las eliminaciones en cascada](https://dev.mysql.com/doc/refman/8.0/en/innodb-and-mysql-replication.html), estas no se escriben en el binlog. Por lo tanto, ClickPipes (ni ninguna herramienta de CDC) no puede replicarlas. Esto puede dar lugar a datos inconsistentes. En su lugar, se recomienda usar triggers para implementar eliminaciones en cascada.
### ¿Por qué no puedo replicar mi tabla si su nombre contiene un punto?
Actualmente, PeerDB tiene una limitación: no admite puntos en los identificadores de la tabla de origen, es decir, en el nombre del esquema o en el nombre de la tabla, para la replicación. Esto se debe a que PeerDB no puede distinguir qué parte corresponde al esquema y cuál a la tabla, ya que divide el identificador por el punto. Se está trabajando para permitir la introducción del esquema y la tabla por separado y así superar esta limitación.
### ¿Puedo incluir columnas que inicialmente excluí de la replicación?
Esto aún no se admite; una alternativa es [resincronizar la tabla](/es/integrations/clickpipes/mysql/table-resync) de la que quieres incluir columnas.