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. Este comportamento não é consistente com o comportamento dos LakeFlow Pipelines.

  • 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.

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

  • O gerenciamento de pipelines de ingestão não é compatível com espaços de trabalho em regiões AWS GovCloud (FedRAMP High).

  • O pipeline de ingestão gerencia não é compatível com o espaço de trabalho FedRAMP Moderate nas regiões us-east-2 ou us-west-1 .

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. Os gateways não podem ser compartilhados entre diferentes pipelines.
  • 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.
  • Não reconecte um pipeline de ingestão a uma réplica ou nó de origem diferente. O checkpointing é local para o nó de origem inicial. Alternar para uma réplica ou nó diferente requer um refresh completo de todas as tabelas no pipeline.

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 decodifica as colunas de caracteres (tipos CHAR, VARCHAR e TEXT) usando o conjunto de caracteres MySQL de cada coluna e grava os valores no destino como UTF-8.

Conjuntos de caracteres sem suporte​

O conector é compatível com todos os conjuntos de caracteres do MySQL, exceto os seguintes:

armscii8, dec8, geostd8, hp8, keybcs2 e swe7.

Se uma tabela selecionada tiver uma coluna de caracteres que use um conjunto de caracteres sem suporte, o gateway de ingestão ignorará a tabela e registrará um erro de INGESTION_GATEWAY_TABLE_SKIPPED_DUE_TO_UNSUPPORTED_CHARSET no log de eventos. As outras tabelas no pipeline continuarão a fazer a ingestão. Para ingerir a tabela, converta as colunas afetadas para um conjunto de caracteres compatível, como utf8mb4.

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.
Nesta página