Transmita dados de bases de dados MySQL

Esta secção contém informações sobre:

  • O comportamento da forma como o Datastream processa os dados extraídos de uma base de dados MySQL de origem
  • As versões da base de dados MySQL que o Datastream suporta
  • Limitações conhecidas da utilização da base de dados MySQL como origem
  • Uma vista geral de como configurar uma base de dados MySQL de origem para que os dados possam ser transmitidos a partir da mesma para um destino

Comportamento

Esta secção descreve o comportamento das origens do MySQL quando replica dados com o Datastream. Quando carrega dados de bases de dados MySQL, pode usar a replicação baseada em binlog ou a replicação baseada no identificador de transação global (GTID). Seleciona o método de CDC quando cria uma stream.

Replicação baseada em binlogs

A stream de dados pode usar ficheiros de registo binário para manter um registo das alterações de dados nas bases de dados do MySQL. As informações contidas nestes ficheiros de registo são replicadas para o destino para reproduzir as alterações feitas na origem.

As principais caraterísticas da replicação baseada em binlog no Datastream são:

  • Pode selecionar todas as bases de dados ou bases de dados específicas de uma determinada origem MySQL, bem como todas as tabelas das bases de dados ou tabelas específicas.
  • Todos os dados do histórico são replicados.
  • Todas as alterações da linguagem de manipulação de dados (DML), como inserções, atualizações e eliminações das bases de dados e tabelas especificadas, são replicadas.
  • Apenas as alterações confirmadas são replicadas.

Replicação baseada no identificador de transação global (GTID)

O Datastream também suporta a replicação baseada no identificador global (GTID).

O identificador global de transação (GTID) é um identificador exclusivo criado e associado a cada transação confirmada numa origem do MySQL. Este identificador é único não só para a origem em que foi criado, mas também em todos os servidores numa determinada topologia de replicação, ao contrário da replicação baseada em registos binários, em que cada nó no cluster da base de dados mantém os seus próprios ficheiros binlog, com a sua própria numeração. A manutenção de ficheiros binlog separados e a numeração podem tornar-se um problema em caso de falha ou tempo de inatividade planeado, porque a continuidade do binlog é interrompida e a replicação baseada no binlog falha.

A replicação baseada em GTID suporta failovers, clusters de bases de dados autogeridos e continua a funcionar independentemente das alterações no cluster de base de dados.

As principais caraterísticas da replicação baseada em GTID no Datastream são:

  • Pode selecionar todas as bases de dados ou bases de dados específicas de uma determinada origem MySQL, bem como todas as tabelas das bases de dados ou tabelas específicas.
  • Todos os dados do histórico são replicados.
  • Todas as alterações da linguagem de manipulação de dados (DML), como inserções, atualizações e eliminações das bases de dados e tabelas especificadas, são replicadas.
  • Apenas as alterações confirmadas são replicadas.
  • Apoio técnico totalmente integrado para comutações por falha.

Mude da replicação baseada em binlog para a replicação baseada em GTID

Se quiser atualizar a sua stream e mudar da replicação baseada em binlogs para a replicação baseada em GTIDs sem ter de fazer um preenchimento, siga estes passos:

  1. Certifique-se de que todos os requisitos para a replicação baseada em GTID são cumpridos. Para mais informações, consulte o artigo Configure uma base de dados MySQL de origem.
  2. Opcionalmente, crie e execute uma stream baseada no GTID de teste. Para mais informações, consulte Crie uma stream.
  3. Crie uma stream baseada em GTID. Não o inicie já.
  4. Pare o tráfego de aplicações para a base de dados de origem.
  5. Pause a stream existente baseada em binlogs. Para mais informações, consulte o artigo Pause a stream.
  6. Aguarde alguns minutos para garantir que o fluxo de dados alcançou a base de dados. Pode verificar esta situação através das métricas no separador Monitorização, na página Detalhes da stream da sua stream. Os valores de Atualidade dos dados e Débito têm de ser 0.
  7. Inicie a stream baseada em GTID. Para mais informações, consulte o artigo Inicie a stream.
  8. Retome o tráfego para a base de dados de origem.

Se a realização de um preenchimento não for um problema, pode truncar as tabelas no BigQuery, eliminar a stream antiga e iniciar uma nova com o preenchimento. Para mais informações sobre a gestão do preenchimento, consulte o artigo Faça a gestão do preenchimento para os objetos de uma stream.

