Sobre Snowflake Connector for MySQL

Nota

O Snowflake Connector for MySQL está sujeito aos Termos do conector.

O Snowflake Connector for MySQL permite:

  • Carregar dados no Snowflake a partir de um banco de dados MySQL.

  • Configure a replicação para que as alterações em seu banco de dados MySQL sejam replicadas para o Snowflake.

Para manipular conexões entre Snowflake e MySQL, o conector usa um agente. O agente é distribuído como uma imagem Docker. O agente é executado em sua rede e é usado para enviar por push dados para sua conta Snowflake.

Nota

O Snowflake Connector for MySQL requer que exatamente uma instância do aplicativo agente esteja em execução o tempo todo.

As atualizações incrementais em andamento usam a técnica de captura de dados de alteração (CDC) que obtém as alterações realizadas no banco de dados de origem. As alterações incluem operações INSERT, UPDATE e DELETE, que são replicadas automaticamente no banco de dados de destino Snowflake.

Várias instâncias de aplicativos

É possível instalar várias instâncias Snowflake Connector for MySQL em sua conta Snowflake. Para obter mais informações, consulte Opcional: Instalação de múltiplas instâncias de Snowflake Connector for MySQL.

Compatibilidades com os aplicativos do Agent e conector

O Snowflake Connector for MySQL está sendo lançado em uma versão específica, descrita como versão x.y.z, onde x é a versão principal, y é a secundária e z é a patch. Os Agents no dockerhub também são lançados com a versão X.Y.Z. Cada versão x.y.z do Snowflake Connector for MySQL oferece suporte a todos os agentes com a mesma versão principal X=x e não a uma versão secundária maior do agente. Além disso, cada versão x.0.0 do Snowflake Connector for MySQL oferece suporte a todas as versões (x-1).Y.Z do agente para todas as versões Y e Z.

Limitações conhecidas

As seções a seguir descrevem as limitações conhecidas do conector.

Número máximo de tabelas

O conector funciona bem com até 200 tabelas de origem adicionadas à replicação. Adicionar mais tabelas pode fazer com que o conector fique instável.

Tamanho da transação

O conector está sujeito às mesmas limitações que a replicação do grupo MySQL. Isso significa que uma única transação deve caber em uma mensagem de log binário de no máximo 4GB. Transações que excederem esse tamanho farão com que a tabela de origem seja marcada como falha permanente e exigirão um recarregamento instantâneo completo da tabela associada.

Disponibilidade do conector

Ao instalar o conector, observe as seguintes limitações:

  • As contas nas regiões governamentais não são suportadas.

  • Para instalar e configurar o conector, você deve estar conectado como um usuário com a função ACCOUNTADMIN. Outras funções não são suportadas neste momento.

Compatibilidade de tipos

Devido às diferenças entre o banco de dados de origem e os tipos de coluna Snowflake, alguns valores não podem ser convertidos e gravados no Snowflake devido à capacidade máxima da coluna ou aos intervalos permitidos. Por exemplo:

  • O tipo Snowflake BINARY tem um comprimento máximo de 8 MB (8.388.608 bytes)

  • Os tipos de data em Snowflake, como DATE, DATETIME e TIMESTAMP, têm um ano máximo de 9999

  • O tipo Snowflake VARCHAR tem um comprimento máximo de 16 MB (16.777.216 bytes)

Se tal incompatibilidade ocorrer, a replicação de uma tabela será interrompida com uma falha.

Alterações no esquema de tabela de origem

A tabela a seguir mostra diferentes tipos de alterações no esquema de tabela de origem, se elas são compatíveis e, em caso afirmativo, como.

Novos nomes de coluna estão sujeitos às mesmas limitações descritas na seção Limitações de identificadores.

Tipo de alteração de esquema

Tem suporte?

Notas

Adicionando uma nova coluna

Sim

A nova coluna ficará visível na tabela de destino como qualquer outra coluna existente no início da replicação.

Não é possível adicionar uma nova coluna com o mesmo nome de uma coluna excluída ou renomeada anteriormente.

Por exemplo, se as colunas A e B existiam inicialmente, mas A foi excluída e B foi renomeada para B2 – não é possível adicionar uma coluna nomeada A ou B.

Excluindo uma coluna existente

Sim

Se uma coluna for excluída na tabela de origem, ela não será excluída na tabela de destino. Em vez disso, uma abordagem de exclusão suave é seguida e a coluna será renomeada para <o nome anterior>__SNOWFLAKE_DELETED para que os valores históricos ainda possam ser consultados. Todas as linhas replicadas após a exclusão da coluna terão um valor NULL nesta coluna.

Por exemplo, se a coluna A for excluída, ela será renomeada para A__SNOWFLAKE_DELETED na tabela de destino, e o conteúdo da coluna permanecerá inalterado.

Como renomear uma coluna

Sim

Renomear uma coluna é o mesmo que excluir a coluna e criar uma nova com o novo nome. A exclusão segue a abordagem de exclusão suave explicada na linha anterior.

Por exemplo, se a coluna A foi renomeada para B, na tabela de destino, A foi renomeada para A__SNOWFLAKE_DELETED, e uma nova coluna B foi adicionada. Todas as linhas existentes antes da alteração mantêm os valores da coluna na coluna A__SNOWFLAKE_DELETED, enquanto as novas linhas adicionadas após a alteração mantêm os valores na coluna B.

Não é possível renomear uma coluna com o mesmo nome de uma coluna excluída ou renomeada anteriormente. Por exemplo, se as colunas A, B e C existiam inicialmente, mas A foi excluída e B foi renomeada para B2, não é possível renomear a coluna C para A ou B.

Alterando o tipo de coluna

Parcialmente

Alterar o tipo de coluna da tabela de origem só é possível se o tipo anterior e o novo forem mapeados para o mesmo tipo no Snowflake.

Em qualquer outro caso, a replicação falhará permanentemente.

Alteração da precisão de uma coluna numérica

Não

Alterar a precisão de uma coluna da tabela de origem resultará em falha permanente na replicação.

Alteração da escala de uma coluna numérica

Não

Alterar a escala de uma coluna da tabela de origem resultará em falha permanente na replicação.

Alterando a definição da chave primária

Não

Alterar a definição da chave primária da coluna da tabela de origem resultará na falha permanente da replicação.

Colunas de alta capacidade

Um agente ativo lê continuamente todos os eventos do log binário, mesmo que alguns eventos se refiram a tabelas de origem que não foram adicionadas para replicação. Se o log binário contiver eventos muito grandes, como atualizações de colunas do tipo BLOB, o agente poderá travar devido à falta de memória disponível.

Chaves primárias

Tabelas sem chaves primárias não são compatíveis.

Limitações dos identificadores

Atualmente, o conector não oferece suporte ao caractere " em nomes de esquema, tabela ou coluna replicados. Além disso, as seguintes palavras-chave não são compatíveis:

Para nomes de esquema:

  • INFORMATION_SCHEMA

Para nomes de coluna:

versão do MySQL >= 8.0.0

Atualmente, o conector depende da propriedade de configuração binlog_row_metadata = full que foi introduzida na versão 8 do MySQL.

Autorização do banco de dados de origem

A autorização de chave privada para o banco de dados de origem não é compatível. Somente autorização via usuário e senha é compatível.

Linguagem: Português