Ошибка запуска mysql сервера

MySQL или MariaDB — это один из самых популярных движков баз данных, который используется для обеспечения работы большинства веб-сайтов в интернете, а также множества других проектов.

Иногда случается, что из-за после изменения настроек или по какой-либо другой причине mysql не запускается. Это довольно серьезная проблема, особенно, когда такая ситуация случается на сервере публичного проекта. В этой статье мы рассмотрим основные причины почему может возникать такая проблема, а также пути решения. В качестве примера будет использоваться Mariadb и Ubuntu.

Если вы используете systemd для запуска сервисов, то получите такую ошибку:

failed to start mysql server или job for mysql failed because the control proccess exited

Из сообщения понято только то что что-то пошло не так, но что именно неизвестно. Чаще всего проблемы в работе MySQL могут вызвать такие причины:

• Синтаксические ошибки в конфигурационном файле;
• Неверные настройки;
• Недостаточное количество оперативной памяти на сервере;
• Проблемы с правами доступа;
• Сетевой порт уже занят;
• Таблицы баз данных повреждены;

Дальше мы рассмотрим основные пути решения этих проблем. Но сначала нам нужно выяснить почему не запускается программа. Гадать на кофейной гуще и перебирать все возможные методы решения можно очень долго, самым эффективным решением будет посмотреть какие ошибки выдает сама программа.

Что делать если не запускается MySQL?

Первым делом, если вы меняли настройки в конфигурационном файле надо проверить его на ошибки. Встроенной утилиты для таких целей нет, но можно запустить mysql daemon с опцией —help:

/usr/sbin/mysqld --help --verbose

В начале вывода будут представлены обнаруженные в основном конфигурационном файле ошибки. Например, здесь я специально добавил несуществующую переменную. Вам остается только исправить ошибки и перезапустить mysql:

systemctl restart mariadb

Если же это не сработало и вы все еще получаете ошибку, посмотрите лог загрузки systemd для этого сервиса:

systemctl status -l mariadb

Иногда здесь тоже можно найти полезную информацию, но в данном случае ничего нет. Следующий шаг — просмотр лога mysql. Если лог еще не включен, включаем его добавив такую строчку в /etc/mysql/my.cnf в секцию [mysqld]:

sudo vi /etc/mysql/my.cnf

[mysqld]
log-error=/var/log/mysql/error.log
Затем снова пытаемся запустить сервис и смотрим на появившиеся в логе ошибки:

tail -f /var/log/mysql/error.log

Здесь вы увидите ошибки, которые мешают запустить mysql. Здесь надо искать слова: Fail, Error, Warning, Aborted и так далее. Вам остается только их исправить. Исправить проблемы с синтаксисом, убрать опции, которые потребляют слишком много памяти и исправить другие проблемы. А теперь рассмотрим несколько распространенных проблем.

1. Изменение размера буфера innodb

Если вы измените значение директивы innodb_buffer_pool_size в большую или меньшую сторону пока сервис работает, то перезапустить вы его уже не сможете. Перед тем как менять значение директивы остановите mysql:

sudo systemctl stop mariadb

Затем удалите старые логи innodb или просто их переименуйте:

sudo mv /var/lib/mysql/ib_logfile0{,bak}
sudo mv /var/lib/mysql/ib_logfile1{,bak}

И только после этого можете снова запускать сервис, он запустится с новыми настройками размера буфера. Только будьте аккуратны с выбором размера. При слишком большом размере может не хватить памяти для запуска, так как весь буфер хранится в ОЗУ.

sudo systemctl start mariadb

2. Ошибка Permission denied

MySQL хранит файлы базы данных на диске. У движка базы данных должен быть полный доступ к папке, в которой хранятся эти файлы. По умолчанию в Ubuntu это /var/lib/mysql/. Все файлы в этой папке должны принадлежать пользователю mysql:

ls -l /var/lib/mysql/

Если это не так, исправляем командой:

sudo chown -R mysql:mysql /var/lib/mysql/

3. Ошибка Address already in use

MySQL может использовать файловый сокет Linux или же сетевой сокет, тогда база данных будет доступна другим программам на порту 3306. Если сейчас уже запущен другой процесс mysql или какой-либо другой процесс занимает этот порт вы получите ошибку Address already in use. Чтобы ее решить смотрим какой процесс использует порт:

sudo ss -lptn 'sport = :3306'

Например, здесь мы видим, что запущен другой экземпляр mysql с PID 11240. Вы можете его завершить с помощью kill:

