mysqldump и /*!40001 SQL_NO_CACHE */

Долгое время в рассылке медленных логов от maatkit меня тревожила запись вида:

#               pct   total     min     max     avg     95%    stddev    median
# Count         38    310
# Exec time     67    355s       0      85s      1s    992ms    8s         0
# Lock time     0     0          0       0       0       0      0          0
# Rows sent     99    10.57M     0      2.66M  34.93k  65.68k  223.39k    9.83
# Rows exam     60    10.57M     0      2.66M  34.93k  65.68k  223.39k    9.83
# Users         1     dbusr
# Databases     3     d1 (4), d2 (2), d3(1)
# Time range 2009-10-07 08:00:02 to 2009-10-07 16:02:38
# Query_time distribution
#   1us
#  10us
# 100us
#   1ms
#  10ms
# 100ms
#    1s  ################################################################
#  10s+  ##########################
# Tables
#    SHOW TABLE STATUS FROM `d1` LIKE 'tbl_n'G
#    SHOW CREATE TABLE `d1`.`tbl_n`G
SELECT /*!40001 SQL_NO_CACHE */ * FROM `tbl_n`G
# Converted for EXPLAIN
# EXPLAIN
SELECT /*!40001 SQL_NO_CACHE */ * FROM `tbl_n`G

Пренеприятнейший лог надо вам сказать. Какая-то зараза выбирает до 2.66M записей разом (за половину суток > 10М). И так каждый день. Собственно забивать закрывать глаза на эту проблему помогал тот факт что на сервисе и нагрузке это вроде бы никак не отражалось.

Однако стоило приглядеться и картина стала ясной.

1. факт – большой разброс макс-мин-95% строк за выборку: 2.66M –  34.93k –  65.68k
2. факт – mk-query-digest агрегирует схожие запросы

Виновником этой строки стал mysqldump (что и было проверено и подтверждено визуально слежением за slow-log во время дампа).

p.s. спасибо munin и maatkit за наш спокойный сон )

hth!

Maatkit для MySQL

Оказывается суровые DBA все прогрессивное MySQL сообщество использует Maatkit http://www.maatkit.org для готовки этой rdbms. Протестировал, запустил в крон ежедневную статистику (пока на почту). Изучаю, чешу репу стмулирую мыслительный процесс. Занятные вещи происходят на нашем сервере, вот ведь.

Вкратце про Maatkit можно просмотреть презентацию Константина Осипова с rootconf’09 http://www.slideshare.net/Dolce727/root-conf, ну а для тех кому лень Maatkit это:

  • 20+ скриптов на perl для анализа и автоматизации некоторых операций
  • параллельный backup/restore,
  • работа со slave базой, 
  • анализ медленных логов
  • анализ дедлоков
  • визуальный EXPLAIN

и многое другое.

Быстрая настройка ротации mysql slow log

Проблема – по умолчанию mysql не умеет и не хочет “вращать” лог медленных запросов.

Необходимые допущения:

  • MySQL работает из-под пользователя mysql (у меня по умолчанию так, скорее всего и у вас тоже)
  • Лог медленных запросов лежит тут: /var/log/mysql-slow.log

Что хотим получить

  • Еженедельную ротацию
  • Держать одновременно 3 лога (+ один текущий)
  • Сжимать gzip‘ом
  • Создавать новый лог с правами 660 в собственности mysql:mysql
  • Запустить mysqladmin flush-logs

Для достижения этого помещаем в /etc/logrotate.d/ следующий скрипт

$ vim /etc/logrotate.d/mysql-slow

Текст скрипта:

/var/log/mysql-slow.log {
    weekly
    rotate 3
    compress
    missingok
    notifempty
    sharedscripts
    create 660 mysql mysql
    postrotate
        /usr/bin/mysqladmin flush-logs
    endscript
}

Желательно предварительно протестировать на вашей конфигурации.

P.S. оригинал тут http://www.saiweb.co.uk/mysql/mysql-slow-query-log-rotation

UPD: гм. по умолчанию на моих серверах logrotate не было. Спасает

yum install logrotate