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 binlogs 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 global da transação (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 binlogs para a replicação baseada em GTIDs

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 no GTID. Para mais informações, consulte a secção Inicie a stream.
  8. Retome o tráfego para a base de dados de origem.

Se não houver problema em fazer um preenchimento, 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:

Práticas recomendadas

Esta secção descreve as práticas recomendadas para configurar a sua origem MySQL para utilização com o Datastream.

Use o GTID para configurações de alta disponibilidade

Se a sua origem MySQL de produção usar réplicas ou qualquer outra configuração de alta disponibilidade, use a replicação baseada em GTID.

A replicação baseada na posição e no ficheiro binlog pode falhar durante uma comutação por falha da base de dados porque, quando a base de dados principal falha, a nova base de dados principal tem um histórico de binlog diferente. Nesse caso, a stream de dados perde a respetiva posição e não pode ser retomada.

O GTID atribui um ID exclusivo a cada transação em toda a sua topologia de replicação (principal e réplicas). Após uma comutação por falha, o fluxo de dados pode ser retomado a partir do último GTID registado no novo servidor principal, sem precisar de saber o ficheiro binlog nem a posição.

Recomendação: para qualquer origem MySQL de produção com uma réplica ou uma configuração de alta disponibilidade, a utilização do método CDC GTID é obrigatória para uma replicação de dados resiliente e fiável.

Dimensionar corretamente a réplica de leitura

Se configurar o Datastream para replicar a partir de uma réplica de leitura, pode encontrar um atraso duplo, que é uma combinação do atraso de replicação do MySQL (da origem à réplica) e do atraso de replicação do Datastream (da réplica ao destino). As réplicas de leitura são frequentemente aprovisionadas com menos recursos (CPU, RAM, IOPS) do que as principais para poupar custos, o que pode fazer com que fiquem atrás da principal durante períodos de escrita elevada.

Recomendação: quando usar uma réplica de leitura como origem para o Datastream, disponibilize-lhe recursos comparáveis aos da réplica principal, para que a réplica possa manter-se a par do débito de gravação da réplica principal.

Aumente a taxa de transferência para o método de CDC binlog

Se estiver a usar a replicação baseada em binlog e tiver uma latência elevada devido a grandes volumes de escrita de origem que geram ficheiros binlog mais rapidamente do que uma única tarefa consegue processar, aumente a taxa de transferência ajustando o parâmetro maxConcurrentCdcTasks. Este parâmetro controla o número de tarefas de CDC que uma stream executa em paralelo. Aumentar o valor deste parâmetro permite que o Datastream processe mais ficheiros binlog em simultâneo.

Recomendação: para determinar o valor adequado para a atualização dos dados, monitorize a taxa de geração do registo binário do servidor MySQL durante as horas de pico. Pode fazê-lo observando a taxa à qual os novos ficheiros binlog são criados e rodados no diretório de dados do MySQL ou usando ferramentas de monitorização do MySQL para acompanhar o crescimento dos registos binários. Por exemplo, se a sua origem gerar 10 ficheiros binlog por minuto durante as horas de ponta, definir maxConcurrentCdcTasks para um valor como 10-15 permite que o Datastream processe estes ficheiros em paralelo, evitando um atraso.

Pode aumentar maxConcurrentCdcTasks até ao valor máximo suportado de 50, desde que a carga na base de dados de origem permaneça sob controlo. Para mais informações, consulte o artigo Controlos de concorrência de streams.

Dimensionar corretamente o parâmetro max_allowed_packet

A predefinição max_allowed_packet no MySQL (por exemplo, 16 MB a 64 MB) pode ser demasiado pequena. Se uma única linha com campos do tipo BLOB, JSON ou TEXT, ou uma única transação grande exceder este tamanho, o MySQL termina a ligação do fluxo de dados, o que faz com que o fluxo falhe com erros como Packet for query is too large ou Got a packet bigger than 'max_allowed_packet' bytes.

Recomendação: defina o parâmetro max_allowed_packet no seu servidor MySQL para o valor máximo permitido de 1 G. Isto garante que o servidor consegue processar qualquer linha ou transação grande que o Datastream precise de ler do binlog.

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 único.
    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 comutação por falha. Por isso, recomendamos a utilização da replicação baseada em GTID para exemplos de utilização de alta disponibilidade.
  • Para as versões 8.0 e posteriores do MySQL, a variável binlog_row_value_options tem de ser definida com um valor vazio. Esta é a predefinição para a maioria das versões, mas para algumas, por exemplo, origens MySQL na Oracle Cloud Infrastructure (OCI), tem de a definir explicitamente. Para mais informações, consulte o artigo Configure uma base de dados MySQL autogerida.

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 que se aplicam à replicação baseada em GTID, consulte a documentação do MySQL.

O que se segue?