Banco de dados MySQL de origem

Essa seção contém informações sobre:

  • O comportamento de como o Datastream lida com dados que estão sendo extraídos de um banco de dados MySQL de origem
  • As versões do banco de dados MySQL compatível com o Datastream
  • Limitações conhecidas para o uso do banco de dados MySQL como fonte
  • Uma visão geral de como configurar um banco de dados MySQL de origem para que os dados possam ser transmitidos dele para um destino

Comportamento

Esta seção descreve o comportamento das origens do MySQL ao replicar dados usando o Datastream. Ao ingerir dados de bancos de dados do MySQL, é possível usar a replicação baseada em binário ou a replicação baseada em identificador global de transação (GTID, na sigla em inglês) (pré-lançamento). Você seleciona 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 mudanças de dados nos bancos de dados MySQL. As informações contidas nesses arquivos de registro são replicadas no destino para reproduzir as mudanças feitas na origem.

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

  • É possível selecionar todos os bancos de dados ou bancos de dados específicos de uma determinada origem MySQL, bem como todas as tabelas dos bancos de dados ou tabelas específicas.
  • Todos os dados históricos são replicados.
  • Todas as mudanças na 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 global de transação (GTID, na sigla em inglês)

O Datastream também oferece suporte à 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 é único não apenas para a origem em que foi originado, mas também para todos os servidores em uma determinada topologia de replicação, em vez da 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 binários e numeração separados pode se tornar um problema em caso de falha ou inatividade planejada, porque a continuidade do binário é interrompida e a replicação baseada em binário falha.

A replicação baseada em GTID oferece suporte a 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 MySQL, bem como todas as tabelas dos bancos de dados ou tabelas específicas.
  • Todos os dados históricos são replicados.
  • Todas as mudanças na 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 perfeito para failovers.

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 a replicação baseada em GTID)

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

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.
  • 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 só pode ser preenchida se as seguintes condições forem atendidas:
    1. A tabela tem um índice exclusivo.
    2. Nenhuma das colunas do índice é anulável.
    3. O índice não é decrescente.
    4. Todas as colunas do índice são incluídas no fluxo.
  • 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 alteração 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. 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 oferece suporte à 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 oferece suporte a cadeias de certificados SSL nos perfis de conexão do MySQL de origem. Somente certificados x509 codificados em PEM são aceitos.
  • O Datastream não oferece suporte a exclusões em cascata. Esses eventos não são gravados no registro binário e, como resultado, não são propagados para o destino.
  • Ao usar a replicação com base em registros binários, o Datastream não oferece suporte a failovers para réplicas. Por isso, não recomendamos o uso do Datastream para a replicação de origens do Cloud SQL para MySQL Enterprise Plus. As instâncias do Cloud SQL Enterprise Plus estão sujeitas a manutenção com tempo de inatividade quase zero e falha de failover para uma réplica durante a manutenção. Isso interrompe a continuidade do binlog e, como resultado, os fluxos afetados falham permanentemente.

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

  • A recuperação de fluxo não é compatível com a replicação baseada em GTID.
  • Não é possível criar tabelas usando outras tabelas com as instruções CREATE TABLE ... SELECT.
  • Para restrições do MySQL que se aplicam à replicação baseada em GTID, consulte a documentação do MySQL.

A seguir