Fazer streaming de dados de bancos de dados MySQL

O Datastream permite replicar dados históricos e mudanças em andamento de um banco de dados MySQL de origem para o destino para análise em tempo real e sincronização de banco de dados.

Antes de configurar uma origem do MySQL, analise o comportamento de replicação, as versões e os tipos de banco de dados compatíveis, as práticas recomendadas e as limitações conhecidas no Datastream.

Comportamento

Nesta seção, descrevemos o comportamento das origens do MySQL quando você replica dados usando o Datastream. Ao ingerir dados de bancos de dados MySQL, é possível usar a replicação baseada em binlog ou a replicação baseada em identificador de transação global (GTID, na sigla em inglês). Selecione o método de CDC ao criar um stream.

Replicação baseada em binlog

O Datastream pode usar arquivos de registro binário para manter um registro das alterações de dados em bancos de dados MySQL. As informações contidas nesses arquivos de registro são replicadas para o destino para reproduzir as alterações feitas na origem.

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

  • É possível selecionar todos os bancos de dados ou bancos de dados específicos de uma determinada origem do MySQL, bem como todas as tabelas dos bancos de dados ou tabelas específicas.
  • Todos os dados históricos são replicados.
  • Todas as alterações da linguagem de manipulação de dados (DML), como inserções, atualizações e exclusões dos bancos de dados e tabelas especificados, são replicadas.
  • Apenas alterações confirmadas são replicadas.

Replicação baseada em identificador de transação global (GTID, na sigla em inglês)

O Datastream também é compatível com a replicação baseada em identificador global (GTID, na sigla em inglês).

O identificador de transação global (GTID, na sigla em inglês) é um identificador exclusivo criado e associado a cada transação confirmada em uma origem do MySQL. Esse identificador é exclusivo não apenas para a origem em que foi originado, mas também em todos os servidores em uma determinada topologia de replicação, em oposição à replicação baseada em registro binário, em que cada nó no cluster de banco de dados mantém os próprios arquivos binlog, com a própria numeração. Manter arquivos e numeração de binlog separados pode se tornar um problema em caso de falha ou inatividade planejada, porque a continuidade do binlog é interrompida e a falha na replicação baseada em binlog.

A replicação baseada em GTID é compatível com failovers, clusters de banco de dados autogerenciados e continua funcionando independentemente das mudanças no cluster de banco de dados.

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

  • É possível selecionar todos os bancos de dados ou bancos de dados específicos de uma determinada origem do MySQL, bem como todas as tabelas dos bancos de dados ou tabelas específicas.
  • Todos os dados históricos são replicados.
  • Todas as alterações da linguagem de manipulação de dados (DML), como inserções, atualizações e exclusões dos bancos de dados e tabelas especificados, são replicadas.
  • Apenas alterações confirmadas são replicadas.
  • Suporte integrado para failovers.

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

Se você quiser atualizar seu stream e mudar da replicação baseada em binlog para a baseada em GTID sem precisar fazer um preenchimento, siga estas etapas:

  1. Verifique se todos os requisitos para a replicação baseada em GTID foram atendidos. Para mais informações, consulte Configurar um banco de dados MySQL de origem.
  2. Se quiser, crie e execute um stream de teste baseado em GTID. Para mais informações, consulte Criar um stream.
  3. Criar um stream baseado em GTID. Não comece ainda.
  4. Interrompa o tráfego do aplicativo para o banco de dados de origem.
  5. Pause o stream atual baseado em binlog. Para mais informações, consulte Pausar o stream.
  6. Aguarde alguns minutos para garantir que o Datastream tenha alcançado o banco de dados. Para verificar isso, use as métricas na guia Monitoramento, na página Detalhes do stream. Os valores de Atualização de dados e Capacidade de processamento precisam ser 0.
  7. Inicie o stream baseado em GTID. Para mais informações, consulte Iniciar a transmissão.
  8. Retome o tráfego para o banco de dados de origem.

Se o preenchimento não for um problema, será possível truncar as tabelas no BigQuery, excluir o stream antigo e iniciar um novo com o preenchimento. Para mais informações sobre como gerenciar o preenchimento, consulte Gerenciar o preenchimento para os objetos de um stream.

Versões

