Início / dba / Perguntas / 281289
Accepted
ParoX
Asked: 2020-12-11 09:53:17 +0800 CST

Posso desabilitar binlogs para economizar espaço temporariamente

  • 772

Estou usando percona mysql 8.

Não uso nenhum tipo de replicação, mas li que os logs binários são úteis para recuperação de dados. Eu gostaria de desligar o binlogging e liberá-los enquanto corro pt-online-schema-changepara fazer a tabela OPTIMIZE sem impacto.

Depois disso, quero ativar o binlogging novamente (e, em seguida, fazer esforços para mover para um servidor com mais espaço).

Isso é seguro e recomendado? Eu preciso otimizar uma tabela e não posso ficar offline e fazer uma cópia da tabela me deixará sem espaço, a menos que eu remova os 50 GB de binlogs

mysql percona

3 respostas

  1. Best Answer

    O que você precisa fazer é definir sql_log_bincomo 0 ao iniciar o pt-online-schema-change usando set-vars

    pt-online-schema-change --set-vars sql_log_bin=0

    Seus logs binários nunca saberão a diferença.

    Verifique se há espaço suficiente para a tabela temporária ( _tablename_new).

    ATUALIZAÇÃO 2020-12-10 14:45 EST

    Se você não estiver fazendo backups neste servidor, poderá executar

    PURGE BINARY LOGS BEFORE CURDATE() - INTERVAL 5 DAY;

    para manter os últimos 5 dias de logs binários ou se você quiser que todos os logs binários desapareçam, execute

    RESET MASTER;

    AVISO !!!

    Antes de fazer isso, descubra se o servidor está executando a replicação como mestre.

    ATUALIZAÇÃO 2020-12-10 16:05 EST

    Como você está executando pt-online-schema-change, você deve executá-lo assim

    pt-online-schema-change --set-vars sql_log_bin=0 --alter "ENGINE=InnoDB"

    Isso apenas criará uma tabela temporária desfragmentada. Acontece que --analyze-before-swap é o valor padrão. Isso significa que a tabela temporária foi ANALYZE TABLEexecutada antes de trocar as tabelas antigas e novas. Isso tem exatamente o mesmo efeito que OPTIMIZE TABLEem uma tabela InnoDB.

    Conforme mencionado no comentário do nbk , você deve ter certeza de ter backups. Você também faria muito bem a si mesmo configurando a replicação e fazendo os backups do escravo.

    • 3

  2. A resposta curta é NÃO, não é seguro e não é recomendado.

    Entendo que esses logs não estão sendo usados ​​para replicação, mas para recuperação de dados. Estes são úteis para fazer a recuperação "point in time". No entanto, você precisa ter um backup completo anterior válido para que os logs binários sejam úteis.

    Minhas recomendações:

    1. Faça um backup completo [usando mysqldump ou qualquer outra forma] para seu(s) banco(s) de dados
    2. Esvazie os logs [e marque o tempo]
    3. Copie os arquivos de logs binários para um local seguro [backup deles]
    4. Limpe os logs binários antes do horário marcado
    5. Execute suas instruções de otimização. Durante esse período, os logs binários ainda serão gravados, mas o tamanho será mínimo

    HTH

    • 0

  3. Ao excluir muitas linhas de uma tabela grande, é muito mais eficiente fazer isso

    CREATE TABLE new LIKE real;
INSERT INTO new
    SELECT ... (the rows to keep);  -- the slow part
RENAME TABLE real TO old,
             new TO real;    -- fast, atomic
DROP TABLE old;

    Se a tabela original foi construída com innodb_file_per_table=ON, então o espaço livre será devolvido ao SO por este processo; não precisa OPTIMIZE.

    O INSERT..SELECTé muito mais rápido (por linha) do que DELETE.

    Se você estiver excluindo dados "antigos" e precisar fazer a limpeza novamente, considere o particionamento.

    Mais detalhes sobre essas e outras técnicas de exclusão: http://mysql.rjweb.org/doc.php/deletebig

    O espaço no log binário --

    • DELETEcom binlog_format = ROW: uma entrada por linha excluída.
    • DELETEcom STATEMENT: uma entrada para a instrução inteira.
    • INSERT: uma entrada por linha.
    • OPTIMIZE: (eu acho) uma entrada para a declaração inteira.

    Ou seja, DELETEé isso que está inchando o log binário. O OPTIMIZEestá travando a mesa por um longo tempo.

    • 0

relate perguntas