Início / dba / Perguntas / 59494
Accepted
ethrbunny
Asked: 2014-02-24 14:57:12 +0800 CST

Problemas com mysqldump após atualização 5.5 -> 5.6

  • 772

Alguns meses atrás, atualizei uma configuração do MySQL de 5.5 para 5.6. Desde então, tenho tido problemas com um script que uso para despejar os vários bancos de dados para poder fazer backup deles.

O script é um pequeno pedaço de perl que obtém uma lista de todos os bancos de dados e, em seguida, chama mysqldumpcada um da seguinte maneira:

mysqldump -udb_account -pdb_pw -hserver.com --single-transaction --flush-logs 
   --routines --triggers --quick $fn 2> $fn.err | gzip > $fn.mysql.gz

Problema: muitos desses bancos de dados têm centenas de tabelas (sempre aumentando). Para esses dbs maiores, o mysqldumpcomando geralmente sai após apenas uma única tabela. Se eu executar o comando de uma sessão de terminal, ele será executado corretamente. (normalmente é executado como um cron job 1x/wk)

O .errarquivo não contém mensagens. Nem o server.errarquivo no diretório raiz do MySQL.

Nota: este script estava funcionando bem no MySQL 5.5 por vários anos. Esse problema começou a acontecer quando atualizei para 5.6.

Além disso: a --flush-logsporção não está funcionando. A pasta mysql_bin nunca foi esvaziada desde que este sistema foi colocado online.

Uma variável que ainda não controlei: quando executado como um trabalho CRON, o script bifurca 3 processos por vez. Quando testo o comando em uma sessão de período, estou fazendo apenas um de cada vez.

Sistema em questão:

  • CentOS 6.4
  • x64
  • RAM de 64 GB
mysql mysql-5.6

1 respostas

  1. Best Answer

    O problema aqui é apenas um mal-entendido

    Usar --flush-logs com mysqldump simplesmente fecha e abre todos os manipuladores de arquivos contra o seguinte:

    No caso de logs binários, o log binário atual é fechado e um novo log binário é aberto. Em essência, é o único arquivo de log que é rotacionado numericamente. Por exemplo, suponha que você execute SHOW MASTER STATUS;e veja os nomes dos arquivos de log binários mysql-bin.000027. Executando FLUSH LOGS;ou FLUSH BINARY LOGS;fecharia mysql-bin.000027(o que para de registrar as transações nesse arquivo) e aberto mysql-bin.000028(que agora registra as transações recebidas).

    No entanto, a rotação não implica exclusão automática.

    Existem duas maneiras de limpar os logs binários

    APAGAR TODOS OS LOGs BINÁRIOS

    Se o servidor de banco de dados não for usado como MySQL Replication Master, execute

    O REGISTRO BINÁRIO ESTÁ ATIVADO

    mysql> RESET MASTER;

    Isso apagará todos os logs binários e começará com o primeiro (como mysql-bin.000001)

    O REGISTRO BINÁRIO NÃO ESTÁ ATIVADO

    Basta acessar o sistema operacional e executar o comando delete ( rmpara Linux, delpara Windows)

    ELIMINAR REGISTROS BINÁRIOS

    Se você deseja manter os logs binários das últimas 48 horas, execute

    mysql> PURGE BINARY LOGS BEFORE NOW() - INTERVAL 48 HOUR;

    mysqld apagará todos os logs binários com mais de 48 horas.

    PURGA AUTOMÁTICA

    Basta definir o seguinte em my.cnf (ou my.ini)

    [mysqld]
expire_logs_days=2

    Então, reinicie o mysqld ou execute o seguinte comoroot

    mysql> SET GLOBAL expire_logs_days = 2;

    Dessa forma, cada liberação manual ou automática de logs binários excluirá logs com mais de 2 dias.

    Depois que expire_logs_days for definido, o mysqldump limpará os logs antigos toda vez que --flush-logs .

    • 1

relate perguntas