O ClickPipe do MySQL oferece suporte ao MariaDB?
O ClickPipe do MySQL é compatível com PlanetScale, Vitess ou TiDB?
Como a replicação é gerenciada?
GTID e FilePos. Diferentemente do Postgres, não há slot para gerenciar o offset. Em vez disso, você deve configurar seu servidor MySQL com um período de retenção do binlog suficiente. Se nosso offset no binlog se tornar inválido (por exemplo, se o mirror ficar pausado por muito tempo ou ocorrer um failover do banco de dados durante o uso da replicação FilePos), será necessário ressincronizar o pipe. Certifique-se de otimizar as visões materializadas que dependem das tabelas de destino, pois consultas ineficientes podem desacelerar a ingestão e fazer com que ela fique atrás do período de retenção.
Também é possível que um banco de dados inativo faça a rotação do arquivo de log sem permitir que o ClickPipes avance para um offset mais recente. Talvez seja necessário configurar uma tabela de heartbeat com atualizações agendadas regularmente.
No início de uma carga inicial, registramos o offset do binlog a partir do qual começar. Esse offset ainda precisa ser válido quando a carga inicial terminar para que o CDC avance. Se você estiver fazendo ingestão de um grande volume de dados, configure um período de retenção do binlog adequado. Ao configurar tabelas, você pode acelerar a carga inicial definindo Use a custom partitioning key for initial load para tabelas grandes nas configurações avançadas, para que possamos carregar uma única tabela em paralelo.
Por que meu pipe falha com um erro de binlog max_allowed_packet?
max_allowed_packet do seu servidor MySQL. Como o servidor não consegue enviar um evento que exceda esse limite, a leitura do fluxo do binlog é abortada e o CDC não consegue avançar.
Na maioria das vezes, isso é causado por linhas com valores grandes de BLOB, TEXT ou JSON. Para resolver:
- Aumente
max_allowed_packetna origem. Defina-o acima do tamanho da sua maior alteração de linha — configurá-lo no valor máximo de1Ggeralmente é seguro:Defina-o também na configuração do seu servidor (por exemplo,my.cnfou o grupo de parâmetros do DB) para que persista após reinicializações. - Se uma única linha for maior que 1G: ressincronize o pipe.
Por que estou recebendo um erro de validação de certificado TLS ao me conectar ao MySQL?
x509: certificate is not valid for any names ou x509: certificate signed by unknown authority. Isso acontece porque o ClickPipes habilita a criptografia TLS por padrão.
Você tem várias opções para resolver esses problemas:
- Defina o campo TLS Host - Quando o hostname da sua conexão for diferente do certificado (algo comum com AWS PrivateLink via Endpoint Service), defina “TLS Host (optional)” para corresponder ao Common Name (CN) ou Subject Alternative Name (SAN) do certificado.
- Faça upload da sua CA raiz - Para servidores MySQL que usam autoridades certificadoras internas ou o Google Cloud SQL na configuração padrão de CA por instância. Para mais informações sobre como acessar certificados do Google Cloud SQL, consulte esta seção.
- Configure o certificado do servidor - Atualize o certificado SSL do seu servidor para incluir todos os hostnames de conexão e usar uma autoridade certificadora confiável.
- Ignore a verificação do certificado - Para MySQL ou MariaDB self-hosted, cujas configurações padrão provisionam um certificado autoassinado que não conseguimos validar (MySQL, MariaDB). Confiar nesse certificado criptografa os dados em trânsito, mas traz o risco de falsificação de identidade do servidor. Recomendamos certificados devidamente assinados para ambientes de produção, mas essa opção é útil para testes em uma instância isolada ou para conexão com infraestrutura legada.