AnalyticDB:Subscribe to binary logs with DTS

Pré-requisitos

• O cluster do AnalyticDB for MySQL deve ser uma das seguintes edições: Enterprise Edition, Basic Edition, Data Lakehouse Edition ou Data Warehouse Edition (in elastic mode).

• O cluster do AnalyticDB for MySQL deve atender aos seguintes requisitos de versão do kernel:

  • Mecanismo de tabela xuanwu_v1: 3.2.1.0 ou posterior.

  • Mecanismo de tabela xuanwu_v2: 3.2.6.0 ou posterior.

  • Para assinar binary logs de visualizações materializadas incrementais, a versão do kernel deve ser 3.2.6.9, 3.2.7.1 ou posterior.

  Nota

  Para visualize e atualize the minor version, acesse a seção Configuration Information na página Cluster Information no console do AnalyticDB for MySQL.

• O Change Data Capture (CDC) está ativado no cluster do AnalyticDB for MySQL.

  Nota

  O Change Data Capture (CDC) captura alterações de dados para dar suporte à sincronização e à migração incremental. Para ativar o CDC ou verificar seu status, entre em contato com o suporte técnico.

Procedimento

1. Faça login no console do AnalyticDB for MySQL. No canto superior esquerdo do console, selecione uma região. No painel de navegação à esquerda, clique em Clusters. Localize o cluster desejado e clique no respectivo ID.

2. Ative o registro de binary log. Este exemplo usa uma tabela chamada source_table.

   Nota

   O AnalyticDB for MySQL permite ativar o registro de binary log apenas no nível da tabela.

   Ao criar uma tabela

   CREATE TABLE source_table (
     `id` INT,
     `num` BIGINT,
     PRIMARY KEY (`id`)
   )DISTRIBUTED BY HASH (id) BINLOG=true;

   Para uma tabela existente

   ALTER TABLE source_table BINLOG=true;

3. (Opcional) Modifique o período de retenção do binary log.

   Altere o parâmetro binlog_ttl para ajustar o período de retenção do binary log. O valor padrão é 6 horas. Por exemplo, defina o período de retenção do binary log da tabela source_table como 1 dia.

   ALTER TABLE source_table binlog_ttl='1d';

   O parâmetro binlog_ttl aceita os seguintes formatos:

   • Milissegundos: valor numérico. Exemplo: 60 representa 60 milissegundos.

   • Segundos: número + s. Exemplo: 30s representa 30 segundos.

   • Horas: número seguido de h. Exemplo: 2h representa 2 horas.

   • Dias: número seguido de d. Exemplo: 1d representa 1 dia.

   Nota

   • O período máximo de retenção do binary log é de 365 dias para clusters com as seguintes versões de kernel ou posteriores em suas respectivas séries: 3.2.1.9, 3.2.2.14, 3.2.3.8, 3.2.4.4 e 3.2.5.1. Para clusters com versões anteriores, o limite é de 21 dias.

   • Recomendamos definir o período de retenção do binary log com um valor igual ou superior ao padrão do parâmetro binlog_ttl. Períodos muito curtos podem causar a remoção de arquivos e afetar a sincronização de dados.

   • Para visualizar o período atual de retenção do binary log, execute SHOW CREATE TABLE source_table;.

4. Assine os binary logs com o DTS.

   O DTS assina os binary logs para habilitar a data synchronization e a incremental migration entre clusters do AnalyticDB for MySQL.

5. (Opcional) Visualize as informações do binary log.

   Nota

   As instruções a seguir retornam 0 se o registro de binary log estiver ativado, mas a assinatura via DTS ainda não tiver sido feita. As informações do binary log aparecem somente após o estabelecimento de uma assinatura bem-sucedida.

   • Para obter o nome do arquivo e a posição da entrada mais recente do binary log, execute a seguinte instrução SQL:

     SHOW MASTER STATUS FOR source_table;

   • Para visualizar todos os arquivos de binary log não removidos e seus tamanhos, execute a seguinte instrução SQL:

     SHOW BINARY LOGS FOR source_table;

Impacto no desempenho ao ativar o registro de binary log

Após a ativação do registro de binary log, o AnalyticDB for MySQL registra logs adicionais de alteração de dados, o que gera os seguintes impactos no cluster:

• Sobrecarga de cpu: tabelas com registro de binary log ativado consomem mais cpu durante operações INSERT, UPDATE e DELETE. Em cargas de trabalho típicas, o aumento geralmente não excede 10%, mas em cenários extremos de gravação com alta concorrência, pode chegar a aproximadamente 40%. Recomendamos ativar o registro de binary log fora dos horários de pico ou avaliar o impacto primeiro em um banco de dados de teste.

• Sobrecarga de armazenamento: os arquivos de binary log crescem conforme o volume de alterações de dados e consomem espaço em disco. O uso de armazenamento é proporcional ao período de retenção definido em binlog_ttl. Defina um período adequado com base nos requisitos reais de sincronização para evitar consumo desnecessário de armazenamento por arquivos expirados.

• Desempenho de consulta: a ativação do registro de binary log não afeta o desempenho das consultas.

Perguntas frequentes

O AnalyticDB for MySQL oferece suporte ao monitoramento de binary log?

Sim. O AnalyticDB for MySQL oferece suporte ao monitoramento de binary log no nível da tabela. Ative o registro de binary log para uma tabela específica e use o DTS ou aplicativos personalizados para assinar eventos de alteração de dados dessa tabela. Não há suporte para registro de binary log no nível da instância. Não é possível usar uma única assinatura para capturar logs de alterações de todas as tabelas em uma instância. Para monitorar binary logs de várias tabelas, ative o registro e crie uma assinatura separadamente para cada tabela.