Versões

O Datastream suporta as seguintes versões da base de dados MySQL:

  • MySQL 5.6
  • MySQL 5.7
  • MySQL 8.0

  • MySQL 8.4 (suportado apenas para replicação baseada em GTID)

O Datastream suporta os seguintes tipos de base de dados MySQL:

Limitações conhecidas

As limitações conhecidas da utilização da base de dados MySQL como origem incluem:

  • Os streams estão limitados a 10 000 tabelas.
  • Não é possível preencher tabelas que tenham uma chave primária definida como INVISIBLE.
  • Não é possível preencher previamente uma tabela com mais de 500 milhões de linhas, a menos que sejam cumpridas as seguintes condições:
    1. A tabela tem um índice exclusivo.
    2. Nenhuma das colunas do índice é anulável.
    3. O índice não está descendente.
    4. Todas as colunas do índice estão incluídas no fluxo.
  • A stream de dados obtém periodicamente o esquema mais recente da origem à medida que os eventos são processados. Se um esquema for alterado, o Datastream deteta a alteração do esquema e aciona uma obtenção do esquema. No entanto, alguns eventos podem ser processados incorretamente ou podem ser ignorados entre as obtenções do esquema, o que pode causar discrepâncias nos dados.
  • Nem todas as alterações ao esquema de origem podem ser detetadas automaticamente, caso em que pode ocorrer corrupção de dados. As seguintes alterações ao esquema podem causar corrupção de dados ou falha no processamento dos eventos a jusante:
    • Remover colunas
    • Adicionar colunas ao meio de uma tabela
    • Alterar o tipo de dados de uma coluna
    • Reordenar colunas
    • Eliminar tabelas (relevante se a mesma tabela for recriada com novos dados adicionados)
    • Truncar tabelas
  • O fluxo de dados não suporta a replicação de vistas.
  • O fluxo de dados não suporta colunas de tipos de dados espaciais. Os valores nestas colunas são substituídos por valores NULL.
  • O fluxo de dados não suporta o valor zero (0000-00-00 00:00:00) nas colunas dos tipos de dados DATETIME, DATE ou TIMESTAMP. O valor zero é substituído pelo valor NULL.
  • O fluxo de dados não suporta a replicação de linhas que incluem os seguintes valores nas colunas JSON: DECIMAL, NEWDECIMAL, TIME, TIME2 DATETIME, DATETIME2, DATE, TIMESTAMP ou TIMESTAMP2. Os eventos que contêm esses valores são rejeitados.
  • O fluxo de dados não suporta a compressão de transações de registo binário.
  • O Datastream não suporta cadeias de certificados SSL nos perfis de ligação do MySQL de origem. Apenas são suportados certificados únicos codificados em PEM x509.
  • O fluxo de dados não suporta eliminações em cascata. Estes eventos não são escritos no registo binário e, como resultado, não são propagados para o destino.
  • O fluxo de dados não suporta operações DROP PARTITION. Essas operações são apenas operações de metadados e não são replicadas. Os outros eventos não são afetados e a stream é executada com êxito.
  • Pode ter problemas de conetividade ao replicar tabelas FEDERATED. Se isso acontecer, remova todas as tabelas FEDERATED da configuração da base de dados de origem e aumente os valores dos parâmetros connect_timeout, net_read_timeout e max_allowed_packet para mitigar os problemas de tempo limite durante o preenchimento.
  • As instâncias do Cloud SQL Enterprise Plus têm de usar a replicação baseada em GTID porque estão sujeitas a manutenção com tempo de inatividade quase nulo. A replicação baseada em registos binários falha em casos de failover. Por isso, recomendamos a utilização da replicação baseada em GTID para exemplos de utilização de alta disponibilidade.

Limitações adicionais para a replicação baseada em GTID

  • A recuperação de streams que usam a replicação baseada em GTID só está disponível quando usa a API Datastream.
  • A criação de tabelas a partir de outras tabelas através das declarações CREATE TABLE ... SELECT não é suportada.
  • O fluxo de dados não suporta GTIDs etiquetados.
  • Para ver as restrições do MySQL aplicáveis à replicação baseada em GTID, consulte a documentação do MySQL.

O que se segue?