FAQ sobre migrações do ClickHouse Managed Postgres

Perguntas frequentes sobre migração de dados para o ClickHouse Managed Postgres.

Muitas dúvidas sobre como funciona a replicação do Postgres — incluindo colunas TOAST, slots de replicação, publicações, alterações de esquema e mapeamentos de tipos de dados — são abordadas no FAQ do ClickPipes for Postgres. As informações de lá também se aplicam às migrações do ClickHouse Managed Postgres.

​

Estou vendo um erro de “valor de entrada inválido para enum” durante a replicação

Esse erro ocorre quando o Postgres de origem tem um valor de enum que não existe no ClickHouse Managed Postgres de destino. A replicação lógica não propaga automaticamente os comandos ALTER TYPE ... ADD VALUE, então novos valores de enum adicionados na origem após a configuração inicial do esquema farão com que as inserções falhem no destino.

Para corrigir isso, adicione o valor ausente ao tipo enum no Postgres de destino:

ALTER TYPE your_enum_type ADD VALUE 'new_value';

Substitua your_enum_type pelo nome do seu tipo Enum e 'new_value' pelo valor ausente na mensagem de erro.

​

Estou recebendo um erro de violação de restrição de unicidade ou de verificação durante a replicação

Violações de restrição podem ocorrer durante a replicação lógica quando a ordem de replicação entra em conflito com uma restrição existente no destino.

• Restrições de unicidade: Aplicamos as alterações como operações MERGE/UPSERT em lote que gravam o valor mais recente para cada chave primária. Portanto, a ordem das operações para uma determinada chave pode não corresponder à ordem esperada pelo índice único. Isso pode violar temporariamente uma restrição UNIQUE durante a transação, embora a restrição seja atendida após a conclusão do MERGE. O Postgres não pode adiar verificações de índice único da mesma forma que adia verificações de chave estrangeira; portanto, não é possível postergar a verificação até o fim da transação. Isso não afeta a consistência dos dados: a identidade da linha é definida pela chave primária, e a lógica do MERGE usa essa mesma chave primária.
• Restrições de verificação: Uma restrição de verificação no destino pode ser mais rigorosa do que na origem, ou um estado intermediário durante um MERGE em lote pode não atender à restrição, mesmo que o estado final a atenda. Assim como ocorre com as restrições de unicidade, isso não afeta a consistência dos dados, pois o MERGE usa a chave primária que define a identidade da linha.

Para desbloquear a replicação, remova a restrição problemática do 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;

Você pode encontrar os detalhes da restrição usando o nome indicado na mensagem de erro:

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

Adicione novamente as restrições durante a migração, após a conclusão da replicação e quando a origem não estiver mais ativa:

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);