Onde, no automysqlbackup, adiciono parâmetros mysqldump?

Question

Como parar o script cron.daily do automysqlbackup - como instalado e configurado a partir de apt-get install automysqlbackup - lançando o seguinte erro:

 mysqldump: Got error: 1142: SELECT,LOCK TABL command denied to user 
'debian-sys-maint'@'localhost' for table 'cond_instances' when using LOCK TABLES

Isso ocorre após a atualização para o MySQL 5.5 como um efeito colateral de ter atualizado para o Ubuntu 12.04 LTS.

A solução correta (obrigado @sr_ pelo apontador para o relatório de erros apropriado) é excluir o banco de dados 'performance_schema' do mysqldump.

Então a questão é: Como fazer isso respeitando os pacotes e configurações Debian?

O problema ocorre diariamente depois de ter feito o upgrade para o MySQL 5.5.

Histórico: Meu objetivo é ficar com os pacotes e configurações Ubuntu Debian instalados da maneira mais padrão possível. Mas, na verdade, este é um bug com a forma como os pacotes são instalados / atualizados, portanto, é necessário atualizar um dos arquivos de configuração fornecidos.

debian-sys-maint tem todos os privilégios, portanto, já tem o suficiente para bloquear cada tabela antes de descartá-la.

O que é confuso é que /usr/share/doc/automysqlbackup/README.Debian diz que

All parameters can be setup by editing the /etc/default/automysqlbackup file

/etc/default/automysqlbackup chama o mysqlbackup com configurações em /etc/mysql/debian.cnf , que diz:

Automatically generated for Debian scripts. DO NOT TOUCH!.

    

Answer 1

Esta solução corrigiu para mim.

De acordo com o relatório de erros , é necessário parar o automysqlbackup despejar o banco de dados 'performance_schema', e isso é feito editando /etc/default/automysqlbackup da seguinte forma:

Adicione um pipe adicional ao grep para remover o 'performance_schema' da lista de DBNAMES.

Assim, na linha que inicia DBNAMES= e depois de | grep -v ^mysql$ inserir

| grep -v ^performance_schema$ 

antes de | tr \\r\\n ,\

Obrigado ao Jérôme Drouet

Esta solução aplica-se à versão Debian do automysqlbackup como no Ubuntu 12.04. Evidentemente, a sintaxe para excluir o banco de dados "performance_schema" varia de acordo com a distribuição do Linux - veja @stat abaixo.

    

Answer 2

Edit: Esqueça tudo o que eu disse.

Veja este relatório de bug . Talvez você encontre uma maneira de "excluir o banco de dados 'performance_schema' do mysqldump", como o comentário # 2 indica; caso contrário, o pôster dos relatórios de erros editou o script automysqlbackup para adicionar o parâmetro --skip-lock-tables , mas suponho que isso possa prejudicá-lo (conforme descrito abaixo).

Resposta curta: você provavelmente quer bloqueá-los.

Eu acho que não trancar eles não é o que você quer, já que você pode obter backups inúteis, ou seja, quando algo muda a tabela enquanto o backup está em andamento - - que é o que o lock está lá para prevenir.

Este LEIAME do garfo e este entrada de bloco menciona algo sobre conceder ao usuário 'autobackup'@'localhost' acesso a tabelas de bloqueio .

Dito isto, a sua mensagem de erro indica que o "utilizador" em questão é 'debian-sys-maint'@'localhost' . Então, acho que se você conceder os privilégios necessários para este usuário ou alterar as credenciais do script de backup em automysqlbackup.conf (que pode ser /etc/default/automysqlbackup no Debian, consulte man automysqlbackup e /usr/share/doc/automysqlbackup/README.Debian ), você deve estar bem.

Editar De este manual , cito o que o --lock-tables deve fazer

--lock-tables, -l

For each dumped database, lock all tables to be dumped before dumping them.

Ele está vinculado a partir da única ocorrência de --skip-lock-tables no manual, portanto, considero que --skip-lock-tables faz com que mysqldump não bloqueie tabelas ao despejá-las . Isso, como argumentei acima, não é aconselhável. Eu não acho que tenha algo a ver com o dumping de tabelas de bloqueio mas com tabelas de bloqueio .

Eu não entendo, no entanto, por que isso não funciona se, como você disse, o usuário em questão deve ser capaz de fazê-lo ...

    

Answer 3

Eu estava enganado, veja a solução 1, que realmente funciona no debian

Consegui corrigir isso "temporariamente" alterando a linha em /etc/default/automysqlbackup para o seguinte:

CONFIG_db_exclude=( 'information_schema' 'performance_schema' )

Não tenho certeza do efeito que isso tem, mas restaurações de teste funcionam para mim e o backup é concluído sem erros.

Após a última atualização, a minha solução que estava no sid debian falhou, mas a solução um (que não funcionou para mim antes) funciona. Isso é grepping o / etc / default / automysqlbackup e adicionando a linha | grep -v ^ performance_schema $. O acima exclui que eu usei antes parece ser ignorado no entulho.