Пароль к серверу баз данных утерян
В случае утери пароля создайте новый, выполнив следующие команды.
Остановите MySQL командой:
# service mysql stop - ОС Centos 6/Debian/Ubuntu # systemctl stop mariadb - ОС Centos 7
либо
# systemctl stop mysqld
Выполните запуск MySQL без учета прав доступа командой:
# mysqld_safe --skip-grant-tables &
Зайдите пользователем root командой:
# mysql -uroot
Измените пароль:
# use mysql;
# UPDATE user SET Password=PASSWORD("mypassword") WHERE User='root';
# FLUSH PRIVILEGES;
Перезагрузите сервер баз данных с учетом прав доступа командой:
# service mysqld restart - ОС Centos 6/Debian/Ubuntu # systemctl restart mariadb - ОС Centos 7
либо
# systemctl restart mysqld
Выполните вход на MySQL сервер с новым паролем:
# mysql -uroot -p mypassword
Как просмотреть перечень ошибок MySQL сервера?
Для получения списка ошибок сервера баз данных просмотрите его лог-файлы. Для каждой ОС и файловой системы они располагаются в разных местах. Чтобы определить, где находятся лог-файлы MySQL на вашем сервере, подключитесь к серверу через консоль (например, Putty) и выполните команду, которая найдет файл my.cnf:
find / -name ‘my.cnf’
Результатом выполнения этой команды будут пути, по которым находится файл с этим именем.

Откройте любым редактором, например vi, найденный файл и найдите строки, начинающиеся с “log” или “log-error”
vi /etc/my.cnf

Откройте редактором лог-файл по найденному пути и просмотрите ошибки.

Если в файле my.cnf нет строк, указывающих на лог-файлы, это значит, что контроль ошибок (логирование) не включен. Включите эту функцию, добавив в my.cnf строку:
[mysqld] log-error=/var/log/mysql.log где mysql.log – новый файл, куда будут записываться ошибки.
Создайте его и наделите привилегиями командами:
touch /var/log/mysql.log chown mysql:mysql /var/log/mysql* chmod 640 /var/log/mysql*
При необходимости просмотр лог-файла можно запустить в фоновом режиме, чтобы параллельно запускать другие директивы. Для этого выполните команду:
tail –f /var/log/mysql.log &
Возможные ошибки в лог-файле и их решение
В лог-файле или в браузере выдается ошибка:

Сообщение говорит о том, что в одной из баз данных появилась поврежденная таблица, которую можно восстановить. Для этого подключитесь через консоль к серверу и выполните команду проверки всех таблиц на целостность:
mysqlcheck --repair --analyze --optimize --all-databases -u<USER> –p<PASSWORD>
В случае ошибки запустите несколько команд:
mysqlcheck --repair --all-databases -u<USER> –p<PASSWORD> mysqlcheck --analyze --all-databases -u<USER> –p<PASSWORD> mysqlcheck --optimize --all-databases -u<USER> –p<PASSWORD> где <USER> - пользователь базы данных, <PASSWORD> - пароль.
Если вы знаете, какая именно база данных повреждена, выполните команду:
mysqlcheck --repair --analyze --optimize <DB> -u<USER> -p<PASSWORD> где <USER> - пользователь базы данных, <PASSWORD> - пароль, <BD> - имя поврежденной базы.
Возникает ошибка вида:

Сообщение говорит о том, что запрещен доступ для пользователя user_xxx к базе данных или какой-то ее таблице.
Зайдите в ISPmanager, перейдите в раздел «Базы данных» — нажмите кнопку «Управление серверами БД», двойным кликом на имени сервера баз данных откройте его настройки.
Проверьте, что указанные данные в полях «Имя пользователя» и «Пароль» соответствуют тем, которые находятся в настройках сайта для подключения к этой БД.
На сайте возникает ошибка вида «Не удалось подключиться к базе данных»
Варианты сообщения об ошибке в случае неудачи при подключении к базе данных могут быть следующими:

Убедитесь, что сервер баз данных MySQL запущен. Зайдите в ISPmanager а раздел «Настройки» -> «Конфигурация ПО» и проверьте, что в списке возможностей присутствует строка «Сервер СУБД MySQL» и лампочка в этой строке зелёного цвета. Если лампочка выключена, то выделите строку и нажмите «Установить» на панели инструментов.
Если проблема не исчезла, то подключитесь к серверу через консоль и перезапустите MySQL командой:
/etc/init.d/mysqld restart - ОС Centos 6, Debian systemctl restart mysqld - ОС Centos 7
Проверьте, что сервер корректно запустился, выполнив команду, которая выводит список процессов MySQL:
ps axuw | grep mysql
Если в результате не вывелось ни одного процесса, то MySQL не запустился.
Не удается запустить MySQL
Попробуйте запустить MySQL через панель управления ISPmanager. Если не получилось, то подключитесь к серверу по SSH и попробуйте запустить MySQL через консоль командой:
/etc/init.d/mysqld restart - ОС Centos 6, Debian systemctl restart mariadb - ОС Centos 7
Если MySQL не запускается через консоль, вы получите сообщение об ошибке вида:
Проверьте свободное место на диске командой
df -h

