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

Limitações do 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.

Saiba mais sobre as limitações e considerações do conector MySQL.

Limitações gerais do conector de banco de dados​

As limitações desta seção aplicam-se a todos os conectores de banco de dados no LakeFlow Connect. Continue lendo para conhecer as limitações específicas de cada conector.

  • Ao executar um pipeline agendado, os alertas não são acionados imediatamente. Em vez disso, elas são acionadas na próxima execução da atualização.

  • Quando uma tabela de origem é excluída, a tabela de destino não é excluída automaticamente. Você deve excluir a tabela de destino manualmente. Esse comportamento não é consistente com o comportamento do pipeline declarativo LakeFlow Spark .

  • Durante períodos de manutenção da fonte de dados, o Databricks poderá não conseguir acessar seus dados.

  • Se o nome de uma tabela de origem entrar em conflito com o nome de uma tabela de destino existente, a atualização do pipeline falhará.

  • O suporte pipeline com múltiplos destinos é feito exclusivamente via API.

  • Opcionalmente, você pode renomear uma tabela que você importa. Se você renomear uma tabela em seu pipeline, ele se tornará um pipeline somente para API e você não poderá mais editá- pipeline na interface do usuário.

  • O sistema de origem pressupõe que as colunas do cursor estejam em ordem crescente monotônica.

  • Com o SCD tipo 1 ativado, as exclusões não produzem um evento delete explícito no feed de dados de alteração. Para exclusões auditáveis, use o tipo SCD 2 se o conector o suportar. Para obter detalhes, consulte o exemplo: Processamento de SCD tipo 1 e SCD tipo 2 com dados de origem CDF.

Versões e variações do MySQL​

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

  • 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 (somente instância primária para configurações de alta disponibilidade)
  • 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 posterior, Versão 8.0 e posterior
  • MySQL no EC2 : Versão 5.7.44 e posteriores

O conector não é compatível com MariaDB ou outros bancos de dados compatíveis com MySQL.

Autenticação​

  • O conector suporta autenticação por nome de usuário e senha com os seguintes plugins de autenticação:

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

  • O botão Testar Conexão na interface do usuário pode falhar para usuários que usam sha256_password ou caching_sha2_password, mesmo quando as credenciais estão corretas. Este é um problema conhecido. Você ainda pode criar a conexão e prosseguir com a configuração do pipeline.

Requisitos de log binário​

  • O registro binário deve ser ativado com binlog_format=ROW e binlog_row_image=FULL.
  • Se o binlog for apagado antes que o gateway processe as alterações, você deverá executar uma refresh completa de todas as tabelas no pipeline.
  • A Databricks recomenda a retenção de binlogs por 7 dias. Definir um valor inferior pode fazer com que os binlogs sejam limpos antes que o gateway de ingestão os reproduza.

Leia o suporte à réplica​

  • O suporte a réplicas de leitura está disponível apenas para Amazon RDS para MySQL, Banco de Dados do Azure para MySQL e MySQL no EC2.
  • O conector não suporta a ingestão de dados de réplicas de leitura do Aurora MySQL. Você precisa se conectar à instância primária do Aurora (endpoint de gravação).
  • Ao usar réplicas de leitura, o atraso na replicação pode afetar a atualização dos dados.

oleoduto​

  • Cada pipeline de ingestão deve estar associado a exatamente um gateway de ingestão.
  • Embora o pipeline de ingestão seja executado em compute serverless , o gateway de ingestão deve ser executado em compute clássica.
  • O gateway de ingestão executa continuamente para capturar as alterações antes que os binlogs possam ser truncados ou eliminados.

evolução do esquema e operações DDL​

O conector lida automaticamente com colunas novas e excluídas.

  • Quando uma nova coluna não espacial aparece na fonte de dados, o Databricks a ingere automaticamente na próxima execução do pipeline.
  • Colunas de tipo de dados espaciais não são suportadas e não podem ser importadas.
  • Quando uma coluna é excluída da fonte de dados, o Databricks não a exclui automaticamente. Em vez disso, o conector usa uma propriedade da tabela para definir a coluna excluída como inactive no destino. Se outra coluna aparecer posteriormente com um nome conflitante com a coluna inactive , o pipeline falhará. Nesse caso, você pode executar uma refresh completa da tabela ou remover manualmente a coluna inativa.

Isso é válido tanto para tabelas novas quanto para tabelas excluídas dentro de um esquema, caso você esteja importando o esquema inteiro.

Manipulação de operações DDL​