O Datastream é compatível com as seguintes versões do banco de dados MySQL:

  • MySQL 5.6
  • MySQL 5.7
  • MySQL 8.0

  • MySQL 8.4 (compatível apenas com replicação baseada em GTID)

O Datastream é compatível com os seguintes tipos de banco de dados do MySQL:

Práticas recomendadas

Nesta seção, descrevemos as práticas recomendadas para configurar sua origem do MySQL para uso com o Datastream.

Usar o GTID para configurações de alta disponibilidade

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

O arquivo binlog e a replicação baseada em posição podem ser interrompidos durante um failover de banco de dados, porque, quando o principal falha, o novo principal tem um histórico de binlog diferente. Nesse caso, o Datastream perde a posição e não pode ser retomado.

O GTID atribui um ID exclusivo a cada transação em toda a topologia de replicação (primária e réplicas). Após um failover, o Datastream pode ser retomado do último GTID registrado no novo primário, sem precisar saber o arquivo binlog ou a posição.

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

Dimensionar corretamente a réplica de leitura

Se você configurar o Datastream para replicar de uma réplica de leitura, poderá encontrar um atraso duplo, que é uma combinação do atraso de replicação do MySQL (da instância principal para a réplica) e do atraso de replicação do Datastream (da réplica para o destino). As réplicas de leitura geralmente são provisionadas com menos recursos (CPU, RAM, IOPS) do que as primárias para economizar custos, o que pode fazer com que elas fiquem atrás da primária durante períodos de alta gravação.

Recomendação:ao usar uma réplica de leitura como origem para o Datastream, provisione-a com recursos comparáveis aos da instância principal para que a réplica possa acompanhar a capacidade de gravação da instância principal.

Aumentar a capacidade de processamento do método CDC de binlog

Se você estiver usando a replicação baseada em binlog e tiver alta latência devido a grandes volumes de gravação de origem que geram arquivos binlog mais rápido do que uma única tarefa pode processar, aumente a capacidade de processamento ajustando o parâmetro maxConcurrentCdcTasks. Esse parâmetro controla o número de tarefas de CDC que um stream executa em paralelo. Aumentar o valor desse parâmetro permite que o Datastream processe mais arquivos binlog simultaneamente.

Recomendação:para determinar o valor adequado para a atualização de dados, monitore a taxa de geração de binlog do servidor MySQL durante os horários de pico. Para isso, observe a taxa em que novos arquivos binlog são criados e alternados no diretório de dados do MySQL ou use ferramentas de monitoramento do MySQL para acompanhar o crescimento dos registros binários. Por exemplo, se a origem gerar 10 arquivos binlog por minuto durante os horários de pico, definir maxConcurrentCdcTasks como um valor como 10-15 permite que o Datastream processe esses arquivos em paralelo, evitando um backlog.

É possível aumentar maxConcurrentCdcTasks até o valor máximo compatível de 50, desde que a carga no banco de dados de origem permaneça sob controle. Para mais informações, consulte Controles de simultaneidade de stream.

Dimensionar corretamente o parâmetro max_allowed_packet

A configuração padrão de max_allowed_packet no MySQL (por exemplo, 16 MB a 64 MB) pode ser muito pequena. Se uma única linha com campos grandes do tipo BLOB, JSON ou TEXT ou uma única transação grande exceder esse tamanho, o MySQL vai encerrar a conexão do Datastream, fazendo com que o stream 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 servidor MySQL com o valor máximo permitido de 1G. Isso garante que o servidor possa processar qualquer linha ou transação grande que o Datastream precise ler do binlog.

Limitações conhecidas