Команда
du –hs /*
выведет, сколько места занимает каждая директория.

Если свободного места осталось мало, освободите его, очистив в первую очередь лог-файлы MySQL и других служб.
Перезапустите MySQL через консоль командами, приведенными выше.
Если проблема сохранилась, внимательно изучите записи в лог-файле MySQL, начинающиеся с [ERROR]. Например, запись Error while setting value ‘—read_buffer_size=256K’ to ‘sort_buffer_size’ означает, что директива sort_buffer_size в конфигурационном файле MySQL, прописана не верно.
I’ve read that Mysql server creates a log file where it keeps a record of all activities — like when and what queries execute.
Can anybody tell me where it exists in my system? How can I read it?
Basically, I need to back up the database with different input [backup between two dates] so I think I need to use log file here, that’s why I want to do it…
I think this log must be secured somehow because sensitive information such as usernames and password may be logged [if any query require this]; so may it be secured, not easily able to be seen?
I have root access to the system, how can I see the log?
When I try to open /var/log/mysql.log it is empty.
This is my config file:
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
log = /var/log/mysql/mysql.log
binlog-do-db=zero
user = mysql
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
skip-external-locking
bind-address = 127.0.0.1
#
# * Fine Tuning
#
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
general_log_file = /var/log/mysql/mysql.log
general_log = 1
kenorb
149k79 gold badges667 silver badges722 bronze badges
asked Mar 26, 2011 at 11:21
![]()
Here is a simple way to enable them. In mysql we need to see often 3 logs which are mostly needed during any project development.
-
The Error Log. It contains information about errors that occur while
the server is running (also server start and stop) -
The General Query Log. This is a general record of what mysqld is
doing (connect, disconnect, queries) -
The Slow Query Log. Ιt consists of «slow» SQL statements (as
indicated by its name).
By default no log files are enabled in MYSQL. All errors will be shown in the syslog (/var/log/syslog).
To Enable them just follow below steps:
step1: Go to this file (/etc/mysql/conf.d/mysqld_safe_syslog.cnf) and remove or comment those line.
step2: Go to mysql conf file (/etc/mysql/my.cnf) and add following lines
To enable error log add following
[mysqld_safe]
log_error=/var/log/mysql/mysql_error.log
[mysqld]
log_error=/var/log/mysql/mysql_error.log
To enable general query log add following
general_log_file = /var/log/mysql/mysql.log
general_log = 1
To enable Slow Query Log add following
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 2
log-queries-not-using-indexes
step3: save the file and restart mysql using following commands
service mysql restart
To enable logs at runtime, login to mysql client (mysql -u root -p) and give:
SET GLOBAL general_log = 'ON';
SET GLOBAL slow_query_log = 'ON';
Finally one thing I would like to mention here is I read this from a blog. Thanks. It works for me.
Click here to visit the blog
Nik
2,7252 gold badges23 silver badges25 bronze badges
answered Apr 2, 2015 at 9:52
![]()
loyolaloyola
3,7652 gold badges24 silver badges18 bronze badges
10
The MySQL logs are determined by the global variables such as:
log_errorfor the error message log;general_log_filefor the general query log file (if enabled bygeneral_log);slow_query_log_filefor the slow query log file (if enabled byslow_query_log);
To see the settings and their location, run this shell command:
mysql -se "SHOW VARIABLES" | grep -e log_error -e general_log -e slow_query_log
To print the value of error log, run this command in the terminal:
mysql -e "SELECT @@GLOBAL.log_error"
To read content of the error log file in real time, run:
sudo tail -f $(mysql -Nse "SELECT @@GLOBAL.log_error")
Note: Hit Control—C when finish
When general log is enabled, try:
sudo tail -f $(mysql -Nse "SELECT CONCAT(@@datadir, @@general_log_file)")
To use mysql with the password access, add -p or -pMYPASS parameter. To to keep it remembered, you can configure it in your ~/.my.cnf, e.g.
[client]
user=root
password=root
So it’ll be remembered for the next time.
answered Jun 7, 2016 at 17:09
kenorbkenorb
149k79 gold badges667 silver badges722 bronze badges
2
You have to activate the query logging in mysql.
-
edit /etc/my.cnf
[mysqld] log=/tmp/mysql.log
-
restart the computer or the mysqld service
service mysqld restart
-
open phpmyadmin/any application that uses mysql/mysql console and run a query
-
cat /tmp/mysql.log( you should see the query )
Nik
2,7252 gold badges23 silver badges25 bronze badges
answered Mar 26, 2011 at 11:28
![]()
johnlemonjohnlemon
20.5k40 gold badges118 silver badges178 bronze badges
2
From the MySQL reference manual:
By default, all log files are created in the data directory.
Check /var/lib/mysql folder.
kenorb
149k79 gold badges667 silver badges722 bronze badges
answered Mar 26, 2011 at 11:29
![]()
Mark NenadovMark Nenadov
6,2415 gold badges22 silver badges29 bronze badges
5
In my (I have LAMP installed) /etc/mysql/my.cnf file I found following, commented lines in [mysqld] section:
general_log_file = /var/log/mysql/mysql.log
general_log = 1
I had to open this file as superuser, with terminal:
sudo geany /etc/mysql/my.cnf
(I prefer to use Geany instead of gedit or VI, it doesn’t matter)
I just uncommented them & save the file then restart MySQL with
sudo service MySQL restart
Run several queries, open the above file (/var/log/mysql/mysql.log) and the log was there 🙂
![]()
answered Apr 2, 2014 at 13:04
LineLine
1,4913 gold badges18 silver badges41 bronze badges
1
Enter MySQL/MariaDB server command-line tool as root
- Set file path (you can replace general.log with the file name of your choice).
SET GLOBAL general_log_file=’/var/log/mysql/general.log’;
- Set log file format
SET GLOBAL log_output = ‘FILE’;
- Enable the server general log
SET GLOBAL general_log = ‘ON’;
- Check your configurations in global configuration variables.
SHOW VARIABLES LIKE «general_log%»;

- Enter
exitto leave MySQL command-line and Tail your queries by
tail -f /var/log/mysql/general.log
or
less /var/log/mysql/general.log
- To disable the general server log
SET GLOBAL general_log = ‘OFF’;
answered Jun 7, 2022 at 12:28
To complement loyola’s answer it is worth mentioning that as of MySQL 5.1 log_slow_queries is deprecated and is replaced with slow-query-log
Using log_slow_queries will cause your service mysql restart or service mysql start to fail
answered Sep 9, 2016 at 14:54
![]()
In addition to the answers above you can pass in command line parameters to the mysqld process for logging options instead of manually editing your conf file. For example, to enable general logging and specifiy a file:
mysqld --general-log --general-log-file=/var/log/mysql.general.log
Confirming other answers above, mysqld --help --verbose gives you the values from the conf file (so running with command line options general-log is FALSE); whereas mysql -se "SHOW VARIABLES" | grep -e log_error -e general_log gives:
general_log ON
general_log_file /var/log/mysql.general.log
Use slightly more compact syntax for the error log:
mysqld --general-log --general-log-file=/var/log/mysql.general.log --log-error=/var/log/mysql.error.log
answered Aug 22, 2016 at 11:02
![]()
br3w5br3w5
4,2834 gold badges32 silver badges42 bronze badges
shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory
![]()
Shaunak D
20.5k10 gold badges45 silver badges78 bronze badges
answered Apr 15, 2015 at 13:27
1
Журналы событий — первый и самый простой инструмент для определения статуса системы и выявления ошибок. Основных логов в MySQL четыре:
Помогаем

- Error Log — стандартный лог ошибок, которые собираются во время работы сервера (в том числе start и stop);
- Binary Log — лог всех команд изменения БД, нужен для репликации и бэкапов;
- General Query Log — основной лог запросов;
- Slow Query Log — лог медленных запросов.
Курс
БІЗНЕС-АНАЛІТИК В IT
Опануйте професію бізнес-аналітика в ІТ та заробляйте від $700 на початку кар’єри.
РЕЄСТРУЙТЕСЯ!

Лог ошибок
Этот журнал содержит все ошибки, которые произошли во время работы сервера, включая критические ошибки, а также остановки, включения сервера и предупреждения (warnings). С него нужно начать в случае сбоя системы. По умолчанию все ошибки выводятся в консоль (stderr), также можно записывать ошибки в syslog (по умолчанию в Debian) или отдельный лог-файл:
log_error=/var/log/mysql/mysql_error.log
Ошибки будут писаться в mysql_error.log
Рекомендуем держать этот журнал включенным для быстрого определения ошибок. А для понимания, что значит та или иная ошибка, в MySQL присутствует утилита [http://dev.mysql.com/doc/refman/5.7/en/perror.html 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 general_log = 1
Включает лог и указывает расположение файла
Также его можно включить/отключить во время работы сервера MySQL:
SET GLOBAL general_log = 'ON'; SET GLOBAL general_log = 'OFF';
Для применения не нужно перезагружать сервер
Лог медленных запросов
Журнал пригодится для определения медленных, то есть неэффективных запросов. Подробнее читайте в этой статье.
Просмотр логов
Для просмотра логов на Debian (Ubuntu) нужно выполнить:
# Лог ошибок tail -f /var/log/syslog #Лог запросов tail -f /var/log/mysql/mysql.log # Лог медленных запросов tail -f /var/log/mysql/mysql-slow.log
Если логи не указаны отдельно, то находятся в /var/lib/mysql
Ротация логов
Не забывайте сжимать (архивировать, ротировать) файлы логов, чтобы они занимали меньше места на сервере. Для этого используйте утилиту logrotate, отредактировав файл конфигурации /etc/logrotate.d/mysql-server:
# - I put everything in one block and added sharedscripts, so that mysql gets
# flush-logs'd only once.
# Else the binary logs would automatically increase by n times every day.
# - The error log is obsolete, messages go to syslog now.
/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log {
daily
rotate 7
missingok
create 640 mysql adm
compress
sharedscripts
postrotate
test -x /usr/bin/mysqladmin || exit 0
# If this fails, check debian.conf!
MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"
if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
# Really no mysqld or rather a missing debian-sys-maint user?
# If this occurs and is not an error please report a bug.
#if ps cax | grep -q mysqld; then
if killall -q -s0 -umysql mysqld; then
exit 1
fi
else
$MYADMIN flush-logs
fi
endscript
}
Сжимает и архивирует нужные логи, очищает файлы
DDL Log
MySQL также ведет лог языка описания данных. В него собираются данные операций типа DROP_TABLE and ALTER_TABLE. Лог используется для восстановления после сбоев, которые произошли во время выполнения таких операций. [http://dev.mysql.com/doc/refman/5.7/en/ddl-log.html DDL Log] — бинарный файл, не предназначенный для чтения пользователем, поэтому не модифицируйте и не удаляйте его.
Самое главное
Всегда включайте лог ошибок, используйте лог запросов для проверки соединения приложения с базой данных, проверки запросов и работы memcached. Лог медленных запросов пригодится для оптимизации работы MySQL.
Этот текст был написан несколько лет назад. С тех пор упомянутые здесь инструменты и софт могли получить обновления. Пожалуйста, проверяйте их актуальность.
- 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 /
Всем привет! Заметка будет краткой, так как не хочу открывать лишние вкладки, для того чтобы вспомнить, где и как включать логи. Ниже будет описание о том, какие логи есть (кратко) и как их включить (емко).
Лог ошибок — Error Log
Если необходимо понять, по какой причине не запускается MySql сервер — error log вам в помощь. Там же еще можно прочесть сообщения о том,
По умолчанию все ошибки выводятся в консоль (stderr), в Debian ошибки пишутся в syslog, но по хорошему было бы неплохо вести этот лог в отдельном файле, а именно:
/var/log/mysql/mysql_error.log
Как его перенести?
открыв файл /etc/mysql/my.conf я нашел следующую строчку:
Error logging goes to syslog due to /etc/mysql/conf.d/mysqld_safe_syslog.cnf.
Ок, полез в файл /etc/mysql/conf.d/mysqld_safe_syslog.cnf — там следующее содержимое:
[mysqld_safe] syslog
Поняв, что все льется в syslog, я закомментировал syslog и добавил следующую строку:
log_error=/var/log/mysql/mysql_error.log
Все, логи пишутся куда нужно, и я спокоен.
ps.: Для того, чтобы понять что означают те или иные ошибки, можно воспользоваться такой штукой, как perror.
Двоичный («bin’арный») лог.
В этот лог записываются все команды изменения БД, и нужен он для репликации и восстановления. Включать его не рекомендуется, если никакой репликации не планируется, так как он требователен к ресурсам.
Включается он в файле /etc/mysql/my.conf, там нужно разкомментрировать следующие строки:
log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 5 max_binlog_size = 500M
Подробнее:
- log_bin — расположение;
- expire_logs_days — срок жизни;
- max_binlog_size — максимальный размер файла.
Лог медленных запросов — mysql-slow.log.
Он будет содержать в себе запросы, которые очень нуждаются в оптимизации. По умолчанию он отключен, включается в том же /etc/mysql/my.cnf.
Если версия MySql у вас < 5.7, то в нужно исправить следующие настройки:
log_slow_queries = /var/log/mysql/mysql-slow.log long_query_time = 1
Если версия MySql у вас > или = 5.7, то нужно исправить следующие настройки:
slow_query_log = /var/log/mysql/mysql-slow.log long_query_time = 1
Подробнее:
- log_slow_queries (slow_query_log) — путь к файлу настроек;
- long_query_time — минимальное время выполнения запроса в секундах, после которого он считается медленным.
Лог всех запросов.
Пригодиться он опять же для оптимизации и выявления ошибочных запросов, так как записывает все запросы. по умолчанию отключен. Включаем там же: /etc/mysql/my.cnf.
Настройки нужно исправить на подобные:
general_log_file = /var/log/mysql/mysql.log general_log = 1
Подробнее:
- general_log_file — месторасположение
- general_log — включение лога
Включить этот лог «на лету», без перезагрузки, мы можем и из консоли «mysql»:
SET GLOBAL general_log = 'ON'; SET GLOBAL general_log = 'OFF';
Не забываем про logrotate.
Дополнено 04/12/2017…
Как я и обещал в какой-то другой статье — «возможно статья будет дополняться».
Во первых про LogRotate, приведу скрипт который используется у меня:
cat /etc/logrotate.d/mysql-server
# - I put everything in one block and added sharedscripts, so that mysql gets
# flush-logs'd only once.
# Else the binary logs would automatically increase by n times every day.
# - The error log is obsolete, messages go to syslog now.
/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log {
daily
rotate 7
missingok
create 640 mysql adm
compress
sharedscripts
postrotate
test -x /usr/bin/mysqladmin || exit 0
# If this fails, check debian.conf!
MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"
if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
# Really no mysqld or rather a missing debian-sys-maint user?
# If this occurs and is not a error please report a bug.
#if ps cax | grep -q mysqld; then
if killall -q -s0 -umysql mysqld; then
exit 1
fi
else
$MYADMIN flush-logs
fi
endscript
}
Как вы уже поняли, он стандартный, и он прекрасно справляется со своей работой.
Нагрузка на БД
Кроме того у меня возникал вопрос: «Скажите пожалуйста какими командами в SSH вычисляется нагрузка на БД ?«..
Собственно все это можно посмотреть хоть в phpmyadmin, но так же никто не запрещает воспользоваться консольным клиентом MySQL, который так и называется: mysql 🙂
Для того, чтобы в него попасть, необходимо ввести следующую команду, а после пароль
[[email protected] ]# mysql -u root -p -h localhost Enter password: Welcome to the MySQL monitor. Commands end with ; or g. Your MySQL connection id is 7926 Server version: 5.0.45 Source distribution Type 'help;' or 'h' for help. Type 'c' to clear the buffer. mysql>
все, вы в него попали 🙂
Там мне были полезны две команды:
show status — команда предоставляет информацию по состоянию сервера.
Пример ее вывода
mysql> show status; +-----------------------------------------------+-------------+ | Variable_name | Value | +-----------------------------------------------+-------------+ | Aborted_clients | 0 | | Aborted_connects | 1 | | Binlog_cache_disk_use | 0 | | Binlog_cache_use | 0 | | Binlog_stmt_cache_disk_use | 0 | | Binlog_stmt_cache_use | 0 | | Bytes_received | 272 | | Bytes_sent | 509 | | Com_admin_commands | 0 | | Com_assign_to_keycache | 0 | | Com_alter_db | 0 | | Com_alter_db_upgrade | 0 | | Com_alter_event | 0 | | Com_alter_function | 0 | | Com_alter_procedure | 0 | | Com_alter_server | 0 | | Com_alter_table | 0 | | Com_alter_tablespace | 0 | | Com_alter_user | 0 | | Com_analyze | 0 | | Com_begin | 0 | | Com_binlog | 0 | | Com_call_procedure | 0 | | Com_change_db | 0 | | Com_change_master | 0 | | Com_check | 0 | | Com_checksum | 0 | | Com_commit | 0 | | Com_create_db | 0 | | Com_create_event | 0 | | Com_create_function | 0 | | Com_create_index | 0 | | Com_create_procedure | 0 | | Com_create_server | 0 | | Com_create_table | 0 | | Com_create_trigger | 0 | | Com_create_udf | 0 | | Com_create_user | 0 | | Com_create_view | 0 | | Com_dealloc_sql | 0 | | Com_delete | 0 | | Com_delete_multi | 0 | | Com_do | 0 | | Com_drop_db | 0 | | Com_drop_event | 0 | | Com_drop_function | 0 | | Com_drop_index | 0 | | Com_drop_procedure | 0 | | Com_drop_server | 0 | | Com_drop_table | 0 | | Com_drop_trigger | 0 | | Com_drop_user | 0 | | Com_drop_view | 0 | | Com_empty_query | 0 | | Com_execute_sql | 0 | | Com_flush | 0 | | Com_get_diagnostics | 0 | | Com_grant | 0 | | Com_ha_close | 0 | | Com_ha_open | 0 | | Com_ha_read | 0 | | Com_help | 0 | | Com_insert | 0 | | Com_insert_select | 0 | | Com_install_plugin | 0 | | Com_kill | 0 | | Com_load | 0 | | Com_lock_tables | 0 | | Com_optimize | 0 | | Com_preload_keys | 0 | | Com_prepare_sql | 0 | | Com_purge | 0 | | Com_purge_before_date | 0 | | Com_release_savepoint | 0 | | Com_rename_table | 0 | | Com_rename_user | 0 | | Com_repair | 0 | | Com_replace | 0 | | Com_replace_select | 0 | | Com_reset | 0 | | Com_resignal | 0 | | Com_revoke | 0 | | Com_revoke_all | 0 | | Com_rollback | 0 | | Com_rollback_to_savepoint | 0 | | Com_savepoint | 0 | | Com_select | 1 | | Com_set_option | 0 | | Com_signal | 0 | | Com_show_binlog_events | 0 | | Com_show_binlogs | 0 | | Com_show_charsets | 0 | | Com_show_collations | 0 | | Com_show_create_db | 0 | | Com_show_create_event | 0 | | Com_show_create_func | 0 | | Com_show_create_proc | 0 | | Com_show_create_table | 0 | | Com_show_create_trigger | 0 | | Com_show_databases | 0 | | Com_show_engine_logs | 0 | | Com_show_engine_mutex | 0 | | Com_show_engine_status | 0 | | Com_show_events | 0 | | Com_show_errors | 0 | | Com_show_fields | 0 | | Com_show_function_code | 0 | | Com_show_function_status | 0 | | Com_show_grants | 0 | | Com_show_keys | 0 | | Com_show_master_status | 0 | | Com_show_open_tables | 0 | | Com_show_plugins | 0 | | Com_show_privileges | 0 | | Com_show_procedure_code | 0 | | Com_show_procedure_status | 0 | | Com_show_processlist | 1 | | Com_show_profile | 0 | | Com_show_profiles | 0 | | Com_show_relaylog_events | 0 | | Com_show_slave_hosts | 0 | | Com_show_slave_status | 0 | | Com_show_status | 1 | | Com_show_storage_engines | 0 | | Com_show_table_status | 0 | | Com_show_tables | 0 | | Com_show_triggers | 0 | | Com_show_variables | 0 | | Com_show_warnings | 0 | | Com_slave_start | 0 | | Com_slave_stop | 0 | | Com_stmt_close | 0 | | Com_stmt_execute | 0 | | Com_stmt_fetch | 0 | | Com_stmt_prepare | 0 | | Com_stmt_reprepare | 0 | | Com_stmt_reset | 0 | | Com_stmt_send_long_data | 0 | | Com_truncate | 0 | | Com_uninstall_plugin | 0 | | Com_unlock_tables | 0 | | Com_update | 0 | | Com_update_multi | 0 | | Com_xa_commit | 0 | | Com_xa_end | 0 | | Com_xa_prepare | 0 | | Com_xa_recover | 0 | | Com_xa_rollback | 0 | | Com_xa_start | 0 | | Compression | OFF | | Connection_errors_accept | 0 | | Connection_errors_internal | 0 | | Connection_errors_max_connections | 0 | | Connection_errors_peer_address | 0 | | Connection_errors_select | 0 | | Connection_errors_tcpwrap | 0 | | Connections | 5 | | Created_tmp_disk_tables | 0 | | Created_tmp_files | 6 | | Created_tmp_tables | 0 | | Delayed_errors | 0 | | Delayed_insert_threads | 0 | | Delayed_writes | 0 | | Flush_commands | 1 | | Handler_commit | 0 | | Handler_delete | 0 | | Handler_discover | 0 | | Handler_external_lock | 0 | | Handler_mrr_init | 0 | | Handler_prepare | 0 | | Handler_read_first | 0 | | Handler_read_key | 0 | | Handler_read_last | 0 | | Handler_read_next | 0 | | Handler_read_prev | 0 | | Handler_read_rnd | 0 | | Handler_read_rnd_next | 0 | | Handler_rollback | 0 | | Handler_savepoint | 0 | | Handler_savepoint_rollback | 0 | | Handler_update | 0 | | Handler_write | 0 | | Innodb_buffer_pool_dump_status | not started | | Innodb_buffer_pool_load_status | not started | | Innodb_buffer_pool_pages_data | 323 | | Innodb_buffer_pool_bytes_data | 5292032 | | Innodb_buffer_pool_pages_dirty | 0 | | Innodb_buffer_pool_bytes_dirty | 0 | | Innodb_buffer_pool_pages_flushed | 1 | | Innodb_buffer_pool_pages_free | 7866 | | Innodb_buffer_pool_pages_misc | 2 | | Innodb_buffer_pool_pages_total | 8191 | | Innodb_buffer_pool_read_ahead_rnd | 0 | | Innodb_buffer_pool_read_ahead | 0 | | Innodb_buffer_pool_read_ahead_evicted | 0 | | Innodb_buffer_pool_read_requests | 2642 | | Innodb_buffer_pool_reads | 324 | | Innodb_buffer_pool_wait_free | 0 | | Innodb_buffer_pool_write_requests | 1 | | Innodb_data_fsyncs | 5 | | Innodb_data_pending_fsyncs | 0 | | Innodb_data_pending_reads | 0 | | Innodb_data_pending_writes | 0 | | Innodb_data_read | 5378048 | | Innodb_data_reads | 336 | | Innodb_data_writes | 5 | | Innodb_data_written | 34304 | | Innodb_dblwr_pages_written | 1 | | Innodb_dblwr_writes | 1 | | Innodb_have_atomic_builtins | ON | | Innodb_log_waits | 0 | | Innodb_log_write_requests | 0 | | Innodb_log_writes | 1 | | Innodb_os_log_fsyncs | 3 | | Innodb_os_log_pending_fsyncs | 0 | | Innodb_os_log_pending_writes | 0 | | Innodb_os_log_written | 512 | | Innodb_page_size | 16384 | | Innodb_pages_created | 0 | | Innodb_pages_read | 323 | | Innodb_pages_written | 1 | | Innodb_row_lock_current_waits | 0 | | Innodb_row_lock_time | 0 | | Innodb_row_lock_time_avg | 0 | | Innodb_row_lock_time_max | 0 | | Innodb_row_lock_waits | 0 | | Innodb_rows_deleted | 0 | | Innodb_rows_inserted | 0 | | Innodb_rows_read | 0 | | Innodb_rows_updated | 0 | | Innodb_num_open_files | 5 | | Innodb_truncated_status_writes | 0 | | Innodb_available_undo_logs | 128 | | Key_blocks_not_flushed | 0 | | Key_blocks_unused | 13396 | | Key_blocks_used | 0 | | Key_read_requests | 0 | | Key_reads | 0 | | Key_write_requests | 0 | | Key_writes | 0 | | Last_query_cost | 0.000000 | | Last_query_partial_plans | 0 | | Max_used_connections | 1 | | Not_flushed_delayed_rows | 0 | | Open_files | 16 | | Open_streams | 0 | | Open_table_definitions | 67 | | Open_tables | 60 | | Opened_files | 115 | | Opened_table_definitions | 0 | | Opened_tables | 0 | | Performance_schema_accounts_lost | 0 | | Performance_schema_cond_classes_lost | 0 | | Performance_schema_cond_instances_lost | 0 | | Performance_schema_digest_lost | 0 | | Performance_schema_file_classes_lost | 0 | | Performance_schema_file_handles_lost | 0 | | Performance_schema_file_instances_lost | 0 | | Performance_schema_hosts_lost | 0 | | Performance_schema_locker_lost | 0 | | Performance_schema_mutex_classes_lost | 0 | | Performance_schema_mutex_instances_lost | 0 | | Performance_schema_rwlock_classes_lost | 0 | | Performance_schema_rwlock_instances_lost | 0 | | Performance_schema_session_connect_attrs_lost | 0 | | Performance_schema_socket_classes_lost | 0 | | Performance_schema_socket_instances_lost | 0 | | Performance_schema_stage_classes_lost | 0 | | Performance_schema_statement_classes_lost | 0 | | Performance_schema_table_handles_lost | 0 | | Performance_schema_table_instances_lost | 0 | | Performance_schema_thread_classes_lost | 0 | | Performance_schema_thread_instances_lost | 0 | | Performance_schema_users_lost | 0 | | Prepared_stmt_count | 0 | | Qcache_free_blocks | 1 | | Qcache_free_memory | 16759680 | | Qcache_hits | 0 | | Qcache_inserts | 0 | | Qcache_lowmem_prunes | 0 | | Qcache_not_cached | 1 | | Qcache_queries_in_cache | 0 | | Qcache_total_blocks | 1 | | Queries | 8 | | Questions | 3 | | Select_full_join | 0 | | Select_full_range_join | 0 | | Select_range | 0 | | Select_range_check | 0 | | Select_scan | 0 | | Slave_heartbeat_period | | | Slave_last_heartbeat | | | Slave_open_temp_tables | 0 | | Slave_received_heartbeats | | | Slave_retried_transactions | | | Slave_running | OFF | | Slow_launch_threads | 0 | | Slow_queries | 0 | | Sort_merge_passes | 0 | | Sort_range | 0 | | Sort_rows | 0 | | Sort_scan | 0 | | Ssl_accept_renegotiates | 0 | | Ssl_accepts | 0 | | Ssl_callback_cache_hits | 0 | | Ssl_cipher | | | Ssl_cipher_list | | | Ssl_client_connects | 0 | | Ssl_connect_renegotiates | 0 | | Ssl_ctx_verify_depth | 0 | | Ssl_ctx_verify_mode | 0 | | Ssl_default_timeout | 0 | | Ssl_finished_accepts | 0 | | Ssl_finished_connects | 0 | | Ssl_server_not_after | | | Ssl_server_not_before | | | Ssl_session_cache_hits | 0 | | Ssl_session_cache_misses | 0 | | Ssl_session_cache_mode | NONE | | Ssl_session_cache_overflows | 0 | | Ssl_session_cache_size | 0 | | Ssl_session_cache_timeouts | 0 | | Ssl_sessions_reused | 0 | | Ssl_used_session_cache_entries | 0 | | Ssl_verify_depth | 0 | | Ssl_verify_mode | 0 | | Ssl_version | | | Table_locks_immediate | 70 | | Table_locks_waited | 0 | | Table_open_cache_hits | 0 | | Table_open_cache_misses | 0 | | Table_open_cache_overflows | 0 | | Tc_log_max_pages_used | 0 | | Tc_log_page_size | 0 | | Tc_log_page_waits | 0 | | Threads_cached | 0 | | Threads_connected | 1 | | Threads_created | 1 | | Threads_running | 1 | | Uptime | 147542 | | Uptime_since_flush_status | 147542 | +-----------------------------------------------+-------------+ 341 rows in set (0,00 sec)
Подробное описание команды
Команда SHOW STATUS предоставляет информацию по состоянию сервера (как mysqladmin extended-status). Приведенные выше переменные состояния имеют следующие значения:
- Aborted_clients — Количество соединений, отмененных по причине отключения клиента без надлежащего закрытия соединения. See Раздел A.2.9, «Коммуникационные ошибки / Оборванные соединения».
- Aborted_connects — Количество неудачных попыток подсоединения к серверу MySQL. See Раздел A.2.9, «Коммуникационные ошибки / Оборванные соединения».
- Bytes_received — Количество байтов, полученных от всех клиентов.
- Bytes_sent — Количество байтов, отправленных всем клиентам.
- Com_xxx — Количество запусков каждой команды xxx.
- Connections — Количество попыток подсоединения к серверу MySQL.
- Created_tmp_tables — Количество неявных временных таблиц на диске, созданных во время выполнения операторов.
- Created_tmp_tables — Количество неявных временных таблиц в памяти, созданных во время выполнения операторов.
- Created_tmp_files — Количество созданных временных файлов mysqld.
- Delayed_insert_threads — Количество используемых потоков вставки данных в режиме insert delayed.
- Delayed_writes — Количество строк, вставленных при помощи команды INSERT DELAYED.
- Delayed_errors — Количество записанных при помощи команды INSERT DELAYED строк, в которых произошли какие-либо ошибки (возможно, duplicate key).
- Flush_commands — Количество запущенных команд FLUSH.
- Handler_commit — Количество внутренних команд COMMIT.
- Handler_delete — Количество удалений строки из таблицы.
- Handler_read_first — Количество считываний из индекса первой записи. Если это значение высокое, то, по всей вероятности, сервер осуществляет много полных индексных сканирований, например, SELECT col1 FROM foo, предполагая, что col1 проиндексирован.
- Handler_read_key — Количество запросов на чтение строки, основанных на ключе. Высокое значение переменной говорит о том, что ваши запросы и таблицы проиндексированы надлежащим образом.
- Handler_read_next — Количество запросов на чтение следующей строки в порядке расположения ключей. Это значение будет увеличиваться, если производится запрос индексного столбца с ограничением по размеру. Значение также увеличивается во время проведения индексного сканирования.
- Handler_read_prev — Количество запросов на чтение предыдущей строки в порядке расположения ключей. В большинстве случаев используется для оптимизации ORDER BY … DESC.
- Handler_read_rnd — Количество запросов на чтение строки, основанных на фиксированной позиции. Значение будет высоким, если выполняется много запросов, требующих сортировки результатов.
- Handler_read_rnd_next — Количество запросов на чтение следующей строки из файла данных. Данное значение будет высоким, если производится много сканирований таблиц. Обычно это означает, что ваши таблицы не проиндексированы надлежащим образом или ваши запросы не используют преимущества индексов.
- Handler_rollback — Количество внутренних команд ROLLBACK.
- Handler_update — Количество запросов на обновление строки в таблице.
- Handler_write — Количество запросов на вставку строки в таблицу.
- Key_blocks_used — Количество используемых блоков в кэше ключей.
- Key_read_requests — Количество запросов на чтение блока ключей из кэша.
- Key_reads — Количество физических считываний блока ключей с диска.
- Key_write_requests — Количество запросов на запись блока ключей в кэш.
- Key_writes — Количество физических записей блоков ключей на диск.
- Max_used_connections — Максимальное количество одновременно используемых соединений.
- Not_flushed_key_blocks — Блоки ключей в кэше ключей, которые были изменены, но еще не записаны на диск.
- Not_flushed_delayed_rows — Количество строк, стоящих в очереди на запись в запросах INSERT DELAY.
- Open_tables — Количество открытых таблиц.
- Open_files — Количество открытых файлов.
- Open_streams — Количество открытых потоков (в основном используется для журналирования).
- Opened_tables — Количество открывавшихся таблиц.
- Rpl_status — Статус отказобезопасной репликации (еще не используется).
- Select_full_join — Количество соединений без ключей (если это значение равно 0, необходимо внимательно проверить индексы своих таблиц).
- Select_full_range_join — Количество соединений, где был использован поиск по диапазону в справочной таблице.
- Select_range — Количество соединений, в которых использовались диапазоны в первой таблице. (Обычно это значение не критично, даже если оно велико)
Select_scan — Количество соединений, в которых проводилось первое сканирование первой таблицы. - Select_range_check — Количество соединений без ключей, в которых проверка использования ключей производится после каждой строки (если это значение равно 0, необходимо внимательно проверить индексы своих таблиц).
- Questions — Количество запросов, направленных на сервер.
- Slave_open_temp_tables — Количество временных таблиц, открытых в настоящий момент потоком подчиненного компьютера.
- Slave_running — Содержит значение ON, если это подчиненный компьютер, подключенный к головному компьютеру.
- Slow_launch_threads — Количество потоков, создание которых заняло больше, чем указано в slow_launch_time.
- Slow_queries — Количество запросов, обработка которых заняла больше времени, чем long_query_time. See Раздел 4.9.5, «Журнал медленных запросов».
- Sort_merge_passes — Количество объединений, осуществленных алгоритмом сортировки. Если это значение велико, следует увеличить sort_buffer_size.
- Sort_range — Количество сортировок, которые осуществлялись в диапазонах.
- Sort_rows — Количество отсортированных строк.
- Sort_scan — Количество сортировок, осуществленных путем сканирования таблицы.
- ssl_xxx — Переменные, используемые SSL; еще не реализовано.
- Table_locks_immediate — Количество запросов на немедленную блокировку таблицы. Доступно начиная с версии 3.23.33.
- Table_locks_waited — Количество запросов, когда немедленная блокировка не могла быть осуществлена и требовалось время на ожидание. Если это значение велико, и у вас есть проблемы с производительностью, сначала необходимо оптимизировать свои запросы, а затем либо разделить таблицы, либо использовать репликацию. Доступно начиная с версии 3.23.33.
- Threads_cached — Количество потоков в кэше потоков.
- Threads_connected — Количество открытых в настоящий момент соединений.
- Threads_created — Количество потоков, созданных для управления соединениями.
- Threads_running — Количество не простаивающих потоков.
- Uptime — Время в секундах, в течение которого сервер находится в работе.
Некоторые примечания к приведенной выше информации:
- Если значение Opened_tables велико, возможно, что значение переменной table_cache слишком мало.
- Если значение Key_reads велико, возможно, что значение переменной key_buffer_size слишком мало. Частоту неуспешных обращений к кэшу можно вычислить так: Key_reads/Key_read_requests.
- Если значение Handler_read_rnd велико, возможно, поступает слишком много запросов, требующих от MySQL полного сканирования таблиц или у вас есть соединения, которые не используют ключи надлежащим образом.
- Если значение Threads_created велико, возможно, необходимо увеличить значение переменной thread_cache_size. Частоту успешных обращений к кэшу можно вычислить при помощи Threads_created/Connections.
- Если значение Created_tmp_disk_tables велико, возможно, необходимо увеличить значение переменной tmp_table_size, чтобы временные таблицы располагались в памяти, а не на жестком диске.
show processlist — показывает, какие потоки запущены в настоящий момент. Пример ее вывода:
mysql> show processlist; +----+------+-----------+------+---------+------+-------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+------+-----------+------+---------+------+-------+------------------+ | 4 | root | localhost | NULL | Query | 0 | init | show processlist | +----+------+-----------+------+---------+------+-------+------------------+ 1 row in set (0,00 sec)
Подробное описание команды
Команда SHOW [FULL] PROCESSLIST показывает, какие потоки запущены в настоящий момент. Эту информацию также можно получить при помощи команды mysqladmin processlist. Если у вас привилегия SUPER, можно просматривать все потоки, в противном случае — только свои потоки. See Раздел 4.5.5, «Синтаксис команды KILL». Если не используется параметр FULL, будут показаны только первые 100 символов каждого запроса.
Начиная с 4.0.12, MySQL сообщает имя хоста для TCP/IP соединений как имя_хоста:клиентский_порт с тем, чтобы было проще понять, какой клиент чем занят.
Эта команда очень полезна, если выдается сообщение об ошибке ‘too many connections’ (слишком много соединений) и необходимо выяснить, что происходит. MySQL резервирует одно дополнительное соединение для клиента с привилегией SUPER, чтобы у вас всегда была возможность войти в систему и произвести проверку (предполагается, что вы не станете раздавать эту привилегию всем своим пользователям).
Некоторые состояния обычно можно увидеть в mysqladmin processlist.
- Checking table — Поток осуществляет [автоматическую] проверку таблицы.
- Closing tables — Означает, что поток записывает измененные данные таблиц на диск и закрывает использующиеся таблицы. Выполнение этой операции должно произойти быстро. Если на нее уходит значительное время, убедитесь, что диск не переполнен или что диск не используется слишком интенсивно.
- Connect Out — Подчиненный компьютер, подсоединенный к головному компьютеру.
- Copying to tmp table on disk — Набор временных результатов превысил tmp_table_size, и теперь поток изменяет таблицу временных данных, расположенную в памяти, на дисковую таблицу, чтобы сохранить память.
- Creating tmp table — Поток создает временную таблицу, чтобы хранить часть результатов для запроса.
- deleting from main table — При запуске первой части удаления нескольких таблиц удаление производится только начиная с первой таблицы.
- deleting from reference tables — При запуске второй части удаления нескольких таблиц удаляются совпадающие строки из других таблиц.
- Flushing tables — Поток запускает команду FLUSH TABLES и ожидает, пока все потоки закроют свои таблицы.
- Killed — Кто-то направил команду на закрытие потока, и поток будет закрыт при следующей проверке флага закрытия. Флаг проверяется при каждом основном цикле в MySQL, но в некоторых случаях закрытие потока может занять некоторое время. Если поток заблокирован другим потоком, закрытие будет произведено сразу после того, как другой поток снимет блокировку.
- Sending data — Поток обрабатывает строки для оператора SELECT, а также направляет данные клиенту.
- Sorting for group — Поток осуществляет сортировку в соответствии с GROUP BY.
- Sorting for order — Поток осуществляет сортировку в соответствии с ORDER BY.
- Opening tables — Это просто означает, что поток пытается открыть таблицу. Такая процедура осуществляется довольно быстро, если что-либо не мешает открытию. Например, команды ALTER TABLE или LOCK TABLE могут помешать открытию таблицы, пока выполнение команды не будет завершено.
- Removing duplicates — Запрос использовал команду SELECT DISTINCT таким образом, что MySQL не смог произвести оптимизацию на начальном этапе. Поэтому MySQL перед отправкой результатов клиенту должен выполнить дополнительное удаление всех дублирующихся строк.
- Reopen table — Поток заблокировал таблицу, но обнаружил, что после блокировки структура таблицы изменилась. Он снял блокировку, закрыл таблицу и теперь пытается повторно ее открыть.
- Repair by sorting — Код восстановления использует сортировку для создания индексов.
- Repair with keycache — Код восстановления использует создание ключей один за другим, через кэш ключей. Это намного медленнее, чем Repair by sorting.
- Searching rows for update — Поток осуществляет первую фазу — производит поиск всех совпадающих строк, чтобы затем обновить их. Это действие
необходимо выполнить, если команда UPDATE изменяет индекс, который используется для поиска указанных строк. - Sleeping — Поток ожидает, когда клиент направит ему новую команду.
- System lock — Поток ожидает получения внешней системной блокировки таблицы. Если не используется несколько серверов mysqld, которые получают доступ к одним и тем же таблицам, системную блокировку можно отключить при помощи параметра —skip-external-locking.
- Upgrading lock — Обработчик INSERT DELAYED пытается заблокировать таблицу, чтобы вставить строки.
- Updating — Поток производит поиск строк, которые необходимо обновить, и обновляет их.
- User Lock — Поток ожидает GET_LOCK().
- Waiting for tables — Поток получил уведомление, что структура таблицы изменилась, и ему необходимо повторно открыть таблицу, чтобы получить новую структуру. Чтобы повторно открыть таблицу, он должен подождать, пока ее не закроют все остальные потоки. Это уведомление выдается, если другой поток воспользовался командой FLUSH TABLES или к таблице была применена одна из следующих команд: FLUSH TABLES table_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE или OPTIMIZE TABLE. Обработчик INSERT DELAYED завершил работу со всеми вставками и ожидает новые.
Большинство состояний — это очень быстрые операции. Если потоки остаются в любом из этих состояний на протяжении большого количества секунд, то, возможно, возникла какая-то проблема, которую следует устранить.
Существует еще несколько состояний, не упомянутых выше, но большинство из них полезны только для поиска ошибок в mysqld.
Описания я взял с руководства, возможно немного не актуального, но на первых парах описаны все основные моменты. Остальное — смотрим полные версии руководства.
Источники:
- https://ruhighload.com/post/бла-бла-бла-1
- https://ruhighload.com/post/бла-бла-бла-2
- https://dev.mysql.com/doc/refman/5.7/en/perror.html
- https://unixforum.org/index.php?showtopic=92923
- http://www.arininav.ru/mysql/show-status.html
- http://www.arininav.ru/mysql/show-processlist.html
Журналы событий — первый и самый простой инструмент для определения статуса системы и выявления ошибок. Основных логов в 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/
28 января, 2019 12:25 пп
3 827 views
| Комментариев нет
LAMP Stack, LEMP Stack, MariaDB, mySQL
MySQL – это реляционная система управления базами данных (РСУБД) с открытым исходным кодом, самая популярная в мире.
Конечно, при работе с любым программным обеспечением и новички, и опытные пользователи могут столкнуться с непонятными ошибками или проблемами, которые трудно диагностировать.
Этот мануал станет отправной точкой при диагностике настроек MySQL и устранении неполадок. Здесь мы рассмотрим общие проблемы, с которыми сталкиваются многие пользователи MySQL, и предоставим рекомендации по их устранению. Мы также предоставим ссылки на официальную документацию MySQL и другие мануалы, которые могут быть полезны в некоторых случаях.
Данный мануал выполнен на основе настройки, описанной в статье Установка MySQL в Ubuntu 18.04. Если вы используете другой дистрибутив, вы можете найти соответствующее руководство в нашем Информатории.
Начало работы в MySQL
Многие пользователи MySQL впервые сталкиваются с проблемой уже в процессе установки и настройки. Мануал Установка MySQL в Ubuntu 18.04 содержит инструкции по базовой конфигурации и может быть полезным для новичков в MySQL.
Причина, по которой некоторые пользователи сталкиваются с проблемами, заключается в том, что их приложениям требуются функции базы данных, доступные только в последних релизах, но версия MySQL в репозиториях по умолчанию некоторых дистрибутивов Linux (включая Ubuntu) не очень свежая. Потому разработчики MySQL поддерживают свой собственный репозиторий программного обеспечения, который вы можете использовать для установки последней версии и регулярного ее обновления. В мануале Установка последней версии MySQL в Ubuntu 18.04 содержатся инструкции о том, как это сделать.
Логи ошибок MySQL
Часто первопричину замедлений, сбоев или другого непредвиденного поведения MySQL можно определить, проанализировав логи ошибок. В системе Ubuntu этот лог по умолчанию находится в /var/log/mysql/error.log. Во многих случаях логи ошибок проще всего прочитать с помощью программы less, утилиты командной строки, которая позволяет просматривать файлы, но не редактировать их:
sudo less /var/log/mysql/error.log
Если MySQL работает не так, как ожидалось, вы можете ввести эту команду и получить больше информации об источнике проблемы, диагностировав ошибку на основе содержимого лога.
Сброс root пароля MySQL
Если вы установили пароль root для MySQL, но потому забыли его, вы можете заблокировать себе доступ к собственным данным в СУБД. Однако если у вас есть доступ к серверу, на котором размещена ваша БД, вы сможете сбросить пароль.
Процедура подробно описана в мануале Сброс root-пароля MySQL или MariaDB в Ubuntu 18.04.
Проблемы с запросами
Иногда пользователи сталкиваются с проблемами при отправке запросов. В некоторых системах баз данных, включая MySQL, операторы запроса должны заканчиваться точкой с запятой (;), как в следующем примере:
SHOW * FROM table_name;
Если вы забудете добавить точку с запятой в конец запроса, запрос будет продолжаться в новой строке. Завершите запрос, введя точку с запятой и нажав Enter.
Некоторые пользователи сталкиваются с тем, что запросы обрабатываются чрезвычайно медленно. Один из способов определить, какой оператор является причиной замедления, – включить и просмотреть лог медленных запросов MySQL. Для этого откройте файл mysqld.cnf, который используется для настройки параметров сервера MySQL. Этот файл обычно хранится в каталоге /etc/mysql/mysql.conf.d/:
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
Просмотрите файл и найдите такой фрагмент:
. . .
#slow_query_log = 1
#slow_query_log_file = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
. . .
Эти закомментированные директивы определяют стандартные параметры конфигурации MySQL для лога медленных запросов. Вот что делает каждая из них:
- slow-query-log: значение 1 включает лог медленных запросов.
- slow-query-log-file: определяет файл, который MySQL будет использовать как лог медленных запросов. В данном случае это /var/log/mysql-slow.log.
- long_query_time: при значении 2 MySQL будет регистрировать любые запросы, выполнение которых занимает более 2 секунд.
- log_queries_not_using_indexes: эта директива будет регистрировать в файле /var/log/mysql-slow.log любые запросы, которые выполняются без индексов. Этот параметр не требуется для работы лога, но может быть полезен для выявления неэффективных запросов.
Раскомментируйте эти строки, удалив символы #. В результате вы получите:
. . .
slow_query_log = 1
slow_query_log_file = /var/log/mysql-slow.log
long_query_time = 2
log_queries_not_using_indexes
. . .
Примечание: В MySQL 8+ по умолчанию этих директив в файле mysqld.cnf нет. Вам нужно добавить в конец файла такие строки:
. . .
slow_query_log = 1
slow_query_log_file = /var/log/mysql-slow.log
long_query_time = 2
log_queries_not_using_indexes
После включения лога медленных запросов сохраните и закройте файл. Затем перезапустите MySQL:
sudo systemctl restart mysql
Эти параметры помогут найти проблемные операторы в логе медленных запросов. Вы можете сделать это с помощью less:
sudo less /var/log/mysql_slow.log
Определив запросы, вызывающие замедление, вы можете обратиться к мануалу Оптимизация запросов и таблиц MySQL и MariaDB, который поможет их оптимизировать.
Кроме того, MySQL включает оператор EXPLAIN, который предоставляет информацию о выполнении запросов. Эта страница из официальной документации MySQL рассказывает о том, как использовать EXPLAIN для выявления неэффективных запросов.
Базовые запросы описаны в мануале Запросы в MySQL.
Настройка удаленного доступа
Многие веб-сайты и приложения запускаются с веб-сервера и базы данных, размещенных на одной машине. Однако со временем такая установка может стать неудобной, а еще ее сложно масштабировать. Общее решение такой проблемы – разделение этих функций путем настройки удаленной базы данных, что позволяет серверу и базе данных работать отдельно, на индивидуальных машинах.
Одна из наиболее распространенных проблем, с которыми сталкиваются пользователи при настройке удаленной базы данных MySQL, заключается в том, что их экземпляр настроен на прослушивание только локальных соединений. Это настройка по умолчанию для MySQL, но она не подходит для удаленной базы данных, поскольку MySQL не имеет возможности прослушивать внешний IP-адрес, по которому можно связаться с сервером. Чтобы изменить это, откройте файл mysqld.cnf:
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
В файле найдите строку bind-address:
. . .
lc-messages-dir = /usr/share/mysql
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 127.0.0.1
. . .
По умолчанию это значение 127.0.0.1, что означает, что сервер будет слушать только локальные соединения. Вам нужно изменить эту директиву и указать внешний IP-адрес. В целях устранения неполадок вы можете установить в этой директиве IP-адрес с подстановочными символами *, :: или 0.0.0.0:
. . .
lc-messages-dir = /usr/share/mysql
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 0.0.0.0
. . .
Примечание: В MySQL 8+ директивы bind-address по умолчанию нет в файле mysqld.cnf. В этом случае добавьте в конец файла следующую выделенную строку:
. . .
[mysqld]
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
datadir = /var/lib/mysql
log-error = /var/log/mysql/error.log
bind-address = 0.0.0.0
Сохраните и закройте файл. Затем перезапустите MySQL:
sudo systemctl restart mysql
Теперь попробуйте получить удаленный доступ к БД.
mysql -u user -h database_server_ip -p
Если сейчас вы можете получить доступ к своей БД, это подтверждает, что проблема была в директиве bind-address и вы ее устранили. Однако обратите внимание, что настройка bind-address на 0.0.0.0 небезопасна, так как позволяет подключаться к вашему серверу с любого IP-адреса. Если же вы все еще не можете получить доступ к базе данных удаленно, проблема может быть вызвана чем-то другим. В любом случае вам может быть полезно обратиться к мануалу Настройка удаленной базы данных MySQL для оптимизации производительности сайта в Ubuntu 18.04.
MySQL внезапно останавливается или не может запуститься
Самая распространенная причина сбоев в MySQL заключается в недостатке памяти. Чтобы проверить это, нужно просмотреть лог ошибок MySQL после сбоя.
Сначала попытайтесь запустить сервер MySQL:
sudo systemctl start mysql
Затем просмотрите логи ошибок, чтобы узнать, что именно вызывает сбой MySQL. Вы можете использовать less:
sudo less /var/log/mysql/error.log
Сообщения, которые указывают на недостаточный объем памяти – это обычно записи типа Out of memory или mmap can’t allocate.
Потенциально решить проблемы с памятью могут:
- Оптимизация настройки MySQL. Отличным инструментом для этого является открытый MySQLtuner. Сценарий MySQLtuner выведет набор рекомендуемых настроек в файл конфигурации MySQL (mysqld.cnf). Обратите внимание, чем дольше ваш сервер работал до использования MySQLTuner, тем точнее будут его предложения. Чтобы получить оценку использования памяти ваших текущих настроек и предложенных MySQLTimer, используйте этот MySQL Calculator.
- Снижение зависимости загрузки страниц от MySQL. Обычно для этого можно добавить в приложение статическое кеширование. Например, можно использовать инструмент Joomla, который имеет встроенную функцию кэширования, и WP Super Cache, плагин WordPress, который добавляет такую функциональность.
- Увеличение ресурсов VPS. Как минимум для обслуживания MySQL мы рекомендуем сервер с 1 ГБ памяти, но размер и тип ваших данных могут существенно повлиять на требования к памяти.
Обратите внимание: хотя обновление (увеличение) сервера является потенциальным решением проблем с памятью, делать это рекомендуется только после того, как вы изучите и взвесите все остальные варианты. Модернизированный сервер с большим количеством ресурсов будет стоить больше денег, поэтому изменение размера следует выполнять только в том случае, если это действительно лучший (или единственный) вариант. Документация MySQL предлагает ряд других решений по диагностике и предотвращению сбоев.
Поврежденные таблицы
Некоторые действия могут повредить таблицы MySQL. Это означает, что произошла ошибка и данные, содержащиеся в них, не читаются. Попытки чтения данных из поврежденной таблицы обычно приводят к сбою сервера.
Вот распространенные причины поврежденных таблиц:
- Сервер MySQL остановился в середине записи.
- Внешняя программа изменяет таблицу, которая одновременно изменяется сервером.
- Машина неожиданно выключилась.
- Аппаратное обеспечение компьютера вышло из строя.
- Где-то в коде MySQL есть ошибка.
Если вы подозреваете, что одна из ваших таблиц была повреждена, вы должны сделать резервную копию вашего каталога данных перед устранением неполадок или попыткой исправить таблицу. Это поможет минимизировать риск потери данных.
Сначала остановите MySQL:
sudo systemctl stop mysql
Затем скопируйте все свои данные в новый каталог. В системах Ubuntu каталогом данных по умолчанию является /var/lib/mysql/:
cp -r /var/lib/mysql /var/lib/mysql_bkp
После создания резервной копии вы можете начать проверку таблицы на наличие повреждений. Если таблица использует механизм хранения MyISAM, вы можете проверить, не повреждена ли она, запустив CHECK TABLE из командной строки MySQL:
CHECK TABLE table_name;
В выводе этого оператора появится сообщение о том, повреждена она или нет. Если таблица MyISAM действительно повреждена, ее обычно можно исправить, выполнив REPAIR TABLE:
REPAIR TABLE table_name;
Если таблица успешно исправлена, вы увидите:
+--------------------------+--------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+--------------------------+--------+----------+----------+
| database_name.table_name | repair | status | OK |
+--------------------------+--------+----------+----------+
Если это не помогло исправить таблицу, в документации MySQL есть несколько альтернативных методов восстановления поврежденных таблиц.
Если поврежденная таблица использует механизм хранения InnoDB, процесс ее восстановления будет другим. InnoDB – это стандартный механизм хранения MySQL начиная с версии 5.5, он поддерживает автоматическую проверку и исправление ошибок. InnoDB проверяет наличие поврежденных страниц, отслеживая контрольные суммы на каждой странице, которую он читает, и если он находит несоответствие контрольной суммы, он автоматически останавливает сервер MySQL.
Необходимость исправления таблиц InnoDB возникает редко, поскольку InnoDB предоставляет механизм восстановления после сбоя, который может решить большинство проблем при перезапуске сервера. Однако если вы все же столкнулись с такой необходимостью, в документации MySQL рекомендуется использовать метод «Сброс и перезагрузка».
Этот метод подразумевает восстановление доступа к поврежденной таблице с помощью утилиты mysqldump для создания логической резервной копии таблицы, которая сохранит структуру и данные в ней, и дальнейшую перезагрузку таблицы.
Имея это в виду, попробуйте перезапустить MySQL, чтобы увидеть, позволит ли это вам получить доступ к серверу:
sudo systemctl restart mysql
Если сервер по-прежнему недоступен, тогда может быть полезно включить опцию InnoDB force_recovery. Вы можете сделать это, отредактировав файл mysqld.cnf:
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
В раздел [mysqld] добавьте такую строку:
. . .
[mysqld]
. . .
innodb_force_recovery=1
Сохраните и закройте файл, а затем попробуйте перезапустить MySQL снова. Если вы можете получить доступ к поврежденной таблице, используйте утилиту mysqldump, чтобы выгрузить данные таблицы в новый файл. Вы можете назвать этот файл как угодно, но здесь мы для примера назовем его out.sql:
mysqldump database_name table_name > out.sql
Затем удалите таблицу из базы данных. Чтобы избежать повторного открытия командной строки MySQL, вы можете использовать следующий синтаксис:
mysql -u user -p --execute="DROP TABLE database_name.table_name"
После этого восстановите таблицу с помощью только что созданного файла:
mysql -u user -p < out.sql
Обратите внимание, что механизм хранения InnoDB обычно более отказоустойчив, чем старый механизм MyISAM. Таблицы, использующие InnoDB, все еще могут быть повреждены, но благодаря функциям автоматического восстановления риск повреждения и сбоев таких таблиц значительно ниже.
Ошибки сокета
MySQL управляет соединениями с сервером базы данных с помощью файла сокета, особого файла, который упрощает связь между различными процессами. Файл сокета MySQL называется mysqld.sock, а в системах Ubuntu он обычно хранится в каталоге /var/run/mysqld/. Этот файл создается сервисом MySQL автоматически.
Иногда изменения в вашей системе или конфигурации MySQL могут привести к тому, что MySQL не сможет прочитать файл сокета, а это, в свою очередь, не даст вам получить доступ к вашим базам данных. Наиболее распространенная ошибка сокета выглядит следующим образом:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
Существует несколько причин, по которым может возникнуть эта ошибка, и несколько возможных способов ее устранения.
Одной из распространенных причин этой ошибки является то, что сервис MySQL изначально остановлен или не запускается. Это означает, что он не смог создать файл сокета. Чтобы выяснить, является ли это причиной возникновения ошибки, попробуйте запустить сервис через systemctl:
sudo systemctl start mysql
Затем попробуйте снова получить доступ к MySQL. Если вы все еще получаете ошибку сокета, проверьте расположение, в котором MySQL ищет файл сокета. Эта информация находится в файле mysqld.cnf:
sudo nano /etc/mysql/mysql.conf.d/mysql.cnf
Найдите параметр socket в разделе [mysqld]:
. . .
[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
. . .
Закройте этот файл, а затем убедитесь, что файл mysqld.sock существует, выполнив команду ls в каталоге, где MySQL будет его искать:
ls -a /var/run/mysqld/
Если файл сокета существует, вы увидите его в выводе этой команды:
. .. mysqld.pid mysqld.sock mysqld.sock.lock
Если файл не существует, возможно, причина в том, что MySQL пытается его создать, но не имеет соответствующих прав для этого. Вы можете убедиться в наличии необходимых привилегий, передав права собственности на каталог пользователю и группе mysql:
sudo chown mysql:mysql /var/run/mysqld/
Затем убедитесь, что у пользователя mysql есть соответствующие права доступа к каталогу. 755 подойдет в большинстве случаев:
sudo chmod -R 755 /var/run/mysqld/
Перезапустите сервис MySQL, чтобы он мог снова попытаться создать файл сокета:
sudo systemctl restart mysql
Затем попробуйте получить доступ к командной строке MySQL еще раз. Если вы по-прежнему сталкиваетесь с ошибкой сокета, вероятно, существует более глубокая проблема. В этом случае вы должны просмотреть лог ошибок, чтобы найти в нем подсказки.
Заключение
MySQL управляет данными огромного количества приложений и веб-сайтов. Конечно, такое широкое применение подразумевает и много потенциальных ошибок.
Здесь мы рассмотрели некоторые из наиболее часто встречающихся ошибок, но есть и другие, которые могут возникнуть в зависимости от того, как ваше приложение взаимодействует с MySQL.
Если вы не смогли найти здесь четкое решение своей проблемы, мы надеемся, что мануал, по крайней мере, дал вам некоторое представление об устранении общих неполадок MySQL, а это поможет найти источник ваших ошибок. Много полезной дополнительной информации вы можете найти в официальной документации MySQL. Кроме тем, которые мы здесь обсуждали, она охватывает другие стратегии устранения неполадок.
Tags: MariaDB, MySQL, SQL