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во время logrotate.

Итак, попробуйте это:

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 и работал как положено.

— codewaggle
источник

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, и chmodded для 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
источник