¿El ClickPipe para MySQL es compatible con MariaDB?
¿Por qué falló mi pipe debido a un evento de filas parciales no compatible de MariaDB?
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?).
¿Por qué falló mi pipe con una columna COMPRESSED no admitida 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):
- vuelva a resincronizar la tabla o el pipe
¿El ClickPipe para MySQL es compatible con PlanetScale, Vitess o TiDB?
¿Cómo se gestiona la replicación?
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?
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_packeten 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 de1G:Establécelo también en la configuración del servidor (por ejemplo,my.cnfo 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?
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_JSONen el origen. Vuelva a establecer el valor como vacío:Bórrelo también de la configuración del servidor (por ejemplo,my.cnfo 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?
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 de la instancia. En Aurora MySQL, es una configuración del grupo de parámetros de clúster de la BD 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? para saber cómo configurar un host TLS, cargar una CA raíz u omitir la verificación de certificados.
- O desactive
require_secure_transporten 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.
¿Por qué recibo un error de validación del certificado TLS al conectarme a MySQL?
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:
- 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.
- 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.
- 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.
- Omite la verificación del certificado - Para MySQL o MariaDB self-hosted, cuyas configuraciones predeterminadas aprovisionan un certificado autofirmado que no podemos validar (MySQL, MariaDB). 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.