O MySQL não registra erro no novo arquivo após a rotação?

14

Problema resolvido, mas estou anotando para referência futura.

/root/.my.cnf

[mysqladmin]
user            = root
password        = pa$$w0rd

/etc/logrotate.d/mysql

/var/log/mysql-slow.log /var/log/mysqld.log {
    daily
    rotate 7
    dateext
    compress
    missingok
    #notifempty
    sharedscripts
    create 644 mysql mysql
    postrotate
        /usr/bin/mysqladmin flush-logs
    endscript
}

logrotate está funcionando bem ao executar na linha de comando:

# logrotate -v -f /etc/logrotate.d/mysql

mas não funciona ao executar a partir do cron às 04:00. O arquivo de logs foi girado, mas o MySQL não registra o erro no arquivo recém-criado:

-rw-r--r-- 1 mysql mysql      0 Aug  7 10:13 /var/log/mysqld.log
-rw-r--r-- 1 mysql mysql     20 Aug  4 04:04 /var/log/mysqld.log-20120804.gz
-rw-r--r-- 1 mysql mysql     20 Aug  5 04:04 /var/log/mysqld.log-20120805.gz
-rw-r--r-- 1 mysql mysql     20 Aug  6 16:28 /var/log/mysqld.log-20120806.gz

mysql logrotate

— quanta
fonte

12

No postrotate, redireciono stderr e stdout para um arquivo de log para ver o que acontece:

postrotate
    /usr/bin/mysqladmin flush-logs > /var/log/mysqladmin.flush-logs 2>&1
endscript

O que eu recebo é:

/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost' (using password: NO)'

Parece mysqladminque não lê /root/.my.cnfdurante a rotação do log.

Então, tente o seguinte:

postrotate
    env HOME=/root/ /usr/bin/mysqladmin flush-logs > /var/log/mysqladmin.flush-logs 2>&1
endscript

Fonte:

— quanta
fonte

1

Eu tive um problema parecido.

Não reiniciei o MySQL depois de adicionar /root/.my.cnf, portanto o comando postrotate flush não foi executado.

Depois de reiniciar o MySQL, ele leu o arquivo my.cnf raiz e funcionou como esperado.

— codewaggle
fonte

0

No meu caso, o bloco /etc/logrotate.d/mysqlparecia um pouco diferente:

postrotate
        test -x /usr/bin/mysqladmin || exit 0

        if [ -f `my_print_defaults --mysqld | grep -oP "pid-file=\K[^$]+"` ]; then
            # If this fails, check debian.conf!
            mysqladmin --defaults-file=/etc/mysql/debian.cnf flush-logs
        fi
endscript

Observe o comentário: "Se isso falhar, verifique o debian.conf!" eo comando ter o parâmetro --defaults-file=/etc/mysql/debian.cnf. Este arquivo tinha a mesma [client]seção, definindo usuário rootcom uma senha vazia. Então, obviamente, a mesma senha usada também /root/.my.cnftinha que ser colocada nesse arquivo. Em termos de segurança, /etc/mysql/debian.cnfé semelhante a /root/.my.cnf: possuído por root:roote com chmod para 0600.

— Izzy
fonte

0

Então, no meu caso, há um problema de permissão para o debian-sys-maintusuário, pois ele galera-clusterpossui a mesma integridade em cada nó, embora cada nó seja instalado individualmente, pelo usuário debian de cada um, que é o arquivo de configuração./etc/mysql/debian.cnf

Então, no logrotatearquivo é:

postrotate
    test -x /usr/bin/mysqladmin || exit 0
    if [ -f `my_print_defaults --mysqld | grep -oP "pid-file=\K[^$]+"` ]; then
        # If this fails, check debian.conf!
        mysqladmin --defaults-file=/etc/mysql/debian.cnf --local flush-error-log \
          flush-engine-log flush-general-log flush-slow-log
    fi
endscript

A solução tão simples, apenas, altere a senha do debian-sys-maintusuário em um nó e defina a senha no arquivo '/etc/mysql/debian.cnf' em todos os nós

SET PASSWORD FOR 'debian-sys-maint'@'localhost' = password('YOUR PASSWORD');

Espero que seja útil como o meu.

— shgnInc
fonte