MySQL nie rejestruje błędu do nowego pliku po obróceniu?

Problem rozwiązany, ale piszę na przyszłość.

/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 działa poprawnie podczas uruchamiania z wiersza poleceń:

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

ale nie działa, gdy działa z crona o 4 rano. Plik logów został obrócony, ale MySQL nie rejestruje błędu do nowo utworzonego pliku:

-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

W postrotateprzekierowuję stderr i stdout do pliku dziennika, aby zobaczyć, co się stanie:

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

Dostaję to:

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

Wygląda na to, mysqladminże nie czyta się /root/.my.cnfpodczas logrotatu.

Wypróbuj to:

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

Źródło:

• http://bugs.mysql.com/bug.php?id=51005
• http://scribble.scran.ac.uk/svene/weblog/2893.html

Miałem podobny problem.

Nie zrestartowałem MySQL po dodaniu /root/.my.cnf, więc polecenie postrotate flush nie zostało uruchomione.

Po ponownym uruchomieniu MySQL odczytał on główny plik my.cnf i działał zgodnie z oczekiwaniami.

W moim przypadku blok /etc/logrotate.d/mysqlwyglądał nieco inaczej:

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

Zwróć uwagę na komentarz: „Jeśli to się nie powiedzie, sprawdź debian.conf!” oraz polecenie posiadające parametr --defaults-file=/etc/mysql/debian.cnf. Ten plik miał tę samą [client]sekcję, definiując użytkownika rootz pustym hasłem. Więc oczywiście to samo hasło, które zostało użyte, /root/.my.cnfmusiało być również umieszczone w tym pliku. Pod względem bezpieczeństwa, /etc/mysql/debian.cnfjest podobny do /root/.my.cnf: właścicielem root:rooti chmodded do 0600.

Tak więc, w moim przypadku, istnieje problem z uprawnieniami dla debian-sys-maintużytkownika, ponieważ galera-clusterma taką samą integralność na każdym węźle, chociaż każdy węzeł instaluje się osobno, przez użytkownika debian dla każdego, którym jest plik konfiguracyjny/etc/mysql/debian.cnf

Więc w logrotatepliku jest:

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

Rozwiązanie tak proste, wystarczy zmienić hasło debian-sys-maintużytkownika w jednym węźle i ustawić hasło w pliku „/etc/mysql/debian.cnf” na każdym węźle

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

Mam nadzieję, że będzie użyteczny, jak mój.