¿Se replican en ClickHouse las reversiones de transacciones?
¿Puedo conservar datos en ClickHouse durante más tiempo que en el Postgres de origen?
¿Cómo puedo enriquecer los datos a medida que se transfieren de Postgres a ClickHouse?
¿Puedo replicar desde varias instancias de Postgres a uno o más servicios de ClickHouse?
¿Cómo afecta la inactividad a mi ClickPipe de Postgres CDC?
¿Cómo se manejan las columnas TOAST en ClickPipes for Postgres?
¿Cómo se manejan las columnas generadas en ClickPipes for Postgres?
¿Las tablas necesitan tener una clave primaria para formar parte de Postgres CDC?
- Clave primaria: La forma más sencilla es definir una clave primaria en la tabla. Esto proporciona un identificador único para cada fila, lo cual es fundamental para seguir las actualizaciones y eliminaciones. En este caso, puedes tener REPLICA IDENTITY configurada como
DEFAULT (el comportamiento predeterminado).
- Replica Identity: Si una tabla no tiene clave primaria, puedes configurar una replica identity. La replica identity puede establecerse en
FULL, lo que significa que se usará la fila completa para identificar los cambios. Como alternativa, puedes configurarla para usar un índice único si existe uno en la tabla y, después, establecer REPLICA IDENTITY en USING INDEX index_name.
Para establecer la replica identity en FULL, puedes usar el siguiente comando SQL:
ALTER TABLE your_table_name REPLICA IDENTITY FULL;
REPLICA IDENTITY FULL puede afectar al rendimiento y acelerar el crecimiento del WAL, especialmente en tablas sin clave primaria y con actualizaciones o eliminaciones frecuentes, ya que exige registrar más datos en cada cambio. Si tienes alguna duda o necesitas ayuda para configurar claves primarias o identidades de réplica en tus tablas, ponte en contacto con nuestro equipo de soporte para recibir orientación.
Es importante tener en cuenta que, si no se define ni una clave primaria ni una identidad de réplica, ClickPipes no podrá replicar los cambios de esa tabla, y podrías encontrarte con errores durante el proceso de replicación. Por lo tanto, se recomienda revisar los esquemas de tus tablas y asegurarte de que cumplan estos requisitos antes de configurar tu ClickPipe.
¿Se admiten tablas particionadas como parte de Postgres CDC?
¿Puedo conectar bases de datos de Postgres que no tienen una IP pública o que están en redes privadas?
-
Túnel SSH
- Funciona bien para la mayoría de los casos de uso
- Consulta las instrucciones de configuración aquí
- Funciona en todas las regiones
-
AWS PrivateLink
- Disponible en tres regiones de AWS:
- us-east-1
- us-east-2
- eu-central-1
- Para obtener instrucciones detalladas de configuración, consulta nuestra documentación de PrivateLink
- En las regiones donde PrivateLink no está disponible, usa el túnel SSH
¿Cómo se gestionan los UPDATEs y DELETEs?
_peerdb_) en ClickHouse. El motor de tabla ReplacingMergeTree realiza periódicamente la deduplicación en segundo plano en función de la clave de ordenación (columnas ORDER BY), conservando solo la fila con la versión _peerdb_ más reciente.
Los DELETEs de Postgres se propagan como filas nuevas marcadas como eliminadas (mediante la columna _peerdb_is_deleted). Como el proceso de deduplicación es asíncrono, es posible que veas duplicados temporalmente. Para resolverlo, debes gestionar la deduplicación en la capa de consulta.
Ten en cuenta también que, de forma predeterminada, Postgres no envía los valores de las columnas que no forman parte de la clave primaria o de la identidad de réplica durante las operaciones DELETE. Si quieres capturar los datos completos de la fila durante los DELETEs, puedes establecer REPLICA IDENTITY en FULL.
Para obtener más información, consulta:
¿Puedo actualizar columnas de la clave primaria en PostgreSQL?
De forma predeterminada, las actualizaciones de la clave primaria en PostgreSQL no se pueden reproducir correctamente en ClickHouse.Esta limitación existe porque la deduplicación de ReplacingMergeTree se basa en las columnas de ORDER BY (que normalmente corresponden a la clave primaria). Cuando se actualiza una clave primaria en PostgreSQL, en ClickHouse aparece como una fila nueva con una clave distinta, en lugar de como una actualización de la fila existente. Esto puede hacer que tanto los valores antiguos como los nuevos de la clave primaria coexistan en su tabla de ClickHouse.
¿Se admiten cambios de esquema?
¿Cuáles son los costos de ClickPipes for Postgres CDC?
El tamaño de mi slot de replicación está creciendo o no disminuye; ¿cuál podría ser el problema?
-
Picos repentinos en la actividad de la base de datos
- Las actualizaciones masivas, los inserts en bloque o los cambios importantes en el esquema pueden generar rápidamente una gran cantidad de datos WAL.
- El slot de replicación conservará estos registros WAL hasta que se consuman, lo que provocará un aumento temporal de tamaño.
-
Transacciones de larga duración
- Una transacción abierta obliga a Postgres a conservar todos los segmentos WAL generados desde que comenzó la transacción, lo que puede aumentar drásticamente el tamaño del slot.
- Establece
statement_timeout e idle_in_transaction_session_timeout en valores razonables para evitar que las transacciones permanezcan abiertas indefinidamente:
SELECT
pid,
state,
age(now(), xact_start) AS transaction_duration,
query AS current_query
FROM
pg_stat_activity
WHERE
xact_start IS NOT NULL
ORDER BY
age(now(), xact_start) DESC;
-
Operaciones de mantenimiento o utilidades (por ejemplo,
pg_repack)
- Herramientas como
pg_repack pueden reescribir tablas completas, generando grandes cantidades de datos WAL en poco tiempo.
- Programa estas operaciones durante períodos de menor tráfico o supervisa de cerca el uso de WAL mientras se ejecutan.
-
VACUUM y VACUUM ANALYZE
- Aunque son necesarios para la salud de la base de datos, estas operaciones pueden generar tráfico WAL adicional, especialmente si escanean tablas grandes.
- Considera usar parámetros de ajuste de autovacuum o programar operaciones manuales de VACUUM durante horas de baja actividad.
-
El consumidor de replicación no está leyendo activamente el slot
- Si tu pipeline de CDC (por ejemplo, ClickPipes) u otro consumidor de replicación se detiene, se pausa o falla, los datos WAL se acumularán en el slot.
- Asegúrate de que tu pipeline esté ejecutándose de forma continua y revisa los logs para detectar errores de conectividad o autenticación.
Para profundizar en este tema, consulta nuestra entrada de blog: Overcoming Pitfalls of Postgres Logical Decoding.
¿Cómo se mapean los tipos de datos de Postgres a ClickHouse?
¿Puedo definir mi propio mapeo de tipos de datos al replicar datos de Postgres a ClickHouse?
¿Cómo se replican las columnas JSON y JSONB desde Postgres?
¿Qué sucede con las inserciones cuando se pausa un mirror?
- En el caso de sync, si se cancela a mitad del proceso, el confirmed_flush_lsn en Postgres no avanza, por lo que la siguiente sync comenzará desde la misma posición que la abortada, lo que garantiza la consistencia de los datos.
- En el caso de normalize, el orden de inserción de ReplacingMergeTree se encarga de la deduplicación.
En resumen, aunque los procesos de sync y normalize se terminan durante una pausa, es seguro hacerlo, ya que pueden reanudarse sin pérdida de datos ni inconsistencias.
Un ClickPipe de Postgres también se puede crear y gestionar mediante los endpoints de OpenAPI. Esta funcionalidad está en beta, y la referencia de la API está disponible aquí. Además, estamos trabajando activamente en la compatibilidad con Terraform para crear también ClickPipes de Postgres.
¿Cómo puedo acelerar mi carga inicial?
snapshot number of tables in parallel o especificar una columna de particionamiento personalizada e indexada para las tablas grandes.
¿Cómo debo delimitar mis publicaciones al configurar la replicación?
REPLICA IDENTITY FULL. Si tiene tablas sin clave primaria, crear una publicación para todas las tablas hará que las operaciones DELETE y UPDATE fallen en esas tablas.
Para identificar las tablas sin claves primarias en su base de datos, puede usar esta consulta:
SELECT table_schema, table_name
FROM information_schema.tables
WHERE
(table_catalog, table_schema, table_name) NOT IN (
SELECT table_catalog, table_schema, table_name
FROM information_schema.table_constraints
WHERE constraint_type = 'PRIMARY KEY') AND
table_schema NOT IN ('information_schema', 'pg_catalog', 'pgq', 'londiste');
-
Excluir de ClickPipes las tablas sin clave primaria:
Cree la publicación solo con las tablas que tienen clave primaria:
CREATE PUBLICATION clickpipes_publication FOR TABLE table_with_primary_key1, table_with_primary_key2, ...;
-
Incluir en ClickPipes las tablas sin clave primaria:
Si quiere incluir tablas sin clave primaria, debe cambiar su identidad de réplica a
FULL. Esto garantiza que las operaciones UPDATE y DELETE funcionen correctamente:
ALTER TABLE table_without_primary_key1 REPLICA IDENTITY FULL;
ALTER TABLE table_without_primary_key2 REPLICA IDENTITY FULL;
CREATE PUBLICATION clickpipes_publication FOR TABLE <...>, <...>;
Si está creando una publicación manualmente en lugar de dejar que ClickPipes la gestione, no recomendamos crear una publicación FOR ALL TABLES, ya que esto genera más tráfico de Postgres hacia ClickPipes (al enviar cambios de otras tablas que no están en el pipe) y reduce la eficiencia general.En las publicaciones creadas manualmente, añada a la publicación todas las tablas que desee antes de agregarlas al pipe.
Si está replicando desde una réplica de lectura o un hot standby de Postgres, deberá crear su propia publicación en la instancia principal, que se propagará automáticamente al standby. En este caso, ClickPipe no podrá gestionar la publicación, ya que no es posible crear publicaciones en un standby.
Configuración recomendada de max_slot_wal_keep_size
- Como mínimo: Configure
max_slot_wal_keep_size para retener al menos dos días de datos WAL.
- Para bases de datos grandes (alto volumen de transacciones): Retenga al menos entre 2 y 3 veces la generación máxima diaria de WAL.
- Para entornos con almacenamiento limitado: Ajuste este valor de forma conservadora para evitar agotar el espacio en disco y, al mismo tiempo, garantizar la estabilidad de la replicación.
Cómo calcular el valor adecuado
Para PostgreSQL 10+
SELECT pg_wal_lsn_diff(pg_current_wal_insert_lsn(), '0/0') / 1024 / 1024 AS wal_generated_mb;
Para PostgreSQL 9.6 y versiones anteriores:
SELECT pg_xlog_location_diff(pg_current_xlog_insert_location(), '0/0') / 1024 / 1024 AS wal_generated_mb;
- Ejecute la consulta anterior en distintos momentos del día, especialmente durante períodos de alta actividad transaccional.
- Calcule cuánto WAL se genera en cada período de 24 horas.
- Multiplique ese valor por 2 o 3 para garantizar una retención suficiente.
- Establezca
max_slot_wal_keep_size en el valor resultante, en MB o GB.
Ejemplo
Si su base de datos genera 100 GB de WAL al día, configure:
max_slot_wal_keep_size = 200GB
Veo un error EOF de ReceiveMessage en los logs. ¿Qué significa?
ReceiveMessage es una función del protocolo de decodificación lógica de Postgres que lee mensajes del flujo de replicación. Un error EOF (End of File) indica que la conexión al servidor de Postgres se cerró inesperadamente mientras se intentaba leer del flujo de replicación.
Es un error recuperable y totalmente no fatal. ClickPipes intentará volver a conectarse automáticamente y reanudar el proceso de replicación.
Puede ocurrir por varios motivos:
- Problemas de red: Las interrupciones temporales de la red pueden hacer que la conexión se cierre.
- Reinicio del servidor de Postgres: Si el servidor de Postgres se reinicia o falla, la conexión se perderá.
Mi slot de replicación se ha invalidado. ¿Qué debo hacer?
max_slot_wal_keep_size tenga un valor demasiado bajo en tu base de datos PostgreSQL (por ejemplo, unos pocos gigabytes). Recomendamos aumentar este valor. Consulta esta sección sobre cómo ajustar max_slot_wal_keep_size. Lo ideal es establecerlo en al menos 200 GB para evitar que el slot de replicación se invalide.
En casos poco frecuentes, hemos visto que este problema se produce incluso cuando max_slot_wal_keep_size no está configurado. Esto podría deberse a un error complejo y poco común en PostgreSQL, aunque la causa sigue sin estar clara.
Estoy viendo errores de memoria insuficiente (OOM) en ClickHouse mientras mi ClickPipe está realizando la ingestión de datos. ¿Pueden ayudarme?
JOIN potencialmente no optimizados:
-
Una técnica de optimización habitual para los
JOIN se aplica cuando tiene un LEFT JOIN en el que la tabla del lado derecho es muy grande. En ese caso, reescriba la consulta para usar un RIGHT JOIN y mueva la tabla más grande al lado izquierdo. Esto permite que el planificador de consultas sea más eficiente en el uso de la memoria.
-
Otra optimización para los
JOIN consiste en filtrar explícitamente las tablas mediante subqueries o CTEs y, a continuación, realizar el JOIN entre esas subconsultas. Esto proporciona al planificador indicaciones sobre cómo filtrar filas de forma eficiente y ejecutar el JOIN.
Veo un invalid snapshot identifier durante la carga inicial. ¿Qué debo hacer?
invalid snapshot identifier se produce cuando se interrumpe la conexión entre ClickPipes y su base de datos de Postgres. Esto puede ocurrir por timeouts del gateway, reinicios de la base de datos u otros problemas transitorios.
Se recomienda no realizar operaciones disruptivas, como actualizaciones o reinicios, en su base de datos de Postgres mientras la carga inicial esté en curso, y asegurarse de que la conexión de red con la base de datos sea estable.
Para resolver este problema, puede iniciar una resincronización desde la UI de ClickPipes. Esto reiniciará el proceso de carga inicial desde el principio.
¿Qué sucede si elimino una publicación en Postgres?
- Crea una nueva publicación con el mismo nombre y las tablas necesarias en Postgres
- Haz clic en el botón ‘Resync tables’ en la pestaña ‘Settings’ de tu ClickPipe
Esta resincronización es necesaria porque la publicación recreada tendrá un identificador de objeto (OID) distinto en Postgres, aunque tenga el mismo nombre. El proceso de resincronización actualiza tus tablas de destino y restaura la conexión.
Como alternativa, si lo prefieres, puedes crear un pipe completamente nuevo.
Ten en cuenta que, si estás trabajando con tablas particionadas, debes asegurarte de crear tu publicación con la configuración adecuada:
CREATE PUBLICATION clickpipes_publication
FOR TABLE <...>, <...>
WITH (publish_via_partition_root = true);
¿Qué pasa si veo errores como Unexpected Datatype o Cannot parse type XX ...?
Veo errores como invalid memory alloc request size <XXX> durante la creación de la replicación o del slot
pipe si se produce este error.
Necesito mantener un historial completo en ClickHouse, incluso cuando los datos se eliminan de la base de datos Postgres de origen. ¿Puedo ignorar por completo las operaciones DELETE y TRUNCATE de Postgres en ClickPipes?
CREATE PUBLICATION <pub_name> FOR TABLES IN SCHEMA <schema_name> WITH (publish = 'insert,update');
¿Por qué no puedo replicar mi tabla si tiene un punto en el nombre?
La carga inicial se completó, pero no hay datos o faltan datos en ClickHouse. ¿Cuál podría ser el problema?
- Si el usuario tiene permisos suficientes para leer las tablas de origen.
- Si hay políticas de filas del lado de ClickHouse que podrían estar filtrando filas.
¿Puedo hacer que ClickPipe cree un slot de replicación con failover habilitado?
Advanced Settings al crear el ClickPipe. Ten en cuenta que tu versión de Postgres debe ser 17 o superior para usar esta función.
Si el origen está configurado correctamente, el slot se conserva tras un failover a una réplica de lectura de Postgres, lo que garantiza una replicación continua de los datos. Más información aquí.
Veo errores como Internal error encountered during logical decoding of aborted sub-transaction
ReorderBufferPreserveLastSpilledSnapshot, esto indica que la decodificación lógica no puede leer la instantánea volcada a disco. Puede valer la pena probar a aumentar logical_decoding_work_mem a un valor mayor.
Veo errores como error converting new tuple to map o error parsing logical message durante la replicación de CDC
¿Puedo incluir columnas que inicialmente excluí de la replicación?
He notado que mi ClickPipe ha entrado en Snapshot, pero no están llegando datos; ¿cuál podría ser el problema?
La creación de instantáneas en paralelo tarda en obtener las particiones
La creación del slot de replicación está bloqueada por una transacción
CREATE_REPLICATION_SLOT atascada en estado Lock. Esto puede deberse a que otra transacción está reteniendo bloqueos sobre objetos que Postgres utiliza para crear slots de replicación.
Para ver las consultas que están bloqueando, puedes ejecutar la siguiente consulta en tu origen de Postgres:
SELECT
blocked.pid AS blocked_pid,
blocked.query AS blocked_query,
blocking.pid AS blocking_pid,
blocking.query AS blocking_query,
blocking.state AS blocking_state
FROM pg_locks blocked_lock
JOIN pg_stat_activity blocked
ON blocked_lock.pid = blocked.pid
JOIN pg_locks blocking_lock
ON blocking_lock.locktype = blocked_lock.locktype
AND blocking_lock.database IS NOT DISTINCT FROM blocked_lock.database
AND blocking_lock.relation IS NOT DISTINCT FROM blocked_lock.relation
AND blocking_lock.page IS NOT DISTINCT FROM blocked_lock.page
AND blocking_lock.tuple IS NOT DISTINCT FROM blocked_lock.tuple
AND blocking_lock.virtualxid IS NOT DISTINCT FROM blocked_lock.virtualxid
AND blocking_lock.transactionid IS NOT DISTINCT FROM blocked_lock.transactionid
AND blocking_lock.classid IS NOT DISTINCT FROM blocked_lock.classid
AND blocking_lock.objid IS NOT DISTINCT FROM blocked_lock.objid
AND blocking_lock.objsubid IS NOT DISTINCT FROM blocked_lock.objsubid
AND blocking_lock.pid != blocked_lock.pid
JOIN pg_stat_activity blocking
ON blocking_lock.pid = blocking.pid
WHERE NOT blocked_lock.granted;