O conector consegue lidar com algumas operações DDL, mas muitas exigem uma refresh completa da tabela:

  • TRUNCATE TABLE : Você precisa refresh a tabela.

  • RENOMEAR TABELA : A tabela renomeada é ignorada no gateway de ingestão, com um erro registrado no log de eventos. O fluxo para esta tabela foi marcado como falho no pipeline de ingestão.

  • DROP TABLE : A tabela foi removida do gateway de ingestão, com um erro registrado no log de eventos. O fluxo para esta tabela foi marcado como falho no pipeline de ingestão.

  • ADICIONAR chave PRIMÁRIA ou restrição UNIQUE : Você precisa refresh a tabela.

  • DROP PRIMARY key constraint : Você precisa refresh a tabela.

  • DROP UNIQUE constraint : Se esta for a única restrição de unicidade na tabela de origem, você deve refresh a tabela. Caso contrário, nenhuma ação é necessária.

  • EXCLUIR COLUNA / MODIFICAR COLUNA / ALTERAR COLUNA : Você precisa refresh a tabela.

  • ADICIONAR COLUNA :

    • Se a coluna for de um tipo não espacial: Nenhuma ação é necessária. A coluna é automaticamente incluída na próxima atualização do pipeline.
    • Se a coluna tiver um tipo espacial: Adicionar a coluna interrompe a ingestão adicional dessa tabela. A tabela é ignorada no gateway de ingestão, com um erro registrado no log de eventos. O fluxo para esta tabela foi marcado como falho no pipeline de ingestão.

  • ADICIONAR TABELA (ao ingerir o esquema completo):

    • Se a tabela não tiver tipos espaciais: Nenhuma ação é necessária. A tabela é automaticamente incluída na próxima atualização do pipeline.
    • Se a tabela contiver tipos espaciais: a tabela será ignorada no gateway de ingestão, resultando em um erro no log de eventos. O fluxo para esta tabela foi marcado como falho no pipeline de ingestão.

Quando realizar uma refreshcompleta​

Execute uma refresh completa de uma tabela nos seguintes cenários:

  • Após TRUNCATE TABLE operações na fonte.
  • Após uma alteração no tipo de dados da coluna (MODIFY COLUMN).
  • Após uma renomeação de coluna (CHANGE COLUMN).
  • Após DROP COLUMN operações (para remover colunas inativas).
  • Quando colunas espaciais são adicionadas (antes de removê-las da seleção).

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

Encenação​

O catálogo de encenação não pode ser um catálogo estrangeiro.

Tabelas e tipos de dados​

  • A Databricks recomenda a ingestão de 250 tabelas ou menos por pipeline. No entanto, não há limite para o número de linhas ou colunas que são suportadas nesses objetos.
  • MySQL é um namespace de dois níveis. Os nomes source_schema e source_table diferenciam maiúsculas de minúsculas.
  • Embora seja possível ingerir dados de vários esquemas de origem em um único pipeline, não é possível ingerir duas tabelas com o mesmo nome no mesmo esquema de destino. Por exemplo, você não pode ingerir schema1.customers e schema2.customers no mesmo esquema de destino. No entanto, você pode ingeri-los em diferentes esquemas de destino usando um pipeline de múltiplos destinos.
  • Os tipos de dados espaciais (GEOMETRY, POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION) não são suportados. Se colunas espaciais estiverem presentes nas tabelas selecionadas, a tabela será ignorada no gateway de ingestão, com um erro registrado no log de eventos.

Conjuntos de caracteres e ordenação​

O conector atualmente replica apenas sequências de bytes compatíveis com UTF-8. Isso significa que a replicação funciona corretamente quando a representação em bytes armazenada no MySQL corresponde à codificação UTF-8.

Conjuntos de caracteres suportados​

Os seguintes conjuntos de caracteres MySQL são total ou parcialmente suportados:

  • Totalmente compatível (os bytes sempre correspondem ao UTF-8):

    • utf8
    • utf8mb4
    • ascii

  • Suporte parcial (somente intervalo ASCII):

    • latin1 - A maioria dos dados do mundo real armazenados como latin1 são compatíveis com ASCII e funcionam corretamente. MySQL 5.7.44 usa latin1 como conjunto de caracteres default .

  • Conjuntos de caracteres padrão por versão :

    • MySQL 5.7.44: latin1 (default)
    • MySQL 8.0 e posterior: utf8mb4 (default)

Limitações de conjunto de caracteres​

  • O conector não converte entre conjuntos de caracteres. Ele transfere bytes brutos e espera que eles representem UTF-8 válido.
  • Caracteres não compatíveis com UTF-8 em conjuntos de caracteres não suportados podem aparecer ilegíveis ou incorretos no destino.
  • Para dados não ASCII em conjuntos de caracteres diferentes dos listados acima, considere converter suas tabelas para utf8mb4 antes da ingestão.

Problemas conhecidos​

  • O botão Testar Conexão falha para usuários MySQL com autenticação sha256_password ou caching_sha2_password , mesmo quando as credenciais são válidas. Essa é uma limitação conhecida. Você ainda pode criar conexões e pipelines.