Статья расскажет, как определять проблемы и ошибки на сервере баз данных MySQL. Вы научитесь определять причины проблем и устранять их.
MySQL — система управления базами данных (СУБД) с открытым исходным кодом от компании Oracle. Она была разработана и оптимизирована специально для работы веб-приложений. MySQL является неотъемлемой частью таких веб-сервисов, как Facebook, Twitter, Wikipedia, YouTube и многих других.
Эта статья расскажет, как определять, с чем связаны частые ошибки на сервере MySQL, и устранять их.
Не удаётся подключиться к локальному серверу
Одной из распространённых ошибок подключения клиента к серверу является «ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)».
Эта ошибка означает, что на хосте не запущен сервер MySQL (mysqld
) или вы указали неправильное имя файла сокета Unix или порт TCP/IP при попытке подключения.
Убедитесь, что сервер работает. Проверьте процесс с именем mysqld
на хосте сервера, используя команды ps или grep, как показано ниже.
$ ps xa | grep mysqld | grep -v mysqld
Если эти команды не показывают выходных данных, то сервер БД не работает. Поэтому клиент не может подключиться к нему. Чтобы запустить сервер, выполните команду systemctl.
$ sudo systemctl start mysql #Debian/Ubuntu
$ sudo systemctl start mysqld #RHEL/CentOS/Fedora
Чтобы проверить состояние службы MySQL, используйте следующую команду:
$ sudo systemctl status mysql #Debian/Ubuntu
$ sudo systemctl status mysqld #RHEL/CentOS/Fedora
Если в результате выполнения команды произошла ошибка службы MySQL, вы можете попробовать перезапустить службу и ещё раз проверить её состояние.
$ sudo systemctl restart mysql
$ sudo systemctl status mysql
Если сервер работает (как показано) и вы по-прежнему видите эту ошибку, вам следует проверить, не заблокирован ли порт TCP/IP брандмауэром или любой другой службой блокировки портов.
Для поиска порта, который прослушивается сервером, используйте команду netstat
.
$ sudo netstat -tlpn | grep "mysql"
Не удаётся подключиться к серверу MySQL
Ещё одна похожая и часто встречающаяся ошибка подключения — «(2003) Can’t connect to MySQL server on ‘server’ (10061)». Это означает, что в сетевом соединении было отказано.
Следует проверить, работает ли в системе сервер MySQL (смотрите выше) и на тот ли порт вы подключаетесь (как найти порт, можно посмотреть выше).
Похожие частые ошибки, с которыми вы можете столкнуться при попытке подключиться к серверу MySQL:
ERROR 2003: Cannot connect to MySQL server on 'host_name' (111)
ERROR 2002: Cannot connect to local MySQL server through socket '/tmp/mysql.sock' (111)
Ошибки запрета доступа в MySQL
В MySQL учётная запись (УЗ) определяется именем пользователя и клиентским хостом, с которого пользователь может подключиться. УЗ может также иметь данные для аутентификации (например, пароль).
Причин для запрета доступа может быть много. Одна из них связана с учётными записями MySQL, которые сервер разрешает использовать клиентским программам при подключении. Это означает, что имя пользователя, указанное в соединении, может не иметь прав доступа к базе данных.
В MySQL есть возможность создавать учётные записи, позволяющие пользователям клиентских программ подключаться к серверу и получать доступ к данным. Поэтому при ошибке доступа проверьте разрешение УЗ на подключение к серверу через клиентскую программу.
Увидеть разрешённые привилегии учётной записи можно, выполнив в консоли команду SHOW GRANTS
Входим в консоль (пример для Unix, для Windows консоль можно найти в стартовом меню):
В консоли вводим команду:
> SHOW GRANTS FOR 'tecmint'@'localhost';
Дать привилегии конкретному пользователю в БД по IP-адресу можно, используя следующие команды:
> grant all privileges on *.test_db to 'tecmint'@'192.168.0.100';
> flush privileges;
Ошибки запрещённого доступа могут также возникнуть из-за проблем с подключением к MySQL (см. выше).
Потеря соединения с сервером MySQL
С этой ошибкой можно столкнуться по одной из следующих причин:
- плохое сетевое соединение;
- истекло время ожидания соединения;
- размер BLOB больше, чем
max_allowed_packet
.
В первом случае убедитесь, что у вас стабильное сетевое подключение (особенно, если подключаетесь удалённо).
Если проблема с тайм-аутом соединения (особенно при первоначальном соединении MySQL с сервером), увеличьте значение параметра connect_timeout
.
В случае с размером BLOB нужно установить более высокое значение для max_allowed_packet
в файле конфигурации /etc/my.cnf
в разделах [mysqld]
или [client]
как показано ниже.
[mysqld]
connect_timeout=100
max_allowed_packet=500M
Если файл конфигурации недоступен, это значение можно установить с помощью следующей команды.
> SET GLOBAL connect_timeout=100;
> SET GLOBAL max_allowed_packet=524288000;
Слишком много подключений
Эта ошибка означает, что все доступные соединения используются клиентскими программами. Количество соединений (по умолчанию 151) контролируется системной переменной max_connections
. Устранить проблему можно, увеличив значение переменной в файле конфигурации /etc/my.cnf
.
[mysqld]
max_connections=1000
Недостаточно памяти
Если такая ошибка возникла, это может означать, что в MySQL недостаточно памяти для хранения всего результата запроса.
Сначала нужно убедиться, что запрос правильный. Если это так, то нужно выполнить одно из следующих действий:
- если клиент MySQL используется напрямую, запустите его с ключом
--quick switch
, чтобы отключить кешированные результаты; - если вы используете драйвер MyODBC, пользовательский интерфейс (UI) имеет расширенную вкладку с опциями. Отметьте галочкой «Do not cache result» (не кешировать результат).
Также может помочь MySQL Tuner. Это полезный скрипт, который подключается к работающему серверу MySQL и даёт рекомендации по настройке для более высокой производительности.
$ sudo apt-get install mysqltuner #Debian/Ubuntu
$ sudo yum install mysqltuner #RHEL/CentOS/Fedora
$ mysqltuner
MySQL продолжает «падать»
Если такая проблема возникает, необходимо выяснить, заключается она в сервере или в клиенте. Обратите внимание, что многие сбои сервера вызваны повреждёнными файлами данных или индексными файлами.
Вы можете проверить состояние сервера, чтобы определить, как долго он работал.
$ sudo systemctl status mysql #Debian/Ubuntu
$ sudo systemctl status mysqld #RHEL/CentOS/Fedora
Чтобы узнать время безотказной работы сервера, запустите команду mysqladmin
.
$ sudo mysqladmin version -p
Кроме того, можно остановить сервер, сделать отладку MySQL и снова запустить службу. Для отображения статистики процессов MySQL во время выполнения других процессов откройте окно командной строки и введите следующее:
$ sudo mysqladmin -i 5 status
Или
$ sudo mysqladmin -i 5 -r status
Заключение
Самое важное при диагностике — понять, что именно вызвало ошибку. Следующие шаги помогут вам в этом:
- Первый и самый важный шаг — просмотреть журналы MySQL, которые хранятся в каталоге
/var/log/mysql/
. Вы можете использовать утилиты командной строки вродеtail
для чтения файлов журнала. - Если служба MySQL не запускается, проверьте её состояние с помощью
systemctl
. Или используйте командуjournalctl
(с флагом-xe
) в systemd. - Вы также можете проверить файл системного журнала (например,
/var/log/messages
) на предмет обнаружения ошибок. - Попробуйте использовать такие инструменты, как Mytop, glances, top, ps или htop, чтобы проверить, какая программа использует весь ресурс процессора или блокирует машину. Они также помогут определить нехватку памяти, дискового пространства, файловых дескрипторов или какого-либо другого важного ресурса.
- Если проблема в каком-либо процессе, можно попытаться его принудительно остановить, а затем запустить (при необходимости).
- Если вы уверены, что проблемы именно на стороне сервера, можете выполнить команды:
mysqladmin -u root ping
илиmysqladmin -u root processlist
, чтобы получить от него ответ. - Если при подключении проблема не связана с сервером, проверьте, нормально ли работает клиент. Попробуйте получить какие-либо его выходные данные для устранения неполадок.
Избегаем часто встречающихся ошибок при работе с MySQL
Время чтения: 6 минут
MySQL Error — это ошибка, препятствующая корректной работе системы управления базами данных. Если при работе с БД возникает проблема, необходимо устранить ее перед продолжением вычислительной операции. Игнорирование ситуации может привести к нарушению целостности базы данных и информации, хранящейся в ней. MySQL сможет продолжить работу сразу после устранения проблемы. Ошибка может возникать на стороне пользователя и на стороне сервера, причины ее появления бывают самыми разными, поэтому важно обращать внимание на ее числовой код. Хотя у каждой MySQL Error есть текстовое название, в поисках решения лучше ориентироваться на ее числовое обозначение. Код из цифр не меняется при обновлении версий программы. Все о MySQL Error: что это, какие виды бывают и как их исправить.
Как исправить распространенные ошибки MySQL
В технической документации MySQL нет пошаговых инструкций по устранению ошибок. Однако широкое профессиональное сообщество часто делится своим опытом по решению сложных ситуаций. Не найдя подробный мануал, не спешите расстраиваться. Мы разберем несколько самых популярных MySQL Error.
Не удается подключиться к локальному серверу
Первую ситуацию, которую мы разберем — «Error 2002 (HY000)». Она означает, что приложение или клиент не может установить соединение с локальным сервером, скорее всего, из-за неправильных настроек подключения или проблем с самим сервером. Для решения этого вопроса необходимо проверить правильность настроек подключения, убедиться, что сервер запущен и работает корректно, а также удостовериться, что сервер доступен из сети. Если проблема не устраняется, можно попробовать перезапустить сервер или переустановить его.
К решению ситуации необходимо подходить последовательно, поочередно проверяя каждую из возможных причин возникновения ошибки.
Шаг 1. Убедитесь, что локальный сервер находится в работоспособном состоянии. Проверьте, запущен ли процесс «mysqld» на хосте сервера. Для этого выполните команды ps или grep:
Шаг 2. Дождитесь появления выходных данных. Их отсутствие является сигналом того, что сервер БД отключен и у юзера не получается к нему подключиться. Для запуска сервера введите команду systemctl:
Шаг 3. Состояние всей системы MySQL проверяется следующей командой:
Шаг 4. Если ошибка сохраняется, необходимо повторно перезапустить службу и исследовать ее состояние.
Шаг 5. Если сервер заработал, но ошибка все равно отображается, нужно проверить на блокировку порт TCP/IP брандмауэром или любой другой службой блокировки портов. Поиск порта выполняется при помощи команды:
Не удается подключиться к серверу MySQL
Ситуация с похожим кодом — «Error 2003». Проблема трактуется так: клиент не может установить соединение с сервером из-за отсутствия подключения с сетью или неправильной конфигурации. Это может быть вызвано также неправильным портом для подключения или блокировкой соединения на стороне сервера. Для устранения проблемы проверьте:
- Запущен ли сервер базы данных MySQL. Если нет, запустите его.
- Корректно ли настроен порт для подключения к серверу. Изначально порт MySQL — 3306. Если он был изменен, убедитесь, что вы используете правильный порт.
- Верно ли настроен фаервол.
- Корректно ли настроен файл конфигурации: проверьте имя хоста, порт, имя пользователя и пароль.
- Попробуйте перезагрузить сервер и снова подключиться к нему.
Если все вышеперечисленные методы не помогли, переустановите MySQL.
Ошибки запрета доступа
Работа с базами данных предполагает, что юзеры могут иметь разные уровни доступа к той или иной информации. Для этого в MySQL создаются учетные записи (УЗ), в которых юзер идентифицируется по имени и хосту. Чтобы избежать несанкционированного подключения к БД, клиент также должен пройти аутентификацию по логину и паролю. Ошибка запрета на доступ к MySQL может возникать, если у учетной записи, используемой для входа, нет прав на доступ к определенной информации. Для ликвидации неполадки проверьте права доступа, которые назначены для имени юзера, которое вы вводите для авторизации в УЗ, и для клиентской программы, используемой для подключения к серверу. Команда для проверки прав доступа:
Если вы хотите дать права доступа новому пользователю БД, введите в командную строку:
Потеря соединения с сервером MySQL
Подобная трудность связана с тем, что клиент был успешно подключен к серверу, но в процессе работы произошла потеря соединения. Это может быть вызвано различными причинами:
- слабое/нестабильное сетевое соединение;
- превышение «time out» при ожидании соединения с сервером;
- max_allowed_packet меньше, чем BLOB.
Шаг 1. Проверьте свое сетевое соединение, в особенности если подключаетесь к серверу с удаленного устройства.
Шаг 2. Откорректируйте значения параметра connect_timeout. Возможно, после его увеличения вам удастся наладить связь с сервером MySQL.
Шаг 3. Как и с параметрами «time out», пропишите более высокое значение для max_allowed_packet. Найти конфигурационный файл можно через путь: /etc/my.cnf. В раздел [mysqld] или [client]:
Слишком много подключений
С MySQL-сервером по умолчанию можно установить не более 151 соединения одновременно. Когда их количество достигает максимума, новые пользователи не могут получить доступ. Для устранения проблемы необходимо обратиться к системной переменной max_connections, увеличив ее значение. Путь к переменной: /etc/my.cnf.
Недостаточно памяти
Проблема трактуется так: у сервера не получается выполнить запрос из-за нехватки оперативной памяти. Его ресурсы исчерпаемы: ему может не хватить памяти для хранения результатов запроса. Так происходит, если на сервере работает слишком много запросов или если используется большой объем данных. Для решения проблемы необходимо увеличить объем оперативной памяти или оптимизировать запросы и данные, чтобы уменьшить потребление памяти. Также можно попробовать увеличить параметры конфигурации MySQL, связанные с использованием памяти.
Однако прежде чем переходить к настройке сервера, необходимо убедиться, что запрос был корректным:
- отключите загрузку результатов из кэша, если клиент MySQL используется напрямую, запустив его с ключом quick switch;
- отключите работу с результатами из кэша при использовании драйвера MyODBC.
Если после этого необходимость в оптимизации производительности у сервера сохраняется, выполните следующие команды:
Заключение
Прежде чем приступать к исправлению ошибки, проведите диагностику системы и определите, что именно вызвало неисправность. У ошибок с одним числовым кодом, могут быть разные причины появления. Полезным инструментом в этом деле будет журнал MySQL.
Автор: RuWeb
Время чтения: 6 минут
другие полезные статьи
-
Что такое MySQL
Автор: RuWebИТ-разработка и, в частности, сфера веба полнятся терминами и аббревиатурами, которые не всегда понятны начинающим специалистам. Разобраться, что из этого значит язык программирования, а что — название технологии, утилиты или хостинг-услуги, без помощи хотя бы интернета не получится. Поэтому такие понятия, как MySQL, SQL и база данных (database), нередко вызывают вопросы.
-
Как зарегистрировать бесплатный домен
Автор: RuWebБез хостинга и домена невозможно размещение и продвижение веб-проекта в сети. Не имея адреса, сайт не будет найден пользователями и останется набором файлов, папок и данных на сервере. Во избежание путаницы каждому веб-ресурсу присваивается оригинальное имя.
-
Как выбрать хостинг для сайта на WordPress
Автор: RuWebСвыше 40% сайтов в интернете работают на системе WordPress (WP). Эта CMS является самой популярной среди всех платформ по созданию веб-проектов, поскольку обладает мощным функционалом, проста в управлении и при этом распространяется бесплатно.
MySQL — система управления базами данных (СУБД). С её помощью можно управлять базами данных (БД) на сервере.
В зависимости от операционной системы, на сервере может быть установлена СУБД MySQL или MariaDB — их функционал сильно похож, и для работы разницы, как правило, нет.
В данной статье рассмотрим, с какими проблемами вы можете столкнуться при работе с MySQL и как их решить.
- Создание базы через ISPmanager
- Раздела «Базы данных» нет в меню
- Не подходит пароль к серверу баз данных
- Где искать ошибки?
- Перечень возможных проблем
- Table ‘./site/content’ is marked as crashed and should be repaired
- mysql_connect() [function.mysql-connect]: Access denied for user ‘user_xxx’@’localhost’ (using password: YES)
- Не удалось подключиться к базе данных
- В панели ISPmanager не удается создать базу данных, ошибка «Недостаточно данных»
- MySQL не запускается ни в сервисах, ни через консоль
- Решение проблем с кодировками MySQL
- Перечень возможных проблем
- Русификация MySQL
Создание базы через ISPmanager
Панель управления ISPmanager значительно упрощает управление СУБД и базами данных. На корректно работающем VDS создание базы займет не больше 5 минут.
В левом меню ISPmanager переходим в раздел Базы данных и нажимаем Создать базу данных.
Заполняем необходимые поля: имя БД, владелец БД (должен совпадать с владельцем сайта), сервер БД, кодировка БД, после чего создаем нового пользователя БД (либо выбираем существующего) и задаем пароль. Рекомендуем создавать сложные пароли.
Подробнее о создании Базы данных можно узнать в отдельной статье.
Теперь немного о тех местах, где могут возникнуть сложности.
Раздела «Базы данных» нет в меню
Есть 2 возможных варианта решения проблемы:
1. На сервере не запущен сервер баз данных MySQL
Проверить, активен ли сервис, вы можете в разделе Мониторинг и журналы панели ISPmanager. Попробуйте запустить или перезапустить службу mariadb
(в ОС CentOS и Debian) или mysql
(в ОС Ubuntu) с помощью кнопок в панели.
Если не помогло, перезапустите из консоли командой systemctl restart mysql
для Ubuntu/Debian или командой systemctl restart mariadb
для Centos 7.
2. Проблемы с подключением к базе данных
Перейдите в раздел Серверы БД, двойным кликом откройте свойства и нажмите Сохранить, ничего не меняя. Это принудительно обновит информацию о MySQL в панели управления. После этого обновите страницу — раздел Базы данных должен появиться.
Не подходит пароль к серверу баз данных
Случается так, что пароль root от MySQL-сервера утерян и надо установить новый. Делается следующим образом:
Останавливаем MySQL-сервер:
В Debian/Ubuntu:
# systemctl stop mysql
В CentOS 7:
# systemctl stop mariadb
или
# systemctl stop mysqld
Запускаем его без проверки таблиц прав:
# mysqld_safe --skip-grant-tables &
Заходим root’ом без пароля:
# mysql -uroot
Меняем пароль:
# use mysql;
MySQL < 5.7
# UPDATE user SET Password=PASSWORD("new_password") WHERE User='root';
MySQL => 5.7
# UPDATE user SET authentication_string=PASSWORD("new_password") WHERE User='root';
Проверить версию MySQL можно с помощью команды:
# mysql –version
или
# mariadb –version
Продолжаем для всех версий
# FLUSH PRIVILEGES;
В Debian/Ubuntu:
# systemctl restart mysql
В Centos 7:
# systemctl restart mariadb
или
# systemctl restart mysqld
Авторизуемся как root с паролем new_password
# mysql -uroot -p
После вводим новый пароль.
Где искать ошибки?
MySQL — свободная реляционная система управления базами данных. Поиск проблем с сервисом лучше всего начинать с изучения логов. Для этого необходимо подключиться на сервер по SSH. Их расположение разнится в зависимости от используемой файловой системы. В конфигурационном файле my.cnf
нужно искать строки log
и log-error
, чтобы определить, где находятся логи. Также можно воспользоваться mysql запросом:
show variables like '%log%';
Если логирование не включено, сделать это можно следующим образом. Зайти в файл:
/etc/my.cnf #Centos /etc/mysql/my.cnf #Debian /etc/mysql/mysql.conf.d/mysql.cnf #Ubuntu
Расположение конфигурационного файла может отличаться в зависимости от дистрибутива или CMS.
И в секцию [mysqld]
добавить строку:
log-error=/var/log/mysql-errors.log
Выйти из файла, выполнить команды:
touch /var/log/mysql-errors.log chown mysql:mysql /var/log/mysql* chmod 640 /var/log/mysql*
Следующая команда включит просмотр созданного лога в режиме реального времени(tail –f) и оставить его в фоне(&) что бы можно было параллельно запускать другие команды:
tail –f /var/log/mysql-errors.log &
Данная команда позволяет проводить действия с БД или сайтов и одновременно смотреть на ошибки в логе. Чтобы остановить команду, нажмите Ctrl+C
.
Перечень возможных проблем
Table ‘./site/content’ is marked as crashed and should be repaired
Такое сообщение может появиться в логах или на сайте. Оно означает, что таблица одной из БД «побилась» и требуется ее восстановление. Необходимо подключится на сервер по SSH, выполнить команду, которая проверит все базы данных на предмет ошибок
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> — имя пользователя базы данных или root,
- <PASSWORD> — заменить на пароль пользователя или root от MySQL (его можно посмотреть в ISPmanager — Базы данных — Серверы БД — двойной клик на сервер MySQL для просмотра пароля root (либо Базы данных — двойной клик на нужную базу данных и двойной клик на нужного пользователя).
Либо можно выполнить исправление конкретной базы данных:
mysqlcheck --repair --analyze --optimize <DB> -u<USER> -p<PASSWORD>
где
- <USER> — имя пользователя базы данных или root,
- <PASSWORD> — заменить на пароль пользователя или root от MySQL (его можно посмотреть в ISPmanager — Базы данных — Серверы БД — двойной клик на сервер MySQL для просмотра пароля root (либо Базы данных — двойной клик на нужную базу данных и двойной клик на нужного пользователя),
- <BD> — база данных, которой требуется исправление.
mysql_connect() [function.mysql-connect]: Access denied for user ‘user_xxx’@’localhost’ (using password: YES)
Чаще всего связана с тем, что в настройках сайта указаны не верные данные (логин и/или пароль) для подключения к базе. Вариант решения: посмотреть в админ-панели сайта данные пользователя, пароль и название базы для подключения к базе. Зайти в ISPmanager — Базы данных — кликнуть на базу, затем на пользователя и в графу Пароль поставить пароль из админ-панели.
Может быть обратная ситуация, когда в панели ISPmanager указаны верные данные, а в конфигурационных файлах указаны неверные. В таком случае нужно править конфигурационные файлы, для CMS Bitrix, например, это /bitrix/.settings.php
и/bitrix/php_interface/dbconn.php
.
На сайте ошибка «Не удалось подключиться к базе данных»
В зависимости от используемой CMS эта ошибка может по-разному выглядеть:
Возникла ошибка при подключении сервера баз данных MySQL Can't connect to local MySQL server Error connect to mysql Unable to connect to the database:Could not connect to ...
Подключится на сервер по SSH, выполнить:
systemctl restart mysql #перезапуск MySQL для Ubuntu, Debian systemctl restart mariadb #перезапуск MySQL для Centos 7 ps axuw | grep mysql #Эта команда должна вывести список процессов MySQL. #Если ничего не вывела – значит, MySQL не запустился.
Убедится что в ISPmanager, в разделе Службы лампочка mysql или mariadb горит.
В панели ISPmanager не удается создать базу данных, ошибка «Недостаточно данных»
Это значит у вас в ISPmanager — Серверы БД не создано ни одного сервера баз данных. Для создания нажмите на Серверы БД, далее на Создать сервер. В полях введите название сервера БД (например, MySQL), придумайте имя пользователя и пароль. Также в панели ISPmanager можно установить более 1 СУБД, альтернативные СУБД будут работать в контейнерах Docker.
MySQL не запускается ни в сервисах, ни через консоль
При запуске через консоль ошибки могут быть вида:
cant connect to local mysql server throught socket /var/run/mysqld/mysql.d.sock /etc/init.d/mysql start Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed! /usr/local/etc/rc.d/mysql-server restart mysql not running? (check /var/db/mysql/peroksid.ispvds.com.pid). Starting mysql.
Проверить свободное место на диске:
df –h #общая информация du –hs /* #сколько занимает конкретные папки
Если не осталось места, удалить ненужные файлы.
Частая ситуация, когда логи сайтов разрастаются и места на диске свободного не остается, MySQL не может нормально работать (справедливо и для всех остальных сервисов – apache, exim и т.д.)
Снова пробуем перезапустить MySQL:
systemctl restart mysql #перезапуск MySQL для Ubuntu и Debian systemctl restart mariadb #перезапуск MySQL для Centos 7
Если проблема не со свободным местом, в логах должны появиться записи, похожие на эти:
130929 06:16:05 mysqld_safe Starting mysqld daemon with databases from /var/db/mysql 130929 6:16:05 [Warning] '--skip-locking' is deprecated and will be removed in a future release. Please use '--skip-external-locking' instead. 130929 6:16:05 [Warning] option 'max_allowed_packet': unsigned value 5824839680 adjusted to 1073741824 Unknown suffix '-' used for variable 'sort_buffer_size' (value '--read_buffer_size=256K') 130929 6:16:05 [Warning] option 'sort_buffer_size': unsigned value 0 adjusted to 32776 130929 6:16:05 [ERROR] /usr/local/libexec/mysqld: Error while setting value '--read_buffer_size=256K' to 'sort_buffer_size' 130929 6:16:05 [ERROR] Aborting
Смотрим записи с меткой [ERROR]. В логе выше ошибка «Error while setting value ‘—read_buffer_size=256K’ to ‘sort_buffer_size’» означает, что в конфиге my.cnf
неверно прописана директива ‘sort_buffer_size. Этот случай приведен только для примера. В каждом конкретном случае лог будет различаться. Ошибки могут быть самые разные. Дальнейшие действия зависят от конкретной ошибки и требуют детального разбирательства.
Решение проблем с кодировками MySQL
Чтобы решить проблему — достаточно понять логику работы. MySQL, начиная с версии 4.1, знает, что такое кодировки и как с ними работать. Если до 4.0 она работала с байтами, то теперь работает с символами.
MySQL написали шведы, поэтому кодировкой по умолчанию (сразу после установки) является latin1, а «сравнение» (последовательность букв, алфавит; влияет на сортировки) — latin1_swedish.
Итак, где кодировки указываются.
1. Кодировка конкретной базы/таблицы/столбца. Это кодировка, в которой MySQL будет хранить данные. Например, если у вас данные в cp1251, то будет большой ошибкой указывать для хранения кодировку latin1. В ней нет соответствий для русских символов, все они будут заменены на вопросы.
Кодировку хранения можно задать, например, так.В терминале открываем MySQL с помощью команды mysql
или mysql -u имя_пользователя -p
, вводим пароль, после чего пишем в консоли MySQL:
create database `имя базы` default charset cp1251;
Если кодировка не указана — будет использовано значение параметра default-character-set
из файла /etc/my.cnf
(либо latin1, если параметра нет). Кстати, именно этот параметр редактирует ISPmanager в свойствах сервера баз данных.
2. Кодировка соединения. Это кодировка, в которой клиент (скрипт пользователя, форум, mysql-клиент и т.д.) общается с MySQL. Когда клиент подсоединяется к серверу, тот ему сообщает значение параметра default-character-set
. Таким образом они договариваются о том, в какой кодировке будут общаться. Кодировку общения можно изменить запросом (его лучше выполнять сразу после соединения с сервером):
set names cp1251
где вместо cp1251 вы можете указать нужную кодировку.
Кстати, множество современных правильных скриптов именно это и делают.
Одна сложность: есть ряд кривых клиентов, которые всего этого не понимают и общаются в какой-то своей кодировке. Персонально для них можно написать в /etc/my.cnf
, секцию [mysqld]
:
[mysqld] set init_connect="set names utf8"
где вместо utf8 вы можете указать нужную кодировку.
Что это означает? Сразу после подсоединения любого клиента, MySQL выполнит запрос set names utf8
, как будто смену кодировки общения запросил сам клиент.
Это всё, что нужно знать для решения любой проблемы с кодировками в MySQL. Осталось несколько уточнений (самое интересное):
phpMyAdmin, mysqldump — обычные клиенты, на них действуют те же самые правила. Одно «но»: на все PHP-скрипты (включая phpMyAdmin) действует default-character-set
из секции [client]
в my.cnf
. Для mysqldump
есть отдельная секция [mysqldump]
. Часто бывает так, что команда mysqldump «не видит» секцию [mysqldump]
, поэтому в случаях, когда необходимо делать дамп БД в определенной кодировке, лучше использовать mysqldump
с параметром --default-character-set=utf8
(вместо utf8 укажите нужную кодировку). ISPmanager прописывает default-character-set
во все секции.
Дамп базы — это обычный набор MySQL-команд. Если вы в самое его начало напишете set names cp1251;
, то эта команда тоже выполнится, и MySQL будет считать, что дальше все данные в дампе идут в кодировке cp1251.
Кодировки в MySQL-командах пишутся без кавычек и без «-» (дефисов). Популярные в России кодировки: utf8, cp866 (DOS), cp1251 (windows-1251), koi8r, utf8mb4.
И, наконец, пара советов:
- Если вы в этом новичок, постарайтесь свести всё к одной кодировке. Пусть у вас дамп и
default-character-set
(напомню, влияет на кодировку хранилища при создании таблиц и на кодировку общения с клиентом) будет в одной кодировке. Это избавит от путаницы и решит 90% проблем. - Если есть возможность — используйте консольную утилиту mysqldump. phpMyAdmin — это дополнительная прослойка, которая лишь добавляет свою путаницу и свои баги.
Русификация MySQL
Чтобы русифицировать базу данных MySQL, не вдаваясь в подробности почему и как, проделайте следующие процедуры:
1. В конфигурационном файле /etc/my.cnf
добавьте следующие строчки:
Под разделом [client]:
default-character-set=cp1251
Под разделом [mysqld]:
character-set-server=cp1251 collation-server=cp1251_general_ci init-connect = "set names cp1251"
2. После этого перезапустите базу MySQL или весь ваш виртуальный сервер (из ISPmanager или консоли).
28 января, 2019 12:25 пп
4 007 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