Fazer um dump mysql faz com que o aplicativo da web seja interrompido.

Question

O seguinte comando pode ser feito em um servidor ativo

mysqldump -h XXXX -u root -pXXXXX --skip-opt --flush-privileges 
    --flush-logs --routines --triggers --allow-keywords 
    --create-options --add-locks --quick --single-transaction 
    --extended-insert --all-databases

causa um aplicativo da web (que depende de bancos de dados do servidor) para travar?

    

Answer 1

Algumas possibilidades:

• As tabelas MyISAM suportam apenas o bloqueio em nível de tabela, portanto, enquanto seu mysqldump estiver lendo a tabela, todas as gravações serão enfileiradas até o término. Se uma gravação for enfileirada, qualquer outra leitura será enfileirada atrás da gravação, bloqueando efetivamente o aplicativo. Não há nada de especial sobre mysqldump nesse sentido, é apenas um único SELECT * FROM table que leva tempo suficiente para que uma gravação aconteça e seja enfileirada.

• As tabelas InnoDB suportam o bloqueio em nível de linha, o que significa que as leituras e gravações podem ser intercaladas, desde que não toquem nas mesmas linhas. Existem alguns tipos de consulta que bloqueiam a tabela inteira (como ALTER table ... ), mas se você os executasse com frequência, eles teriam causado problemas muito antes de mysqldump .

• Um mysqldump também pode causar muito mais acesso ao disco do que o normal. Ele está efetivamente lendo em todo o seu banco de dados e escrevendo de volta, provavelmente para o mesmo disco físico. Ler e gravar no mesmo disco físico vai causar latência extra (a menos que sejam SSDs) porque as partes do disco que você está lendo e escrevendo têm que ser diferentes e, portanto, haverá mais buscas, o que leva tempo . Isso aumentará a média de carga em sua caixa e fará com que quaisquer outras operações que requeiram acesso ao disco sejam mais lentas.

• A maioria dos bancos de dados armazena mais dados do que eles possuem RAM. Seu mysqldump pode ter esvaziado seu cache do sistema de arquivos e preenchido com dados inúteis, o que significa que outras solicitações de acesso ao disco terão que vir dos discos reais (que têm latência excessiva no momento), em vez de serem provenientes do cache muito mais rápido . Ele também pode ter liberado caches dentro do MySQL, dependendo dos limites que você configurou para cada um deles.

• Dependendo da sua configuração do MySQL, o mysqldump que toca cada tabela pode fazer com que o MySQL use mais RAM do que você tem disponível. Isso faria com que parte da sua RAM ativa fosse trocada para o disco, aumentando ainda mais a utilização do disco e causando um enorme impacto no desempenho.

Execute o mysqltuner.pl no seu sistema para ajudar a ajustar sua configuração e considere mudar para o InnoDB ao invés do MyISAM se você estiver atualmente usando MyISAM. Tente transmitir seus backups diretamente para o servidor de backup, em vez de gravá-los no mesmo disco. (Isso pode ser conseguido de várias formas, mas isso funciona: mysqldump [OPTIONS] | gzip | ssh "cat - > database_backup.$(date +%F).sql.gz" <BACKUPHOST> ) Se (ou uma vez) você estiver no InnoDB, você pode usar XtraBackup da Percona como uma ferramenta de backup melhor que é quase tão eficiente quanto uma cópia de arquivo puro e pode ser usada para inicializar a replicação. O XtraBackup também pode transmitir diretamente para outro servidor.