Pular para o conteúdo principal
Última atualização em

Perguntas frequentes sobre o conector MySQL

info

Visualização

O conector MySQL está em versão prévia pública. Entre em contato com a equipe da sua account Databricks para solicitar acesso.

Encontre respostas para perguntas frequentes sobre o conector MySQL.

Quais versões e plataformas do MySQL são suportadas?​

O conector MySQL é compatível com as seguintes versões e plataformas:

  • Amazon RDS para MySQL : Versão 5.7.44 e posterior (tanto para implantações independentes quanto de alta disponibilidade)
  • Amazon Aurora MySQL : Versão 5.7.mysql_aurora.2.12.2 e posterior (para configurações de alta disponibilidade, o suporte é apenas para a instância primária)
  • Amazon Aurora MySQL sem servidor : Compatível
  • Banco de Dados do Azure para Servidores Flexíveis MySQL : Versão 5.7.44 e posterior (implantações autônomas e de alta disponibilidade)
  • Google Cloud SQL para MySQL : versão 5.7.44 e posteriores
  • MySQL no EC2 : Versão 5.7.44 e posteriores

Quais métodos de autenticação são suportados?​

O conector MySQL suporta os seguintes plugins de autenticação, dependendo da sua versão do MySQL:

  • MySQL 5.7.44 : Apenas sha256_password é suportado. O usuário de replicação deve ser criado usando este plugin de autenticação.
  • MySQL 8.0 e posterior : Ambos sha256_password e caching_sha2_password são suportados.

O conector suporta replicação baseada em GTID?​

Não, o conector MySQL não suporta replicação baseada em GTID (Identificador Global de Transação). O conector utiliza replicação binlog baseada em posição.

Você ainda pode usar o conector se o GTID estiver habilitado no seu servidor MySQL, mas o conector usa um arquivo binlog e replicação baseada em posição independentemente disso.

As transações XA são suportadas?​

Não, o conector MySQL não suporta transações XA (transações distribuídas). Se uma transação XA for executada, a tabela será ignorada no pipeline.

Posso importar tabelas com tipos de dados espaciais?​

Não, os tipos de dados espaciais (GEOMETRY, POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION) não são suportados.

Se uma tabela contiver colunas espaciais, você deverá excluir a tabela inteira da ingestão. As tabelas com tipos espaciais são ignoradas quando detectadas ou quando uma nova coluna com tipos espaciais é adicionada.

Posso criar vários pipelines com a mesma tabela de destino?​

Não, uma tabela de destino pode ser gerenciada por apenas um pipeline de ingestão. Não é possível criar dois pipelines de ingestão de gerenciamento diferentes com tabelas de destino sobrepostas.

Posso importar tabelas com o mesmo nome de esquemas diferentes?​

Não, não é possível ingerir duas tabelas com o mesmo nome no mesmo pipeline, mesmo que elas venham de esquemas de origem diferentes. Por exemplo, você não pode ingerir schema1.customers e schema2.customers em um mesmo pipeline.

Para contornar esse problema, consulte Criar pipeline com vários destinos.

Como faço para rotacionar as credenciais do MySQL?​

Para rotacionar as credenciais de uma conexão existente:

  1. Atualizar a senha no MySQL
  2. No Databricks, acesse o Explorador de Catálogo.
  3. Navegue até a conexão
  4. Clique em Editar e atualize a senha.
  5. Salvar as alterações

O gateway de ingestão e o pipeline usarão automaticamente as novas credenciais na próxima execução.

Os nomes de tabelas e colunas diferenciam maiúsculas de minúsculas?​

Sim, os nomes de tabelas e esquemas do MySQL diferenciam maiúsculas de minúsculas no conector MySQL. Os nomes de esquema e tabela do MySQL diferenciam maiúsculas de minúsculas, enquanto os nomes de catálogo, esquema e tabela do Unity Catalog não diferenciam. Se houver um conflito devido a maiúsculas e minúsculas (por exemplo, mytable vs MyTable), use a funcionalidade de múltiplos destinos para resolver os conflitos.

Para obter detalhes, consulte a seção "Diferenciação entre maiúsculas e minúsculas de identificadores" na documentação do MySQL.

Qual escala foi testada para o conector MySQL ?​

O conector foi testado em 100 tabelas em um único pipeline com um volume total de dados de Snapshot inferior a 1 TB.

Recomendações de tipo de máquina para o gateway de ingestão:

Os tipos de máquina default são os seguintes:

  • AWS: r5n.xlarge
  • AZUL: Standard_E4d_v4
  • GCP: n2-highmem-4

Considere usar r5n.2xlarge, Standard_E8d_v4 ou n2-highmem-8 para um melhor desempenho do Snapshot.

limites do oleoduto:

  • A Databricks recomenda 250 tabelas ou menos por pipeline.
  • Limite máximo: 1.000 fluxos por pipeline (o que efetivamente suporta até 500 tabelas).

Observação: Embora o limite máximo seja de 500 tabelas, a Databricks recomenda 250 ou menos para um desempenho ideal.

O gateway de ingestão suporta execução em modo acionado?​

Não, o pipeline do gateway de ingestão não suporta o modo acionado e deve ser executado continuamente para evitar a necessidade de atualização completa devido à limpeza log .

O pipeline de ingestão (não o gateway) pode ser executado por um programador ou ser acionado, mas o gateway deve permanecer em execução continuamente.

Quando devo realizar uma refresh completa?​

Execute uma refresh completa nos seguintes cenários:

  • Quando um fluxo de tabela é marcado como falho no pipeline de ingestão.
  • Quando uma alteração de esquema incompatível causa falha no fluxo da tabela.
  • Quando os arquivos binlog são limpos antes que o gateway de ingestão os reproduza.
  • Quando você precisa ressincronizar uma tabela manualmente.

Para realizar uma refresh completa, consulte refresh completamente as tabelas de destino.

O que devo fazer se os arquivos binlog forem limpos antes que o gateway de ingestão os reproduza?​

Se os arquivos binlog forem apagados antes de serem processados pelo gateway de ingestão:

  1. O gateway de ingestão detectará esse evento e ignorará todas as tabelas afetadas.
  2. Cada tabela ignorada terá logs de eventos DLT apropriados indicando o problema.
  3. Você deve acionar uma refresh completa para todas as tabelas afetadas no pipeline

Para evitar que isso aconteça:

  • Configure um período de retenção de binlog adequado (recomenda-se 7 dias).
  • Garanta que o gateway de ingestão esteja em execução contínua.

O conector é compatível com implantações MySQL on-premises ?​

Sim, as implementações MySQL on-premises são suportadas quando conectadas a um workspace Databricks por meio de:

  • Azure ExpressRoute
  • Conexão direta da AWS
  • Conexão VPN

Assegure-se de que:

  • Há largura de banda de rede suficiente disponível para a transferência de dados.
  • A conectividade de rede é estável e confiável.
  • As regras do firewall permitem tráfego na porta MySQL (default 3306).
  • A retenção de binlogs está configurada corretamente.

Para mais informações, entre em contato com a equipe de suporte Databricks .