sudo kill -TERM 11240

Теперь база данных запуститься.

4. Ошибка corrupt database page Mysql

Если mysql завершился некорректно из-за недостатка памяти или других проблем, например, проблем с файловой системой, то таблицы innodb могут быть повреждены — corrupt database page. Это происходит не так часто. При такой проблеме вы увидите такую запись в логе:

Проблема серьезная, но решаемая. В самом сообщении об ошибке система рекомендует сделать резервную копию таблиц, удалить их и создать заново из резервной копии. Но для этого должна быть запущена база данных, а она не запускается.

Нам необходимо запустить mysql в режиме восстановления, в котором все повреждения таблиц будут игнорироваться. Для этого добавляем в конфигурационный файл /etc/mariadb/my.cnf строку:

sudo vi /etc/mariadb/my.cnf

innodb_force_recovery=1

Затем запускаем mysql:

systemctl start mariadb

Ошибок не будет и сервис запуститься. Нам остается только исправить таблицы. Для этого можно воспользоваться инструментом mysqlcheck:

mysqlcheck -u root --auto-repair --all-databases

Готово. Теперь возвращаемся в конфигурационный файл и комментируем или удаляем строку innodb_force_recovery.

После этого можно перезапустить mysql и сервис будет работать в обычном режиме:

sudo systemctl restart mariadb

Выводы

В этой статье мы рассмотрели основные причины почему не запускается mysql сервер. Теперь вы сможете очень быстро с ними справиться, если столкнетесь в своей работе. А с какими еще проблемами кроме этих сталкивались вы? Какие были пути решения? Давайте дополним статью вместе, пишите в комментариях!

In my case, it was a space issue.
Check if you have enough space left.

from /var/log/mysql/error.log I got some hints from two lines:

2018-08-04T05:25:29.519139Z 0 [ERROR] InnoDB: Write to file ./ibtmp1failed at offset 3145728, 1048576 bytes should have been written, only 704512 were writt$
2018-08-04T05:25:29.519145Z 0 [ERROR] InnoDB: Error number 28 means 'No space left on device'

I could see that it is a space issue.

root@xxx:/home/user1# df -h
Filesystem                            Size  Used Avail Use% Mounted on
udev                                  477M     0  477M   0% /dev
tmpfs                                 100M   11M   89M  11% /run
/dev/mapper/server1--osticket--vg-root  8.3G  7.9G     0 100% /
tmpfs                                 497M     0  497M   0% /dev/shm
tmpfs                                 5.0M     0  5.0M   0% /run/lock
tmpfs                                 497M     0  497M   0% /sys/fs/cgroup
/dev/vda1                             472M  467M     0 100% /boot
tmpfs                                 100M     0  100M   0% /run/user/1000

From here, I could see that there was not enough space left on the virtual server /dev/mapper/server1--osticket--vg-root 8.3G 7.9G 0 100% /. And I thought on either migrating or increasing the virtual drive, but I decided to remove unnecessary files first.

So, had to clean up cache and files that were not needed:

#apt-get clean
#apt-get -f autoremove

Then, do not forget to remove the mysql corrupted log files afterwards. They would be generated again when you restart mysql

#service mysql stop
#cd /var/lib/mysql
#rm ib_logfile*
#service mysql start

Check your mysql server service and it is probably up and running

root@server1-osticket:/var/lib/mysql# service mysql status
● mysql.service - MySQL Community Server
   Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2018-08-04 23:07:24 WAT; 7min ago
  Process: 1559 ExecStartPost=/usr/share/mysql/mysql-systemd-start post (code=exited, status=0/SUCCESS)
  Process: 1549 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
 Main PID: 1558 (mysqld)
    Tasks: 29
   Memory: 280.3M
      CPU: 589ms
   CGroup: /system.slice/mysql.service
           └─1558 /usr/sbin/mysqld

Aug 04 23:07:19 server1-osticket systemd[1]: Starting MySQL Community Server...
Aug 04 23:07:24 server1-osticket systemd[1]: Started MySQL Community Server.
root@server1-osticket:/var/lib/mysql#

Case closed.
I hope it helps.

Функционирование большинства веб-сайтов в сети Интернет во многом зависит от используемого движка. Чаще всего это MySQL или его альтернативный вариант – MariaDB. В результате изменения некоторых настроек может произойти следующая ситуация: движок отказывается запускаться. Это может доставить много хлопот в том случае, если такое происходит на сервере публичного проекта.

