MySQL не записує помилку в новий файл після обертання?

14

Проблема вирішена, але я записую її для подальшого використання.

/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 працює добре під час запуску з командного рядка:

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

але він не працює, коли працює з cron о 4 ранку. Файл журналів повернуто, але MySQL не записує помилку до новоствореного файлу:

-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

— кванти
джерело

12

У розділі postrotateя перенаправляю і stderr, і stdout у файл журналу, щоб побачити, що відбувається:

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

Що я отримую:

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

Здається mysqladmin, не читається /root/.my.cnfпід час логротату.

Отже, спробуйте це:

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

Джерело:

— кванти
джерело

1

У мене була схожа проблема.

Я не перезапустив MySQL після додавання /root/.my.cnf, тому команда postrotate flush не була запущена.

Як тільки я перезапустив MySQL, він прочитав кореневий файл my.cnf і працював, як очікувалося.

— ковзання
джерело

0

У моєму випадку блок у /etc/logrotate.d/mysqlвиглядав дещо інакше:

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

Зверніть увагу на коментар: "Якщо це не вдалося, перевірте debian.conf!" і команда, що має параметр --defaults-file=/etc/mysql/debian.cnf. Цей файл мав той самий [client]розділ, який визначав користувача rootз порожнім паролем. Очевидно, що той самий пароль, який було використано, /root/.my.cnfмав бути розміщений і у цьому файлі. Безпечний, /etc/mysql/debian.cnfсхожий на /root/.my.cnf: належить root:rootі підтримується 0600.

— Іззі
джерело

0

Таким чином, у моєму випадку існує проблема з дозволом для debian-sys-maintкористувача, оскільки він galera-clusterмає однакову цілісність на кожному вузлі, хоча кожен вузол встановлюється індивідуально, користувачем Debian для кожного, який, конфігураційний файл, є/etc/mysql/debian.cnf

Отже, у logrotateфайлі є:

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

Рішення настільки просто, просто змініть пароль debian-sys-maintкористувача на одному вузлі та встановіть пароль у файлі '/etc/mysql/debian.cnf' на всіх вузлах

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

Сподіваюся, це буде корисним, як і моє.

— shgnInc
джерело