FAQ sobre migraciones de ClickHouse Managed Postgres

Preguntas frecuentes sobre la migración de datos a ClickHouse Managed Postgres.

Muchas preguntas sobre cómo funciona la replicación de Postgres —incluidas las columnas TOAST, los slots de replicación, las publicaciones, los cambios de esquema y los mapeos de tipos— se abordan en las FAQ de ClickPipes for Postgres. La información allí también aplica a las migraciones de ClickHouse Managed Postgres.

​

Veo un error de “invalid input value for enum” durante la replicación

Este error se produce cuando el Postgres de origen tiene un valor enum que no existe en el ClickHouse Managed Postgres de destino. La replicación lógica no propaga automáticamente los comandos ALTER TYPE ... ADD VALUE, por lo que los nuevos valores enum añadidos en el origen después de la configuración inicial del esquema harán que las inserciones fallen en el destino.

Para solucionarlo, añade el valor que falta al tipo enum en el Postgres de destino:

ALTER TYPE your_enum_type ADD VALUE 'new_value';

Sustituya your_enum_type por el nombre de su tipo enum y 'new_value' por el valor que falta en el mensaje de error.

​

Se produce un error de violación de una restricción de unicidad o de comprobación durante la replicación

Pueden producirse violaciones de restricciones durante la replicación lógica cuando el orden de replicación entra en conflicto con una restricción existente en el destino.

• Restricciones de unicidad: Aplicamos los cambios como operaciones MERGE/UPSERT por lotes que escriben el valor más reciente para cada clave primaria, por lo que el orden de las operaciones para una clave determinada puede no coincidir con el orden que espera el índice único. Esto puede infringir temporalmente una restricción UNIQUE dentro de la transacción, aunque la restricción se cumpla una vez finalizado el MERGE. Postgres no puede diferir las comprobaciones de índices únicos como sí puede hacerlo con las claves foráneas, por lo que no es posible posponer la comprobación hasta el final de la transacción. Esto no afecta a la consistencia de los datos: la identidad de la fila se define mediante la clave primaria y la lógica de MERGE usa esa misma clave primaria.
• Restricciones de comprobación: Una restricción de comprobación en el destino puede ser más estricta que en el origen, o un estado intermedio durante un MERGE por lotes puede no cumplir la restricción, aunque el estado final sí la cumpla. Al igual que con las restricciones de unicidad, esto no afecta a la consistencia de los datos, ya que el MERGE usa la clave primaria que define la identidad de la fila.

Para desbloquear la replicación, elimine la restricción problemática en el Postgres de destino:

-- Drop a unique constraint
ALTER TABLE your_table DROP CONSTRAINT your_constraint_name;

-- Drop a check constraint
ALTER TABLE your_table DROP CONSTRAINT your_check_constraint_name;

Puedes consultar los detalles de la restricción usando el nombre indicado en el mensaje de error:

SELECT conname, conrelid::regclass, contype
FROM pg_constraint
WHERE conname = 'your_constraint_name';

Vuelva a agregar las restricciones durante la transición, una vez completada la replicación y cuando el origen ya no esté activo:

ALTER TABLE your_table ADD CONSTRAINT your_constraint_name UNIQUE (column1, column2);
ALTER TABLE your_table ADD CONSTRAINT your_check_constraint_name CHECK (column1 > 0);