Так как любая проблема имеет решение, остается найти необходимый «ключик».

Основные причины, почему не стартует mysql / MariaDB server

При запуске сервиса может быть использован systemd. Это приведет к ошибке – на экране появится соответствующий текст:

«failed to start mysql server»

Обычному пользователю подобный текст ни о чем не скажет. Отходя в сторону от «шифров», следует уделить особое внимание возможным причинам сбоя:

1. Допущенные ошибки в синтаксисе конфигурационного файла;
2. Заданы неправильные настройки;
3. Нехватка памяти;
4. Трудности с правами доступа;
5. Не свободен сетевой порт;
6. Повреждение таблиц баз данных. Обычно это происходит когда сервер выключился аварийно, например когда пропало электричество.

Как видите, существует предостаточно потенциальных причин для сбоя MySQL. И нет никакого смысла рассматривать всевозможные пути решения данной проблемы. Действовать по принципу «пальцем в небо» не стоит. Так как программа выдает определенную ошибку, нужно лишь разобрать её подробнее.

Что делать

Если недавно правили конфиг, необходимо проверить его на ошибки.

$ /usr/sbin/mysqld --help --verbose

Ошибки, найденные в конфигурационном файле, будут указаны в самом начале вывода. Их нужно исправить.

Следующее действие – перезапуск MySQL. Это легко сделать данным способом:

$ systemсtl restart mariadb

В том случае, если ошибка снова появляется на экране, нужно посмотреть статус, так называемый лог запуска.

$ systemсtl status -l mariadb

Теперь необходимо просмотреть лог MySQL. Он может быть не включен, поэтому для начала стоит задать:

$ sudo nano /etc/mysql/my.cnf

Далее еще раз производим запуск сервиса для просмотра ошибок.

На практике это делается следующим способом:

$ tail –f /var/log/mysql/error.log

В логе будут указаны ошибки, которые нужно исправить. На что обратить внимание:

• Fail
• Error
• Warning
• Aborted

Пользователю необходимо исправить проблемы с синтаксисом, а также устранить опции, для которых выделяется большой объем памяти.

Инструменты для проверки и оптимизации сервера

Посредством некоторых инструментов можно произвести мониторинг производительности MySQL. Возможно, работает программа, на которую затрачивается весь ресурс процессора. Это может послужить причиной блокировки машины. Инструменты, представленные ниже, помогут выявить нужный софт:

• Mytop;
• Glances;
• Top;
• Htop;
• Ps.

По окончанию мониторинга станет ясно, что происходит с состоянием памяти и дискового пространства.

Повреждение таблиц баз данных — corrupt database page Mysql

Если не запускается база данных по причине сломанных таблиц, тогда в логе можно увидеть строчку — aborting because of a corrupt database page.

В таком случае починить базу данных можно, рассмотрим процесс восстановления:

• запустить mysql в режиме восстановления. В данном режиме все ошибки игнорируются.

В конфиг /etc/mariadb/my.cnf добавим строчку

innodb_force_recovery = 2

Затем запускаем сервис.

systemctl start mariadb

При помощи утилиты mysqlcheck запустим восстановления таблиц.

mysqlcheck -u root --auto-repair --all-databases

После выполнения команды, удаляем из конфига строчку innodb_force_recovery = 2, затем перезапускаем mysql.

systemctl restart mariadb

Заключение

MySQL имеет достаточно широкое применение, что приводит к немалому числу потенциальных ошибок и сбоев. Рассмотреть всевозможные ошибки в одном материале не представляется возможным. Многое будет зависеть от того, каким образом взаимодействует приложение пользователя с базой данных. Алгоритм необходимых действий под конкретную ситуацию также будет зависеть от того, какую ошибку выдаёт система.

В данной статье указаны самые распространенные проблемы при работе с 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"

Ещё одна похожая и часто встречающаяся ошибка подключения — «(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, чтобы получить от него ответ.
• Если при подключении проблема не связана с сервером, проверьте, нормально ли работает клиент. Попробуйте получить какие-либо его выходные данные для устранения неполадок.

Перевод статьи «Useful Tips to Troubleshoot Common Errors in MySQL»

От автора: не запускается MySQL? Наверно «стартер» барахлит. Нужно показать опытному «механику». Хотя в некоторых случаях можно обойтись и собственными силами. Вот сегодня и разберемся, как произвести починку «заглохнувшей» СУБД самостоятельно.

Использование теории «чужих ошибок»

Если думаете, что при написании материалов из этой серии я «не потею», то ошибаетесь. Даже самый «заядлый» разработчик-профессионал не может все знать. Причем часто натыкаешься в своей практике на те «грабли», на которые уже наступал (и не раз). А это во сто крат обиднее и больнее. Получается, что данная статья предназначена не только для вас, но и мне :).