Limitações conhecidas para o uso do banco de dados MySQL como fonte incluem:

  • Os streams são limitados a 10.000 tabelas.
  • As tabelas replicadas precisam usar o mecanismo de armazenamento InnoDB. As tabelas que usam o mecanismo de armazenamento MyISAM não são compatíveis e falham na validação do stream.
  • Tabelas que têm uma chave primária definida como INVISIBLE não podem ser preenchidas.
  • Uma tabela com mais de 500 milhões de linhas não pode ser preenchida, a menos que as seguintes condições sejam atendidas:
    1. A tabela tem um índice exclusivo.
    2. Nenhuma das colunas do índice é anulável.
    3. O índice não é descendente.
    4. Todas as colunas do índice são incluídas no stream.
  • O Datastream busca periodicamente o esquema mais recente da origem à medida que os eventos são processados. Se um esquema mudar, o Datastream vai detectar a mudança e acionar uma busca de esquema. No entanto, alguns eventos podem ser processados incorretamente ou descartados entre as buscas de esquema, o que pode causar discrepâncias de dados.
  • Nem todas as alterações no esquema de origem podem ser detectadas automaticamente. Nesse caso, pode ocorrer corrupção de dados. As seguintes alterações de esquema podem causar corrupção de dados ou falha no processamento de eventos downstream:
    • Como descartar colunas
    • Como adicionar colunas no meio de uma tabela
    • Como alterar o tipo de dados de uma coluna
    • Como reorganizar as colunas
    • Como descartar tabelas (relevantes se a mesma tabela for recriada com novos dados adicionados)
    • Truncando tabelas
  • O Datastream não é compatível com a replicação de visualizações.
  • O Datastream não é compatível com colunas de tipos de dados espaciais, por exemplo, GEOMETRY, POINT, LINESTRING, POLYGON. Os valores nessas colunas são substituídos por valores NULL.
  • O Datastream não é compatível com 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 Datastream não é compatível com 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 descartados.
  • O Datastream não oferece suporte à compactação de transações de registro binário.
  • O Datastream não é compatível com arquivos de registro binário maiores que 4 GiB. Como o MySQL grava cada transação em um único arquivo de registro binário, mantenha as transações individuais abaixo de 4 GiB para que os arquivos de registro binário não excedam esse limite.
  • O Datastream não é compatível com cadeias de certificados SSL nos perfis de conexão de origem do MySQL. Somente certificados x509 codificados em PEM são aceitos.
  • O Datastream não é compatível com operações em cascata: ON UPDATE CASCADE e ON DELETE CASCADE. Esses eventos não são gravados no registro binário e, como resultado, não são propagados para o destino. Como alternativa, é possível substituir as operações em cascata por gatilhos de banco de dados.
  • O Datastream não é compatível com operações DROP PARTITION. Essas operações são apenas de metadados e não são replicadas. Os outros eventos não são afetados, e o stream é executado sem problemas.
  • Talvez você tenha problemas de conectividade ao replicar tabelas do FEDERATED. Se isso acontecer, remova todas as tabelas FEDERATED da configuração do banco de dados de origem e aumente os valores dos parâmetros connect_timeout, net_read_timeout e max_allowed_packet para reduzir os problemas de tempo limite durante o preenchimento.
  • As instâncias do Cloud SQL Enterprise Plus precisam usar a replicação baseada em GTID porque estão sujeitas à manutenção com tempo de inatividade quase zero. A replicação baseada em registros binários é interrompida em failovers. Por isso, recomendamos o uso da replicação baseada em GTID para casos de uso de alta disponibilidade.
  • Para as versões 8.0 e mais recentes do MySQL, a variável binlog_row_value_options precisa ser definida como um valor vazio. Esse é o padrão para a maioria das versões, mas para algumas, como origens do MySQL na Oracle Cloud Infrastructure (OCI), é necessário defini-lo explicitamente. Para mais informações, consulte Configurar um banco de dados MySQL autogerenciado.
  • Limitações do MariaDB:
    • A replicação baseada em GTID não é compatível com o MariaDB. É preciso configurar os streams do MariaDB para usar a replicação baseada em binlog.
    • Para as versões 11.4 a 12.2 do MariaDB, é necessário ativar a variável de sistema binlog_legacy_event_pos no banco de dados de origem para garantir a compatibilidade com o Datastream.
    • O Datastream não é compatível com o tipo de dados UUID (introduzido no MariaDB 10.7). É necessário excluir as colunas do tipo de dados UUID da configuração do stream.

Outras limitações para a replicação baseada em GTID

  • A recuperação de streams que usam a replicação baseada em GTID só está disponível ao usar a API Datastream.
  • Não é possível criar tabelas usando outras tabelas com as instruções CREATE TABLE ... SELECT.
  • O Datastream não é compatível com GTIDs marcados.
  • Para ver as restrições do MySQL que se aplicam à replicação baseada em GTID, consulte a documentação do MySQL.

A seguir