Início / dba / Perguntas / 320418
Accepted
Niyaz
Asked: 2022-12-01 13:05:07 +0800 CST

Como gerenciar o binlog no MySQL?

  • 772

Tenho um banco de dados com três tabelas grandes, possui as seguintes especialidades:

  1. Três tabelas com cerca de 15 milhões de inserções por hora para cada tabela.
  2. Sem atualização.
  3. Selecione a consulta rapidamente com a ajuda de Indexinge Partition.
  4. Só mantenho os dados por 14 dias, eu uso PARTITION . Cada partição por um dia. Eu crio um novo Partitionàs 23h50 (antes do início do novo dia) e excluo a partição de 15 dias atrás. (Rápido e preciso)
  5. Eu faço backup do conjunto de dados todos os dias, por um dia. (somente dados de ontem)

Eu monitorei meu log binário por nove dias, o tamanho do log aumentou drasticamente. O problema é: em algum momento, o binlog ocupa todo o meu espaço em disco. Minhas perguntas são:

  1. No meu caso, preciso de binlog? (Se o benefício for apenas replicação, não preciso disso agora)
  2. Qual é a melhor maneira de gerenciar o binlog? (Se eu mantiver)
  3. Existe alguma relação entre Partitione binlog? (Se eu desabilitar)

O comando que executa, tabela e configuração do MySQL é mostrado abaixo.

du -ch /var/lib/mysql/binlog.* | tail -n 1

innodb_file_per_table
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G
innodb_buffer_pool_size=4G
Data Tamanho total em GB
2022-11-22 289 GB
2022-11-23 300 GB
2022-11-24 311 GB
2022-11-25 322 GB
2022-11-26 334 GB
2022-11-27 364 GB
2022-11-28 378 GB
2022-11-29 417 GB
30/11/2022 437 GB
mysql

1 respostas

  1. Best Answer

    Existem vários usos do log binário:

    • Replicação, como você sabe.
    • Recuperação pontual. Se você precisar restaurar a partir de um backup recente, usar o log binário de alterações desde esse backup pode trazer sua restauração para a alteração mais recente (desde que você ainda tenha os logs binários). Consulte https://dev.mysql.com/doc/refman/8.0/en/point-in-time-recovery-binlog.html
    • Alimentando ferramentas de captura de dados alterados (um exemplo de código aberto é o Debezium ), para que você possa transmitir o MySQL para um data warehouse ou outro destino.
    • Às vezes, investigando alterações suspeitas nos dados. Isso é de uso limitado, porque o log binário registra carimbos de data/hora, mas não nomes de usuário. Um log de auditoria seria melhor, mas muitas vezes estive em ambientes onde a gerência não acha que precisa de um log de auditoria, mas então algo acontece e eles querem que alguma alteração de dados seja investigada.

    Se um ou mais desses usos se aplica ao seu caso, você deve manter seu log binário. Você não forneceu informações suficientes para que eu saiba disso.

    O log binário se acumula e cresce cada vez mais, a menos que você expire alguns ou todos os arquivos. Você pode fazer isso manualmente com PURGE BINARY LOGS (isso não permitirá que você remova o último log binário, porque esse arquivo de log está sendo gravado no momento).

    • No MySQL 8.0, os logs binários também expiram automaticamente após 30 dias por padrão, ou você pode configurá-los para um período de tempo diferente (consulte binlog_expire_logs_seconds ).

    • No MySQL 5.x, você pode opcionalmente configurar a expiração automática de logs binários, mas o padrão é reter todos os logs binários para sempre (consulte expire_logs_days ).

    Observe que a expiração significa que, quando o log binário rola para abrir um novo arquivo, ele verifica os arquivos mais antigos e, se forem mais antigos do que a janela de tempo de expiração, eles são removidos. Lembre-se que isso não acontece até que o log abra um novo arquivo. Ao usar o MySQL 5.x, isso pode levar a situações em que os arquivos não expiram enquanto você está fazendo uma grande importação/exportação de dados, porque a granularidade da idade do arquivo é em dias. Em outras palavras, se sua expiração for para logs com mais de 1 dia, mas você preencher 500 GB de dados em um dia, poderá acumular 500 arquivos binlog e nenhum deles tiver mais de 1 dia, portanto, eles não expiram ainda . Fico feliz que tenham mudado a granularidade para 1 segundo no MySQL 8.0.

    Não há nenhuma relação especial entre o particionamento e os logs binários. O log binário registra todas as alterações DML e DDL (embora seja possível para uma determinada sessão suprimir as gravações no log binário).

    DDL é sempre gravado no log binário no formato de instrução. Não há como ALTER TABLE ocupar mais espaço no log binário dependendo do tamanho da tabela. Portanto, se seu log binário está aumentando muito, é por causa do DML (INSERT/UPDATE/DELETE). Sua DROP PARTITION diária não é responsável.

    • 1

relate perguntas