Журналы событий — первый и самый простой инструмент для определения статуса системы и выявления ошибок. Основных логов в MySQL четыре:
- Error Log — стандартный лог ошибок, которые собираются во время работы сервера (в том числе start и stop);
- Binary Log — лог всех команд изменения БД, нужен для репликации и бэкапов;
- General Query Log — основной лог запросов;
- Slow Query Log — лог медленных запросов.
Лог ошибок
Этот журнал содержит все ошибки, которые произошли во время работы сервера, включая критические ошибки, а также остановки, включения сервера и предупреждения (warnings). С него нужно начать в случае сбоя системы. По умолчанию все ошибки выводятся в консоль (stderr), также можно записывать ошибки в syslog (по умолчанию в Debian) или отдельный лог-файл:
|
log_error=/var/log/mysql/mysql_error.log |
Рекомендуем держать этот журнал включенным для быстрого определения ошибок. А для понимания, что значит та или иная ошибка, в MySQL присутствует утилита perror:
|
shell> perror 13 64 OS error code 13: Permission denied OS error code 64: Machine is not on the network |
Бинарный (он же двоичный) лог
В бинарный лог записываются все команды изменения базы данных, пригодится для репликации и восстановления.
Включается так:
|
log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 5 max_binlog_size = 500M |
Учтите, что если вы не собираетесь масштабировать систему и реализовывать отказоустойчивость, то бинарный лог лучше не включать. Он требователен к ресурсам и снижает производительность системы.
Лог запросов
В этом журнале содержатся все полученные SQL-запросы, информация о подключениях клиентов. Может пригодиться для анализа индексов и оптимизации, а также выявления ошибочных запросов:
|
general_log_file = /var/log/mysql/mysql.log <b>general_log = 1</b> |
Также его можно включить/отключить во время работы сервера MySQL:
|
SET GLOBAL general_log = ‘ON‘; SET GLOBAL general_log = ‘OFF‘; |
Лог медленных запросов
Журнал пригодится для определения медленных, то есть неэффективных запросов. Подробнее читайте в этой статье.
Просмотр логов
Для просмотра логов на Debian (Ubuntu) нужно выполнить:
|
# Лог ошибок tail -f /var/log/syslog <span class=«comment»> #Лог запросов </span>tail -f /var/log/mysql/mysql.log <span class=«comment»> # Лог медленных запросов </span>tail -f /var/log/mysql/mysql-slow.log |
Ротация логов
Не забывайте сжимать (архивировать, ротировать) файлы логов, чтобы они занимали меньше места на сервере. Для этого используйте утилиту logrotate, отредактировав файл конфигурации /etc/logrotate.d/mysql-server:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
# — I put everything in one block and added sharedscripts, so that mysql gets <span class=«comment»> # flush-logs’d only once. </span># Else the binary logs would automatically increase by n times every day. <span class=«comment»> # — The error log is obsolete, messages go to syslog now. </span><b>/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log</b> { daily rotate 7 missingok create 640 mysql adm compress sharedscripts postrotate test -x /usr/bin/mysqladmin || exit 0 <span class=«comment»> # If this fails, check debian.conf! </span> MYADMIN=«/usr/bin/mysqladmin —defaults-file=/etc/mysql/debian.cnf» if [ -z «`$MYADMIN ping 2>/dev/null`» ]; then <span class=«comment»> # Really no mysqld or rather a missing debian-sys-maint user? </span> <span class=«comment»> # If this occurs and is not an error please report a bug. </span> <span class=«comment»> #if ps cax | grep -q mysqld; then </span> if killall -q -s0 -umysql mysqld; then exit 1 fi else $MYADMIN flush-logs fi endscript } |
DDL Log
MySQL также ведет лог языка описания данных. В него собираются данные операций типа DROP_TABLE and ALTER_TABLE. Лог используется для восстановления после сбоев, которые произошли во время выполнения таких операций. DDL Log — бинарный файл, не предназначенный для чтения пользователем, поэтому не модифицируйте и не удаляйте его.
Самое главное
Всегда включайте лог ошибок, используйте лог запросов для проверки соединения приложения с базой данных, проверки запросов и работы memcached. Лог медленных запросов пригодится для оптимизации работы MySQL.
https://github.com/midnight47/
- Home
- Coding
- MySQL
- Журналы работы сервера MySQL — ошибок, двоичные, общих запросов, медленных запросов
Статья содержит краткое описание журналов работы сервера MySQL — журнал ошибок, общий журнал запросов, журнал медленных запросов, двоичные журналы
Все журналы связанные с работой сервера MySQL по умолчанию находятся в папке data корневой папки MySQL (той паки куда был установлен MySQL).
Представляет файл с расширением .err. В качестве имени файла берется hostname (hostname.err). Содержит информацию об ошибках в работе, запусках и остановках сервера. Данные хранятся в текстовом виде, поэтому их можно посмотреть любым текстовым редактором.
Общий журнал запросов MySQL
Представляет файл с расширением .log. В качестве имени файла берется hostname (hostname.log). Содержит информацию о подключениях клиентских программ и выполняемых запросах. Для ведения этих журналов сервер должен быть запущен с параметром – log. Данные хранятся в текстовом виде, поэтому их можно посмотреть любым текстовым редактором.
Журнал медленных запросов MySQL
Представляет файл с именем hostname-show.log. Содержит информацию об длительных АО времени SQL-запросах (по умолчанию – более 10 с), служит для обнаружения объектов, требующих оптимизации. Для ведения этих журналов сервер должен быть запущен с параметром – log-slow-queries. Данные хранятся в текстовом виде, поэтому их можно посмотреть любым текстовым редактором.
Двоичные журналы MySQL
Представляет файл с именем hostname-bin.xxxxxx, где xxxxxx – порядковый номер журнала. Содержат историю изменений данных в базе. Для ведения этих журналов сервер должен быть запущен с параметром – log-bin. Для просмотра двоичных журналов необходимо использовать специальную утилиту mysqlbinlog (запускается из командной строки)
mysqlbinlog hostname-bin.xxxxxx — Выведет содержимое в виде SQL-команд.
mysqlbinlog hostname-bin.xxxxxx filename – Запишет содержимое в виде SQL-команд в файл, который можно посмотреть любым текстовым редактором.
На этом все, всем пока.
Меня два раза спрашивали [члены Парламента]: «Скажите на милость, мистер Бэббидж, что случится, если вы введёте в машину неверные цифры? Cможем ли мы получить правильный ответ?» Я не могу себе даже представить, какая путаница в голове может привести к подобному вопросу. / Charles Babbage /
Список
- Общий журнал — все запросы — см. VARIABLE general_log
- Медленный журнал — запросы медленнее, чем long_query_time — slow_query_log_file
- Binlog — для репликации и резервного копирования — log_bin_basename
- Журнал ретрансляции — также для репликации
- общие ошибки — mysqld.err
- start / stop — mysql.log (не очень интересно) — log_error
- Журнал изменений InnoDB — iblog *
См. Переменные basedir и datadir для местоположения по умолчанию для многих журналов
Некоторые журналы включаются и выключаются другими ПЕРЕМЕННЫМИ. Некоторые из них либо записываются в файл, либо в таблицу.
(Примечание для рецензентов: для этого требуется более подробная информация и пояснения.)
Документаторы : укажите расположение и имя по умолчанию для каждого типа журнала, как для Windows, так и для * nix. (Или, по крайней мере, столько, сколько сможете).
Медленный журнал запросов
Журнал медленных запросов состоит из журнальных событий для запросов, long_query_time до long_query_time . Например, до 10 секунд для завершения. Чтобы увидеть установленный порог времени, выполните следующие действия:
SELECT @@long_query_time;
+-------------------+
| @@long_query_time |
+-------------------+
| 10.000000 |
+-------------------+
Его можно установить как переменную GLOBAL в файле my.cnf или my.ini . Или это может быть установлено связью, хотя это необычно. Значение может быть установлено в диапазоне от 0 до 10 (в секундах). Какую ценность использовать?
- 10 настолько высока, что почти бесполезна;
- 2 — компромисс;
- 0,5 и другие фракции;
- 0 захватывает все; это может залить диск опасно быстро, но может быть очень полезно.
Захват медленных запросов включается или выключается. И указанный файл также указан. Ниже приведены следующие понятия:
SELECT @@slow_query_log; -- Is capture currently active? (1=On, 0=Off)
SELECT @@slow_query_log_file; -- filename for capture. Resides in datadir
SELECT @@datadir; -- to see current value of the location for capture file
SET GLOBAL slow_query_log=0; -- Turn Off
-- make a backup of the Slow Query Log capture file. Then delete it.
SET GLOBAL slow_query_log=1; -- Turn it back On (new empty file is created)
Для получения дополнительной информации см. Страницу руководства MySQL. Журнал медленных запросов
Примечание: приведенная выше информация о включении / выключении замедления была изменена в 5.6 (?); у старой версии был другой механизм.
«Лучший» способ увидеть, что замедляет вашу систему:
long_query_time=...
turn on the slowlog
run for a few hours
turn off the slowlog (or raise the cutoff)
run pt-query-digest to find the 'worst' couple of queries. Or mysqldumpslow -s t
Общий журнал запросов
Общий журнал запросов содержит листинг общей информации от клиентских подключений, разъединений и запросов. Это бесценно для отладки, но это создает препятствия для работы (цитата?).
Пример просмотра общего журнала запросов приведен ниже:
Чтобы определить, записывается ли в настоящий момент общий журнал:
SELECT @@general_log; -- 1 = Capture is active; 0 = It is not.
Чтобы определить имя файла захвата:
SELECT @@general_log_file; -- Full path to capture file
Если полный путь к файлу не отображается, файл существует в datadir .
Пример Windows:
+----------------------------------------------------------+
| @@general_log_file |
+----------------------------------------------------------+
| C:ProgramDataMySQLMySQL Server 5.7DataGuySmiley.log |
+----------------------------------------------------------+
Linux:
+-----------------------------------+
| @@general_log_file |
+-----------------------------------+
| /var/lib/mysql/ip-ww-xx-yy-zz.log |
+-----------------------------------+
Когда изменяются переменные GLOBAL general_log_file , новый журнал сохраняется в datadir . Однако полный путь больше не может быть отражен путем изучения переменной.
В случае отсутствия записи для файла general_log_file в файле конфигурации по умолчанию будет @@hostname .log в datadir .
Лучшая практика — отключить захват. Сохраните файл журнала в резервном каталоге с именем файла, отражающим дату и время начала и окончания захвата. Удаление предыдущего файла, если перемещение файловой системы не произошло из этого файла. Установите новое имя файла для файла журнала и включите захват (все показано ниже). Лучшие практики также включают тщательное определение, даже если вы хотите захватить на данный момент. Как правило, захват включен только для целей отладки.
Типичным именем файла файловой системы для резервного архива может быть:
/LogBackup/GeneralLog_20160802_1520_to_20160802_1815.log
где дата и время являются частью имени файла как диапазона.
Для Windows обратите внимание на следующую последовательность изменений настроек.
SELECT @@general_log; -- 0. Not being captured
SELECT @@general_log_file; -- C:ProgramDataMySQLMySQL Server 5.6DataGuySmiley.log
SELECT @@datadir; -- C:ProgramDataMySQLMySQL Server 5.7Data
SET GLOBAL general_log_file='GeneralLogBegin_20160803_1420.log'; -- datetime clue
SET GLOBAL general_log=1; -- Turns on actual log capture. File is created under `datadir`
SET GLOBAL general_log=0; -- Turn logging off
Linux похож. Они будут представлять собой динамические изменения. Любой перезапуск сервера подбирает настройки файла конфигурации.
Что касается файла конфигурации, рассмотрите следующие соответствующие параметры переменной:
[mysqld]
general_log_file = /path/to/currentquery.log
general_log = 1
Кроме того, переменную log_output можно настроить для вывода TABLE , а не только FILE . Для этого, пожалуйста, см. « Направления» .
См. Страницу руководства MySQL . Общий журнал запросов .
Журнал ошибок
Журнал ошибок заполняется информацией о запуске и остановке и критическими событиями, встречающимися на сервере.
Ниже приведен пример его содержимого:
Переменная log_error содержит путь к файлу журнала для регистрации ошибок.
В отсутствие записи файла конфигурации для log_error система будет по умолчанию использовать значения @@hostname .err в datadir . Обратите внимание, что log_error не является динамической переменной. Таким образом, изменения выполняются с помощью изменений файла cnf или ini и перезапуска сервера (или путем просмотра «Промывка и переименование файла журнала ошибок» на странице «Ручная страница» внизу).
Журналы не могут быть отключены для ошибок. Они важны для здоровья системы при устранении неполадок. Кроме того, записи нечасты по сравнению с общим журналом запросов.
GLOBAL-переменная log_warnings устанавливает уровень для многословия, который зависит от версии сервера. Следующий фрагмент иллюстрирует:
SELECT @@log_warnings; -- make a note of your prior setting
SET GLOBAL log_warnings=2; -- setting above 1 increases output (see server version)
log_warnings как показано выше, является динамической переменной.
Изменения файла конфигурации в файлах cnf и ini могут выглядеть следующим образом.
[mysqld]
log_error = /path/to/CurrentError.log
log_warnings = 2
MySQL 5.7.2 расширил многословие уровня предупреждения до 3 и добавил GLOBAL log_error_verbosity . Опять же, оно было введено в 5.7.2. Он может быть установлен динамически и проверен как переменная или задан с помощью настроек файла конфигурации cnf или ini .
Начиная с MySQL 5.7.2:
[mysqld]
log_error = /path/to/CurrentError.log
log_warnings = 2
log_error_verbosity = 3
Пожалуйста, обратитесь к странице руководства по MySQL, озаглавленной « Журнал ошибок», особенно для флеширования и переименования файла журнала ошибок, а также в разделе « Подробный журнал ошибок » с версиями, связанными с log_warnings и error_log_verbosity .
Журнал ошибок содержит запись критических ошибок,произошедших во время работы сервера,повреждение таблицы,информацию о запуске и остановке.
Ошибки SQL также можно регистрировать в отдельном файле с помощью подключаемого модуля SQL_ERROR_LOG .
Настройка назначения выхода журнала ошибок
MariaDB всегда записывает свой журнал ошибок,но место назначения настраивается.
Запись журнала ошибок в файл.
Чтобы настроить запись журнала ошибок в файл, вы можете установить системную переменную log_error . Вы можете настроить конкретное имя файла. Однако, если конкретное имя файла не настроено, журнал по умолчанию будет записываться в файл ${hostname}.err в каталоге datadir .
Системная переменная log_error может быть установлена в группе опций сервера в файле опций перед запуском сервера. Например, чтобы записать журнал ошибок в файл ${hostname}.err по умолчанию , вы можете настроить следующее:
[mariadb]
...
log_error
Если вы настроите определенное имя файла в качестве системной переменной log_error и если это не абсолютный путь, то он будет относительным к каталогу datadir . Например, если вы настроили следующее, журнал ошибок будет записываться в mariadb.err в каталоге datadir :
[mariadb]
...
log_error=mariadb.err
Если это относительный путь, то log_error относится к каталогу datadir .
Однако системная переменная log_error также может быть абсолютным путем. Например:
[mariadb] ... log_error=/var/log/mysql/mariadb.err
Другой способ настроить имя файла журнала ошибок — установить параметр log-basename , который настраивает MariaDB на использование общего префикса для всех файлов журнала (например , общий журнал запросов , журнал медленных запросов , журнал ошибок, двоичные журналы и т. д .). Имя файла журнала ошибок будет создано путем добавления расширения .err к этому префиксу. Например, если вы настроили следующее, журнал ошибок все равно будет записываться в mariadb.err в каталоге datadir :
[mariadb]
...
log-basename=mariadb
log_error
Лог-базовое имя не может быть абсолютным путем. Имя файла журнала относится к каталогу datadir .
Запись журнала ошибок в Stderr на Unix
В Unix, если системная переменная log_error не установлена, то ошибки записываются в stderr , что обычно означает, что сообщения журнала выводятся на терминал, запустивший mysqld .
Если системная переменная log_error была установлена в файле опций или в командной строке, ее все равно можно отменить, указав --skip-log-error .
Запись журнала ошибок в Syslog на Unix
В Unix журнал ошибок также можно перенаправить в системный журнал . Как это будет сделано, зависит от того, как вы запускаете MariaDB.
Syslog с mysqld_safe
Если вы запускаете MariaDB с mysqld_safe , то журнал ошибок можно перенаправить в syslog. См. mysqld_safe: Настройка MariaDB для записи журнала ошибок в системный журнал для получения дополнительной информации.
Syslog с Systemd
Если вы запускаете MariaDB с помощью systemd , то журнал ошибок также может быть перенаправлен в syslog. См. Systemd: Настройка MariaDB для записи журнала ошибок в системный журнал для получения дополнительной информации.
systemd также имеет свою собственную систему журналирования, называемую journal , и вместо этого некоторые ошибки могут регистрироваться там. См. Systemd:Журнал Systemd для получения дополнительной информации.
Запись журнала ошибок в консоль на Windows
В Windows, если указана консольная опция и не используется системная переменная log_error , то ошибки записываются в консоль. Если указаны оба параметра, последний вариант имеет приоритет.
Запись журнала ошибок в программу просмотра событий Windows Event Viewer
В Windows сообщения журнала об ошибках также записываются в средство просмотра событий Windows. Вы можете найти сообщения журнала ошибок MariaDB, просмотрев журналы Windows и выбрав приложение или журнал приложений , в зависимости от версии Windows.
В MariaDB 10.3 и ранее вы можете найти сообщения журнала ошибок MariaDB, выполнив поиск по Source MySQL .
В MariaDB 10.4 и более поздних версиях вы можете найти сообщения журнала ошибок MariaDB, выполнив поиск по источнику MariaDB .
Настройка вербозиции журнала ошибок
Системная переменная log_warnings может использоваться для настройки детализации журнала ошибок. Его можно изменить динамически с помощью SET GLOBAL . Например:
SET GLOBAL log_warnings=3;
Его также можно установить либо в командной строке, либо в группе опций сервера в файле опций перед запуском сервера. Например:
[mariadb]
...
log_warnings=3
Некоторые из предупреждений,включенных в каждый уровень сложности,описаны ниже.
Системная переменная log_warnings влияет только на некоторые сообщения журнала . Некоторые сообщения журнала всегда записываются в журнал ошибок, независимо от детализации журнала ошибок. Например, log_warnings не влияет на большинство предупреждений механизма хранения InnoDB . Полный список сообщений журнала, на которые влияет log_warnings , см. в описании системной переменной log_warnings .
Уровень гербицидности 0
Если log_warnings равен 0 , то многие необязательные предупреждения не будут регистрироваться. Однако это не препятствует регистрации всех предупреждений, поскольку некоторые основные предупреждения всегда будут записываться в журнал ошибок. Например:
- Если строгий режим InnoDB отключен, и если DDL выполняется для таблицы, которая вызывает ошибку «Размер строки слишком большой» , то InnoDB регистрирует предупреждение:
[Warning] InnoDB: Cannot add field col25 in table db1.tab because after adding it, the row size is 8477 which is greater than maximum allowed size (8126) for a record on index leaf page.
Однако, если строгий режим InnoDB включен, то это же сообщение будет зарегистрировано как ошибка.
Уровень гербицидности 1
Если log_warnings равно 1 , то регистрируются многие типы предупреждений. Некоторые полезные предупреждения:
- Replication-related messages:
[Note] Error reading relay log event: slave SQL thread was killed [Note] Slave SQL thread exiting, replication stopped in log 'dbserver-2-bin.000033' at position 181420; GTID position '0-263316466-368886' [Note] Slave I/O thread exiting, read up to log 'dbserver-2-bin.000034', position 642; GTID position 0-263316466-368887
- Сообщения,связанные с ошибками DNS поиска:
[Warning] IP address '192.168.1.193' could not be resolved: Name or service not known
- Сообщения, относящиеся к планировщику событий :
[Note] Event Scheduler: Loaded 0 events
- Сообщения, связанные с небезопасными операторами для репликации на основе операторов :
[Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. The statement is unsafe because it uses a LIMIT clause. This is unsafe because the set of rows included cannot be predicted.
Частые предупреждения о небезопасных операторах для репликации на основе операторов могут привести к тому, что журнал ошибок станет очень большим. MariaDB автоматически обнаружит частые повторяющиеся предупреждения о небезопасных операторах для репликации на основе операторов . После обнаружения 10 одинаковых предупреждений MariaDB предотвратит повторную запись того же предупреждения в журнал ошибок в течение следующих 5 минут.
Уровень гербицидности 2
Если log_warnings равно 2 , то выводится несколько других видов предупреждений. Например:
- Сообщения,связанные с ошибками отказа в доступе:
[Warning] Access denied for user 'root'@'localhost' (using password: YES)
- Сообщения,связанные с соединениями,которые прерываются из-за ошибок или таймаутов:
[Warning] Aborted connection 35 to db: 'unconnected' user: 'user1@host1' host: '192.168.1.40' (Got an error writing communication packets) [Warning] Aborted connection 36 to db: 'unconnected' user: 'user1@host2' host: '192.168.1.230' (Got an error writing communication packets) [Warning] Aborted connection 38 to db: 'db1' user: 'user2' host: '192.168.1.60' (Unknown error) [Warning] Aborted connection 51 to db: 'db1' user: 'user2' host: '192.168.1.50' (Got an error reading communication packets) [Warning] Aborted connection 52 to db: 'db1' user: 'user3' host: '192.168.1.53' (Got timeout reading communication packets)
- Сообщения,связанные с ошибками в обработчике таблицы:
[Warning] Can't find record in 'tab1'. [Warning] Can't write; duplicate key in table 'tab1'. [Warning] Lock wait timeout exceeded; try restarting transaction. [Warning] The number of locks exceeds the lock table size. [Warning] Update locks cannot be acquired during a READ UNCOMMITTED transaction.
- Сообщения, относящиеся к файлам, используемым для сохранения состояния репликации :
- Либо файл
master.infoпо умолчанию , либо файл, настроенный опцией master_info_file . - Либо файл
relay-log.infoпо умолчанию , либо файл, настроенный системной переменной relay_log_info_file .
- Либо файл
[Note] Reading Master_info: '/mariadb/data/master.info' Relay_info:'/mariadb/data/relay-log.info' [Note] Initialized Master_info from '/mariadb/data/master.info' [Note] Reading of all Master_info entries succeded [Note] Deleted Master_info file '/mariadb/data/master.info'. [Note] Deleted Master_info file '/mariadb/data/relay-log.info'.
- Сообщения о потоке дампа двоичного журнала мастера :
[Note] Start binlog_dump to slave_server(263316466), pos(, 4)
Уровень гербицидности 3
Если log_warnings равно 3 , то печатается пара других различных видов предупреждений. Например:
- Сообщения,связанные с вариантами языка старого образца:
[Warning] An old style part detected: /usr/local/mysql/data/ [Warning] Use
- Сообщения, относящиеся к прогрессу InnoDB online DDL :
[Note] InnoDB: Online DDL : Start [Note] InnoDB: Online DDL : Start reading clustered index of the table and create temporary files [Note] InnoDB: Online DDL : End of reading clustered index of the table and create temporary files [Note] InnoDB: Online DDL : Start merge-sorting index PRIMARY (1 / 3), estimated cost : 18.0263 [Note] InnoDB: Online DDL : merge-sorting has estimated 33 runs [Note] InnoDB: Online DDL : merge-sorting current run 1 estimated 33 runs [Note] InnoDB: Online DDL : merge-sorting current run 2 estimated 17 runs [Note] InnoDB: Online DDL : merge-sorting current run 3 estimated 9 runs [Note] InnoDB: Online DDL : merge-sorting current run 4 estimated 5 runs [Note] InnoDB: Online DDL : merge-sorting current run 5 estimated 3 runs [Note] InnoDB: Online DDL : merge-sorting current run 6 estimated 2 runs [Note] InnoDB: Online DDL : End of merge-sorting index PRIMARY (1 / 3) [Note] InnoDB: Online DDL : Start building index PRIMARY (1 / 3), estimated cost : 27.0395 [Note] InnoDB: Online DDL : End of building index PRIMARY (1 / 3) [Note] InnoDB: Online DDL : Completed [Note] InnoDB: Online DDL : Start merge-sorting index ux1 (2 / 3), estimated cost : 5.7895 [Note] InnoDB: Online DDL : merge-sorting has estimated 2 runs [Note] InnoDB: Online DDL : merge-sorting current run 1 estimated 2 runs [Note] InnoDB: Online DDL : End of merge-sorting index ux1 (2 / 3) [Note] InnoDB: Online DDL : Start building index ux1 (2 / 3), estimated cost : 8.6842 [Note] InnoDB: Online DDL : End of building index ux1 (2 / 3) [Note] InnoDB: Online DDL : Completed [Note] InnoDB: Online DDL : Start merge-sorting index ix1 (3 / 3), estimated cost : 6.1842 [Note] InnoDB: Online DDL : merge-sorting has estimated 3 runs [Note] InnoDB: Online DDL : merge-sorting current run 1 estimated 3 runs [Note] InnoDB: Online DDL : merge-sorting current run 2 estimated 2 runs [Note] InnoDB: Online DDL : End of merge-sorting index ix1 (3 / 3) [Note] InnoDB: Online DDL : Start building index ix1 (3 / 3), estimated cost : 9.2763 [Note] InnoDB: Online DDL : End of building index ix1 (3 / 3) [Note] InnoDB: Online DDL : Completed
Если log_warnings равно 4 , то печатается пара других различных видов предупреждений. Например:
Если log_warnings равно 9 , то выводятся очень подробные предупреждения. Например:
MariaDB не поддерживает системную переменную log_error_verbosity , добавленную в MySQL 5.7.
Формат состоит из даты (гггг-мм-дд)и времени,идентификатора потока,затем типа ошибки (Примечание,Предупреждение или Ошибка)и сообщения об ошибке,например:
До версии MariaDB 10.1.4 формат состоял только из даты (ггммдд) и времени, за которыми следовал тип ошибки (примечание, предупреждение или ошибка) и сообщение об ошибке, например:
Дистрибутивы Unix и Linux предлагают утилиту logrotate , которая упрощает ротацию файлов журналов. Дополнительную информацию о том, как использовать эту утилиту для ротации журнала ошибок, см. в разделе Ротация журналов в Unix и Linux .
Многие сообщения об ошибках готовы из файла сообщений об ошибках,который содержит локализованные сообщения об ошибках.Если сервер не может найти этот файл при запуске,то вы можете увидеть ошибки,как показано ниже:
Если эта ошибка возникает из-за того, что файл находится в пользовательском расположении, вы можете настроить это расположение, задав системную переменную lc_messages_dir либо в командной строке, либо в группе параметров сервера в файле параметров перед запуском сервера. Например:
Если вы хотите использовать другую локаль для сообщений об ошибках, вы также можете установить системную переменную lc_messages . Например:
Содержание,воспроизводимое на этом сайте,является собственностью соответствующих владельцев,и это содержание не просматривается заранее компанией MariaDB.Взгляды,информация и мнения,выраженные в этом содержании,не обязательно представляют собой взгляды,информацию и мнения,выраженные MariaDB или любой другой стороной.
Аннотация: В этой лекции рассматриваются вопросы аудита работы системы MySql.
В MySQL имеется несколько журналов, позволяющих узнать, что происходит внутри mysqld:
| Журнал | Описание |
|---|---|
| Журнал ошибок | В нем хранятся ошибки запуска, работы или завершения работы mysqld |
| Журнал isam | В нем хранится информация обо всех изменениях таблиц ISAM. Используется только при отладке кода isam |
| Общий журнал запросов | В нем хранится информация об установленных соединениях и выполненных запросах |
| Журнал обновлений log | В нем хранятся все команды, меняющие данные; в скором времени выйдет из употребления |
| Бинарный журнал обновлений | В нем хранятся все меняющие что-либо команды. Используется для репликации |
| Журнал медленных запросов | В нем хранятся все запросы, на выполнение которых ушло больше времени, чем указано в переменной long_query_time (или запросы, не использовавшие индексов) |
Все файлы журналов хранятся в каталоге с данными mysqld. С помощью команды FLUSH LOGS можно заставить mysqld открыть файлы журналов снова (или — в некоторых случаях — переключиться на новый файл).
Журнал ошибок
Журнал ошибок содержит информацию о том, когда запускается и останавливается mysqld, а также все критические ошибки, обнаруженные в процессе работы.
В нем содержится информация о запуске и завершении работы mysqld, а также обо всех серьезных ошибках, возникших во время работы. Если произойдет неожиданное аварийное завершение работы и safe_mysqld придется перезапустить mysqld, safe_mysqld внесет в этот файл соответствующую запись. Кроме того, в этот журнал заносится предупреждение в том случае, если mysqld обнаружит таблицу, нуждающуюся в автоматической проверке или исправлении.
Все ошибки mysqld записывает в stderr, который сценарий safe_mysqld перенаправляет в файл с именем ‘hostname’.err (в Windows mysqld сохраняет его в каталоге mysqldatamysql.err ).
В некоторых ОС в журнал включается распечатка части стека погибшего mysqld. С помощью этой информации можно определить причину сбоя.
Начиная с MySQL 4.0.10 можно указать, где именно mysqld должен сохранять журнал ошибок, с помощью опции -log-error[=filename]. Если имя файла не задается, то тогда mysqld будет использовать mysql-data-dir/’hostname’.err на Unix и mysqldatamysql.err на windows.
Если вы выполняете FLUSH LOGS старый файл будет сохранен с префиксом -old и mysqld создаст новый пустой журнал.
На старых версиях MySQL журнал ошибок велся скриптом mysqld_safe, который перенаправлял вывод в файл ‘hostname’.err. В старых версиях можно было изменить имя этого файла опцией -err-log=filename.
Если вы не указываете -log-error или используете опцию -console, то ошибки будут выводиться на stderr (на терминал).
В Windows вывод всегда пишется в .err —файл, если -console не была указана.
Общий журнал запросов
Если вы хотите знать обо всем, что происходит с mysqld, нужно запустить систему с ключом -log[=file]. После этого информация обо всех соединениях и запросах будет записываться в файл журнала (по умолчанию ему дается имя ‘hostname’.log ). Этот журнал может оказаться полезным, если вы подозреваете наличие ошибки в клиентском ПО и хотите выяснить, что, по мнению mysqld, клиент передал базе.
Старые версии скрипта mysql.server (с MySQL 3.23.4 по 3.23.8) передавали safe_mysqld опцию -log (включить общий журнал запросов). Если вам нужна большая производительность при запуске MySQL в промышленной эксплуатации, вы можете удалить опцию -log из mysql.server или поменять ее на -log-bin..
Записи в журнал заносятся по мере получения mysqld запросов. Порядок их занесения может быть иным, чем порядок выполнения команд. В этом и заключается основное отличие данного журнала от журналов обновлений и бинарных журналов, в которые информация заносится по мере выполнения запросов, но до отмены блокировок.
Журнал обновлений (update)
Обратите внимание: журнал обновлений (update) применялся в старых версиях и сейчас заменен бинарным журналом (binary). С этим журналом можно производить те же операции, что и с журналом обновлений.
При запуске с ключом -log-update[=file_name] mysqld создает журнал, в который заносятся все команды SQL, обновляющие данные. Если имя файла не задано, по умолчанию ему присваивается имя хоста. Если файлу присвоено имя, не содержащее пути доступа к нему, этот файл сохраняется в каталоге с данными. Если у имени file_name нет расширения, mysqld даст файлу примерно такое имя: file_name.###, где ### — номер, увеличивающийся при каждом выполнении команд mysqladmin refresh, mysqladmin flush-logs, FLUSH LOGS или при перезапуске сервера.
Обратите внимание: чтобы вышеописанная схема могла работать, нельзя самостоятельно создавать файлы с тем же именем, что и у журнала обновлений, а также с некоторыми расширениями, которые могут быть восприняты как номер, в каталоге, использующемся для хранения этого журнала!
При запуске с ключами -log или -l mysqld создает общий журнал в файле с именем hostname.log, причем перезапуски и обновления не приводят к созданию нового файла журнала (хотя существующий при таких операциях закрывается и затем открывается вновь). В таком случае скопировать его (в Unix) можно так:
mv hostname.log hostname-old.log mysqladmin flush-logs cp hostname-old.log to-backup-directory rm hostname-old.log
Журнал обновлений работает избирательно — в него попадают только те команды, которые действительно обновляют данные. Команда UPDATE или DELETE, выражение WHERE которой не находит совпадающих строк, в журнал не заносится — как и команды UPDATE, присваивающие столбцам те же значения, которые у них были до «обновления».
Запись в журнал осуществляется сразу по завершении работы запроса, но до того, как будут сняты блокировки. Таким образом обеспечивается уверенность в том, что журнал ведется именно в порядке выполнения запросов.
При желании обновить базу в соответствии с данными журналов обновлений можно воспользоваться следующей командой (при условии, что имена файлов журналов соответствуют форме file_name.### ):
shell> ls -l -t -r file_name.[0-9]* | xargs cat | mysql
ls расставляет все файлы журналов в правильном порядке.
Эта возможность может пригодиться в случае, если возникнет необходимость (в результате серьезного сбоя) привести базу в соответствие с резервной копией и затем повторить все обновления, произошедшие с момента создания копии и до сбоя.