Лучшая практика для исправления ошибки журнала медленных запросов mysql 13

CentOS 5.5 MySQL 5.5 установлен через репозиторий yum

[ОШИБКА] Не удалось использовать /var/log/mysqld.slow.log для ведения журнала (ошибка 13). Отключение выхода на все время работы сервера MySQL. Чтобы снова включить его: устраните причину, выключите сервер MySQL и перезапустите его.

При стандартной установке MySQL 5.5 (в частности, из веб-репозитория) журнал медленных запросов не может начать запись из-за проблем с разрешениями. Если я заранее создам копию и chown он должен принадлежать user: mysql и group: mysql, тогда он работает нормально.

В том же каталоге (/var/log), у него нет проблем с созданием и записью в mysql.log и mysql.error.log.

Очевидно, у меня есть хакерское исправление для этого, но я хотел бы иметь возможность использовать на нем logrotate, не требуя дополнительно logrotate для повторения хакерства. (Единственное, что хуже хакерства, - это повторение хакерства.)

Кто-нибудь знает, что лучше всего исправить?

Похоже на процесс mysql (mysqld_safe, Я считаю) не может Создайте файл журнала после того, как вы использовали logrotate, чтобы убрать его с дороги и отправить HUP? Если я далеко отсюда, дайте мне знать.

Предполагая, что я не далеко, здесь есть несколько вариантов:

Переместите журнал в каталог, принадлежащий тому же пользователю, что и процесс mysqld_safe. Например, создать /var/log/mysqld/ каталог и сохраните туда файлы журналов. Если это каталог mysql: mysql 700, новые файлы могут быть созданы без проблем.
Используйте метод logrotate copy / truncate вместо метода move / SIGHUP. Метод copy / truncate скопирует текущие файлы журнала (mysqld.slow.log) в новый файл (mysqld.slow.log.1) затем обрежьте исходный файл до нуля байтов. Это полезно, если вы не хотите по какой-либо причине прерывать процесс записи в журнал. Обратной стороной, конечно же, является то, что возникает дополнительная нагрузка на диск при копировании исходного файла в новый файл перед очисткой исходного файла до нулевых байтов. Это делается путем добавления copytruncate параметр в разделе logrotate для этого файла и удаление ненужных postrotate раздел.

Вы также можете использовать параметр create команды logrotate, чтобы создать файл журнала после ротации старого файла журнала. Единственное, что вам понадобится после этого, - это сценарий postrotate, который вызывает mysqladmin flush-logs (помните -u и -p, если у вас есть имя пользователя / пароль, который вы хотите использовать для обслуживания). Это должно сэкономить вам накладные расходы на дублирование файла журнала в случае его увеличения.

Любой способ должен быть хорош: create или copytruncate. Помимо требований к пространству, я не знаю никаких преимуществ одного перед другим.