Но в MySQL столько «граблей», что их умудряются не перешагнуть и «чайники», и профессионалы по всему миру. Попробуем в этом материале собрать наиболее частые причины того, почему не подключается база данных MySQL и другие распространенные проблемы.

Начнем с описания особенностей синтаксиса запросов SQL. Данная система управления БД хоть и основана на языке структурированных запросов, но все же сохранила некоторую самобытность с «заковыркой». Причем в прямом смысле этого слова :).

Особенности синтаксиса

Для примера возьмем один, и выполним его в программной оболочке, которую часто используем. А также запустим его в командной строке. Таким образом мы выясним особенности синтаксиса MySQL, «царящих» в каждом из вариантов. Начнем, как предписывает традиция, с phpMySQL. Но сначала запрос, написанный по всем «канонам» SQL:

Теперь введем его и выполним в программе:

Как видим, приложение «ругается» на несоответствующий синтаксис. Правильно:

В phpMyAdmin (чтобы не говорили потом «не удалось запустить MySQL») название столбцов экранируются грависом, а все указываемые значения – одинарными кавычками. Кстати, гравис находится над клавишей буквы «Ё».

На самом деле использование грависов не является обязательным. Они прописываются программой в автоматически сгенерированных запросах. Ошибки синтаксиса в командной строке

Теперь переходим в командную строку, и попытаемся запустить вариант запроса, корректный для phpMyAdmin. Здесь нас сразу подстерегает ошибка, поскольку мы не выделили ни одной БД.

Исправим это:

И еще раз выполним предыдущий код SQL. Теперь все прошло успешно. Для чистоты эксперимента введем первый вариант запроса. Сервер СУБД говорит нам, что такого столбца в этой таблице нет. Исправим запрос, и экранируем значение одинарными кавычками.

Но что-то опять пошло не так, и MySQL ждет от нас ввода дополнительных параметров. Это потому, что мы забыли поставить точку с запятой. Хотя она не является обязательной в phpMyAdmin.

Кстати (пока мы находимся в CMD) одной из причин, почему не удается запустить службу MySQL из командной строки, может быть нарушение синтаксиса команды входа. «Неправильный» пример:

Из-за пробела между параметром –p и значением пароля система СУБД просит пользователя ввести пароль еще раз. Но затем его значение не принимает. Напомню, что все из-за одного единственного пробела. Правильная написанная команда выглядит следующим образом: Z:usrlocalmysql-5.5binmysql.exe -u roman –pзначение пароля

На этих граблях я тоже «побывал» неоднократно. Вот такой «крючковатый» синтаксис получается :). Также важно, если не удалось запустить MySQL через командную строку, проверить правильность указанного пути к исполняемому файлу СУБД.

Другие распространенные ошибки

Вот еще несколько самых частых ошибок, которые допускают пользователи СУБД:

«Acces danied» — сервер говорит, что доступ запрещен. Чаще всего эта ошибка выскакивает, когда пользователь или приложение пытается совершить операцию, которая не разрешена для используемой учетной записи.

Поясню следующий скриншот, и почему и не удается подключиться к MySQL базе. Я зашел на сервер БД под учеткой пользователя (user), привилегии которого распространяются только на одну базу. При попытке вывести список всех баз, имеющихся на сервере, MySQL вернул пустой результат. А когда я попытался «пробраться» на другую БД, система выдала мне «Access denied».

«Не удается найти указанный диск» — эта ошибка возникает, если вы работаете с Денвером, который при запуске эмулирует (создает) виртуальный диск. Причина – локальный сервер не запущен.

«Can’t connect to MySQL server on…» — такая ошибка возникает, если неправильно указан в параметрах хост или локальный сервер не запущен.

Не устанавливается MySQL – причин этого может быть много. Например, если вы пытаетесь инсталлировать СУБД через командную строку, то она должна быть запущена от имени администратора устройства.

Понятно, что это далеко не все «популярные» неполадки MySQL. Если «копнуть» глубже, то на их изучение уйдут годы. Помните, что причиной всех бед может стать обычный пробел или неправильная кавычка. И из-за этого ваш MySQL будет «глохнуть» уже на старте. Вот такая «заковырка» получается :).

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 или консоли).