MySQL ne consigne pas d'erreur dans le nouveau fichier après la rotation?

14

Problème résolu mais j'écris pour la future référence.

/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 fonctionne correctement lors de l'exécution à partir de la ligne de commande:

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

mais cela ne fonctionne pas lors de l'exécution de cron à 4 heures du matin. Le fichier journal a été tourné mais MySQL ne consigne pas l'erreur dans le fichier nouvellement créé:

-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
la source

Réponses:

12

Dans le postrotate, je redirige stderr et stdout vers un fichier journal pour voir ce qui se passe:

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

Ce que je reçois est:

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

Cela ressemble à mysqladminne pas lire /root/.my.cnfpendant la rotation du journal.

Alors essayez ceci:

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

La source:

quanta
la source
1

J'avais un problème similaire.

Je n'ai pas redémarré MySQL après l'ajout /root/.my.cnf, la commande postrotate flush n'a donc pas été exécutée.

Une fois que j'ai redémarré MySQL, il a lu le fichier racine my.cnf et a fonctionné comme prévu.

codewaggle
la source
0

Dans mon cas, le bloc /etc/logrotate.d/mysqlétait un peu différent:

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

Notez le commentaire: "Si cela échoue, vérifiez debian.conf!" et la commande ayant le paramètre --defaults-file=/etc/mysql/debian.cnf. Ce fichier avait la même [client]section, définissant l'utilisateur rootavec un mot de passe vide. Donc, évidemment, le même mot de passe utilisé dans /root/.my.cnfdevait également être placé dans ce fichier. En termes de sécurité, /etc/mysql/debian.cnfest similaire à /root/.my.cnf: détenu par root:root, et modifié par 0600.

Izzy
la source
0

Donc, dans mon cas, il y a un problème de permission pour l' debian-sys-maintutilisateur, car il galera-clustera la même intégrité sur chaque nœud, bien que chaque nœud s'installe individuellement, par l'utilisateur Debian pour chacun, ce qui, le fichier de configuration est/etc/mysql/debian.cnf

Donc, dans le logrotatefichier se trouve:

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 solution si simple, changez simplement le mot de passe de l' debian-sys-maintutilisateur sur un nœud et définissez le mot de passe sur le fichier '/etc/mysql/debian.cnf' sur chaque nœud

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

J'espère, ce sera utile, comme le mien.

shgnInc
la source