¿MySQL no registra el error en el nuevo archivo después de rotar?

14

Problema resuelto pero estoy escribiendo para la referencia 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 funciona bien cuando se ejecuta desde la línea de comandos:

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

pero no funciona cuando se ejecuta desde cron a las 4 a.m. El archivo de registros se rotó pero MySQL no registra el error en el archivo recién creado:

-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
fuente

12

En el postrotate, redirijo stderr y stdout a un archivo de registro para ver qué sucede:

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

Lo que obtengo es:

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

Parece que mysqladminno se lee /root/.my.cnfdurante logrotate.

Entonces, prueba esto:

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

Fuente:

— quanta
fuente

1

Tuve un problema similar.

No /root/.my.cnfreinicié MySQL después de agregar , por lo que no se ejecutó el comando de lavado postrotate.

Una vez que reinicié MySQL, leyó el archivo raíz my.cnf y funcionó como se esperaba.

— codewaggle
fuente

0

En mi caso, el bloque se /etc/logrotate.d/mysqlveía un poco 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

Tenga en cuenta el comentario: "Si esto falla, compruebe debian.conf!" y el comando que tiene el parámetro --defaults-file=/etc/mysql/debian.cnf. Este archivo tenía la misma [client]sección, definiendo al usuario rootcon una contraseña vacía. Obviamente, la misma contraseña utilizada también /root/.my.cnftuvo que colocarse en ese archivo. En cuanto a la seguridad, /etc/mysql/debian.cnfes similar a /root/.my.cnf: propiedad de root:rooty modificado para 0600.

— Izzy
fuente

0

Entonces, en mi caso, hay un problema de permiso para el debian-sys-maintusuario, debido a que galera-clustertiene la misma integridad en cada nodo, aunque cada nodo se instala individualmente, por el usuario de Debian para cada uno, cuyo archivo de configuración es/etc/mysql/debian.cnf

Entonces en el logrotatearchivo está:

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

La solución es tan simple, simplemente, cambie la contraseña del debian-sys-maintusuario en un nodo y configure la contraseña en el archivo '/etc/mysql/debian.cnf' en cada nodo

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

Espero, sea útil, como el mío.

— shgnInc
fuente