MySQL non registra l'errore nel nuovo file dopo la rotazione?

14

Problema risolto ma sto scrivendo per riferimento futuro.

/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 funziona bene quando si esegue dalla riga di comando:

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

ma non funziona quando si esegue da cron alle 4 AM Il file dei registri è stato ruotato ma MySQL non registra l'errore nel file appena creato:

-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

Nel postrotate, reindirizzo sia stderr che stdout a un file di registro per vedere cosa succede:

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

Quello che ottengo è:

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

Sembra mysqladminche non legga /root/.my.cnfdurante il logrotate.

Quindi, prova questo:

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

Fonte:

— Quanta
fonte

1

Ho avuto un problema simile.

Non ho riavviato MySQL dopo l'aggiunta /root/.my.cnf, quindi il comando flush postrotate non è stato eseguito.

Una volta riavviato MySQL, leggeva il file my.cnf di root e funzionava come previsto.

— codewaggle
fonte

0

Nel mio caso, il blocco in /etc/logrotate.d/mysqlsembrava un po 'diverso:

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

Nota il commento: "Se fallisce, controlla debian.conf!" e il comando avente il parametro --defaults-file=/etc/mysql/debian.cnf. Questo file aveva la stessa [client]sezione, che definiva l'utente rootcon una password vuota. Quindi, ovviamente, la stessa password utilizzata /root/.my.cnfdoveva essere inserita anche in quel file. Per quanto riguarda la sicurezza, /etc/mysql/debian.cnfè simile a /root/.my.cnf: di proprietà di root:roote chmodded 0600.

— Izzy
fonte

0

Quindi, nel mio caso, c'è un problema di autorizzazione per l' debian-sys-maintutente, a causa del fatto che galera-clusterha la stessa integrità su ciascun nodo, sebbene, ogni nodo sia installato singolarmente, dall'utente debian per ognuno, il cui file di configurazione è/etc/mysql/debian.cnf

Quindi nel logrotatefile è:

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 soluzione è così semplice, basta cambiare la password debian-sys-maintdell'utente su un nodo e impostare la password sul file '/etc/mysql/debian.cnf' su ogni nodo

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

Spero sia utile come il mio.

— shgnInc
fonte