Не запускается mysql debian

Обновлено: 03.07.2024

Статья давно не обновлялась, поэтому информация могла устареть.

Содержание

На корректно работающем VDS создание базы займет не больше 5 минут. В левом меню ISPmanager находим раздел "Базы данных" - Создать - заполнить необходимые поля - пароли рекомендуем создавать сложные.

Теперь немного о тех местах, где могут возникнуть сложности.

Раздела "Базы данных" нет в меню

Есть 2 возможных варианта и пути решения проблемы:

1)На сервере не запущен сервер баз данных MySQL:

  1. Проверить, активен ли сервис, вы можете в меню "Сервисы" панели ISPmanager. Попробуйте запустить или перезапустить его с помощью кнопок в панели.
  2. Если не помогло, перезапустите из консоли командой /etc/init.d/mysql restart для Ubuntu/Debian/Centos 6 или командой systemctl restart mariadb для Centos 7.

2) Проблемы с подключением к базе данных: Откройте пункт меню "Серверы баз данных", двойным кликом откройте свойства и нажмите "OK", ничего не меняя. Это принудительно обновит информацию о MySQL в панели управления. После этого обновите страницу - пункт "Базы данных" должен появиться.

Случается так, что пароль root от MySQL-сервера утерян, и надо установить новый. Делается следующим образом:

В Centos 6/Debian/Ubuntu:

Запускаем его без проверки таблиц прав:

Заходим root’ом без пароля:

Продолжаем для всех версий

В Centos 6/Debian/Ubuntu:

Авторизуемся как root с паролем new_password

MySQL - свободная реляционная система управления базами данных. Поиск проблем с сервисом лучше всего начинать с изучения логов. Для этого необходимо подключиться на сервер по ssh Их расположение разнится в зависимости от используемой файловой системы. В конфигурационном файле my.cnf нужно искать строки log и log-error, чтобы определить, где находятся логи. Также можно воспользоваться mysql запросом:

Если логирование не включено, сделать это можно следующим образом: Зайти в файл:

И в секцию [mysqld] добавить строку:

Выйти из файла, выполнить команды:

Следующая команда включит просмотр созданного лога в режиме реального времени(tail –f) и оставить его в фоне(&) что бы можно было параллельно запускать другие команды:

Перечень возможных проблем

Table './site/content' is marked as crashed and should be repaired

Если эта команда выдаёт ошибку, вставьте ключи раздельно

  • <USER> - имя пользователя базы данных, либо "root".
  • <PASSWORD> - заменить на пароль root от MySQL (его можно посмотреть в ISPmanager -> Настройки сервера -> Серверы баз данных -> двойной клик на MySQL)

Либо можно выполнить исправление конкретной базы данных

  • <USER> - имя пользователя базы данных, либо "root".
  • <PASSWORD> - заменить на пароль root от MySQL (его можно посмотреть в ISPmanager -> Настройки сервера -> Серверы баз данных -> двойной клик на MySQL)
  • <BD> - база данных, требуемая починки

mysql_connect() [function.mysql-connect]: Access denied for user 'user_xxx'@'localhost' (using password: YES)

Чаще всего связана с тем, что в настройках сайта указаны не верные данные(логин и/или пароль) для подключения к базе. Вариант решения: посмотреть в админ-панели сайта пользователь, пароль и название базы для подключения к базе. Зайти в ISPmanager -> настройки сервера -> кликнуть на базу, кликнуть на пользователя и в графу «Пароль» поставить пароль из админ-панели.

На сайте ошибка: Не удалось подключиться к базе данных

В зависимости от используемой CMS эта ошибка может по-разному выглядеть:

Подключится на сервер по SSH, выполнить:

Убедится что в ISPmanager, в разделе «Службы» лампочка mysqld горит.

В панели ISPmanager 5 нет пункта Базы данных

Это значит у вас в ISPmanager --- Серверы баз данных не создано ни одного сервера баз данных. Создайте

MySQL не запускается ни в сервисах, ни через консоль.

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

Проверить свободное место на диске.

Если не осталось места, удалить не нужные файлы.

Частая ситуация, когда логи сайтов разрастаются и места на диске свободного не остается, MySQL не может нормально работать(справедливо и для всех остальных сервисов – apache, exim и т.д.)

Снова пробуем перезапустить MySQL:

Если проблема не со свободным местом, в логах должны появиться записи, похожие на эту:

Смотрим записи с меткой [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. В ней нет соответствий для русских символов, все они будут заменены на вопросы. Кодировка хранения можно задать, например, так:

Если кодировка не указана - будет использовано значение параметра default-character-set из файла /etc/my.cnf (либо latin1, если параметра нет). Кстати, именно этот параметр редактирует ISPmanager в свойствах сервера баз данных.

2. Кодировка соединения. Это кодировка, в которой клиент (скрипт пользователя, форум, mysql-клиент и т.д.) общается с MySQL. Когда клиент подсоединяется к серверу, тот ему сообщает значение параметра default-character-set. Таким образом, они договариваются о том, в какой кодировке они будут общаться. Кодировку общения можно изменить запросом (его лучше выполнять сразу после соединения с сервером):

Кстати, множество современных правильных скриптов именно это и делают.

Одна сложность: есть ряд кривых клиентов, которые всего этого не понимают и общаются в какой-то своей кодировке. Персонально для них можно написать в /etc/my.cnf, секцию [mysqld]:

Что это означает? Сразу после подсоединения любого клиента, MySQL выполнит запрос "set names utf8", как будто смену кодировки общения запросил сам клиент.

Это всё, что нужно знать для решения любой проблемы с кодировками в MySQL. Осталось несколько уточнений (самое интересное :)

phpMyAdmin, mysqldump - обычные клиенты, на них действуют те же самые правила. Одно "но": на все PHP-скрипты (включая phpMyAdmin) действует default-character-set из секции [client] в my.cnf. Для mysqldump есть отдельная секция [mysqldump]. ISPmanager прописывает default-character-set во все секции.

Дамп базы - это обычный набор MySQL-команд. Если вы в самое его начало напишете "set names cp1251;", то эта команда тоже выполнится и MySQL будет считать, что дальше все данные в дампе идут в кодировке cp1251.

Кодировки в MySQL-командах пишутся без кавычек и без "-" (дефисов). Популярные в России кодировки: utf8, cp866 (DOS), cp1251 (windows-1251), koi8r.

И, наконец, пара советов:

  • Если вы в этом новичок, постарайтесь свести всё к одной кодировке. Пусть у вас дамп и "default-character-set" (напомню, влияет на кодировку хранилища при создании таблиц и на кодировку общения с клиентом) будет в одной кодировке. Это избавит от путаницы и решит 90% проблем.
  • Если есть возможность - используйте консольную утилиту mysqldump. phpMyAdmin - это дополнительная прослойка, которая лишь добавляет свою путаницу и свои баги.

Чтобы русифицировать базу данных MySQL, не вдаваясь в подробности почему и как, проделайте следующие процедуры:

1. В файле /etc/my.cnf добавьте следующие строчки:

1.1. Под разделом [client]

1.2. Под разделом [mysqld]

После этого перезапустите базу MySQL или весь ваш виртуальный сервер (из ISPmanager или консоль).

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

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

Почему не запускается MySQL сервер?

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

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

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

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

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

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

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

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

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

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

sudo systemctl stop mariadb

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

sudo mv /var/lib/mysql/ib_logfile0
sudo mv /var/lib/mysql/ib_logfile1

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

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

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

systemctl start mariadb

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

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

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

sudo systemctl restart mariadb

Выводы

MySQL наиболее широко используемая система управления базами данных (СУБД) с открытым исходным кодом. Она используется для хранения и извлечения данных во многих приложениях. В официальных репозиториях Debian 10 находится СУБД MariaDB в качестве альтернативы для MySQL, и в большинстве случаев, она работает хорошо.

Но если вы хотите, получить СУБД с характеристиками присущими лишь MySQL, то вам потребуется установить ее из официального репозитория MySQL. Далее мы разберем как выполняется установка MySQL Debian 10 от разработчиков.

Как установить MySQL 8 в Debian 10

Шаг 1: Добавление репозитория MySQL

Чтобы установить MySQL в Debian, вам необходимо скачать и установить APT репозиторий содержащийся в .deb пакете, который управляет настройкой и установкой программного обеспечения MySQL.

Во время установки пакета вам будет предложено настроить репозиторий MySQL APT для выбора версий сервера MySQL и других компонентов, которые вы хотите установить. Для установки последней версии оставьте все как есть, перейдите к Оk и нажмите Enter.


Шаг 2: Установка MySQL

После добавления репозитория обновите кэш пакетов apt и установите пакет сервера MySQL. При этом также будут установлены пакеты для клиента и другие зависимости.

sudo apt update
sudo apt install mysql-server

Во время установки появится диалоговое окно конфигурации, в котором нужно будет установить пароль пользователя root для MySQL. Введите безопасный и надежный пароль, а затем подтвердите его.


После этого вас предупредят о новой системе аутентификации, на основе SHA256, использующейся в MySQL, нажмите Ok. Выберите плагин аутентификации (оставьте опцию по умолчанию, чтобы использовать рекомендуемый плагин) и нажмите кнопку Enter, чтобы завершить процесс установки.



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

sudo systemctl status mysql


Есть несколько команд systemctl, которые вам нужно знать, чтобы управлять (запускать, перезапускать и останавливать) службу MySQL, когда это будет необходимо:

sudo systemctl start mysql
sudo systemctl restart mysql
sudo systemctl stop mysql
sudo systemctl reload mysql

Шаг 3: Настройка безопасности MySQL

Сервер MySQL из коробки не защищен, и для повышения безопасности потребуется запустить сценарий mysql_secure_installation. Выполните:

Прочитайте описание каждого вопроса и правильно ответьте на них. Во-первых, введите пароль пользователя root, который вы задали во время установки пакета. Вы можете выбрать y (для Yes) или n (для No), чтобы использовать или не использовать компонент VALIDATE PASSWORD.


Когда сценарий предложит вам установить новый пароль для пользователя root выберите No (вы уже установили его во время установки пакета). Затем внимательно следуйте другим подсказкам и выберите y (для YES), чтобы удалить анонимных пользователей, запретить удаленный вход под root в систему, удалить тестовую базу данных и перезагрузить таблицу привилегий.



Настройки MySQL Debian завершены, можно переходить к использованию.

Шаг 4: Проверка MySQL

После того как вы закончили настройку безопасности MySQL, можно начать использовать его для хранения данных для ваших веб-сайтов или веб-приложений. Чтобы получить доступ к оболочке MySQL, выполните следующую команду (пароль пользователя root введите по запросу, как показано на скриншоте):


Выводы

В этой статье мы рассказали, как выполняется установка MySQL Debian 10. Если у вас есть какие-либо вопросы по этой статье, спрашивайте в комментариях!

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

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

Скорость работы MySQL

Оптимизация без аналитики бессмысленна. Перед тем как переходить к оптимизации давайте посмотрим как работает база данных сейчас, есть ли запросы, которые выполняются очень медленно. Все настройки вашего сервиса mysql находятся в файле /etc/my.cnf. Чтобы включить отображение медленных запросов добавьте такие строки в my.cnf, в секцию [mysqld]:

Здесь первая строка включает запись лога медленных запросов, вторая указывает, что минимальное время запроса для внесения его в этот лог - две секунды. Еще можно включить в лог запросы, которые не используют индексы:

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

systemctl restart mariadb

tail -f /var/log/mariadb/slow-queries.log


Мы можем видеть, что есть запросы, которые выполняются больше, чем 10 секунд. Это, например, запрос

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

Можно его выполнить отдельно, в консоли mysql:


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

Оптимизация MySQL

Конфигурация MySQL достаточно сложная, но, к счастью, вам не нужно в нее сильно углубляться. Есть специальный скрипт под названием MySQLTunner, который анализирует работу MySQL и дает советы какие параметры нужно изменить и какие значения для них установить. Скрипт поддерживает большинство версий MariaDB, MySQL и Percona XtraDB. Нам понадобится загрузить три файла с помощью wget:


Первый из них - это сам скрипт, написанный на Perl, второй и третий - база данных простых паролей и уязвимостей. Они позволяют обнаружить проблемы с безопасностью. Дальше можно переходить к тестированию. Я использую сервер с настройками mysql по умолчанию, установленными панелью управления VestaCP.


Буквально за несколько минут скрипт выдаст полную статистику по работе MySQL. Количеству запросов, занимаемому объему памяти и эффективности работы буферов. Вы можете ознакомиться со всем этим, чтобы лучше понять в чем причина проблем. Проблемные места обозначены красными восклицательными знаками. Например, здесь мы видим, что размер буфера движка таблиц InnoDB (InnoDB buffer pool) намного меньше, чем должен быть для оптимальной работы:



Все параметры нужно добавлять в /etc/my.cnf. Еще раз замечу, что вы не копируете статью, а смотрите что вам выдала утилита. Начнем с query-cache.

query_cache_size=0
query_cache_type=0
query_cache_limit=1M

Скрипт рекомендует отключить кэш запросов. Query Cache - это кэш вызовов SELECT. Когда базе данных отправляется запрос, она выполняет его и сохраняет сам запрос и результат в этом кэше. И все бы ничего, но при использовании его вместе с InnoDB при любом изменении совпадающих данных кэш будет перестраиваться, что влечет за собой потерю производительности. И чем больше объем кэша, тем больше потери. Кроме того при обновлении кэша могут возникать блокировки запросов. Таким образом, если данные часто пишутся в базу данных - его надежнее отключить.

Оба параметра устанавливают размер памяти, которая используется для внутренних временных таблиц MySQL. Утилита рекомендует использовать объем больше 16 мегабайт, просто установите это ваше значение для обоих переменных, если у вас достаточно памяти, то можно выделить 32 или даже 64. Но важно чтобы оба значения совпадали, иначе будет использоваться минимальное.

Этот параметр отвечает за количество потоков, которые будут закэшированны. После того, как работа с подключением будет завершена, база данных не разорвет его, а закэширует, если количество кэшированных потоков не превышает ограничение. Утилита рекомендует больше четырех, например, 16.

Указывает, что не нужно пытаться определить доменное имя для подключений извне. Ускоряет работу, так как не тратится время на DNS запросы.

Этот параметр определяет размер буфера InnoDB в оперативной памяти, от этого размера очень сильно зависит скорость выполнения запросов. Значение зависит от размера ваших таблиц и количества данных в них. Если памяти недостаточно, запросы будут обрабатываться дольше. У меня используется стандартный объем 128, а нужно больше 652.


Размер файла лога innodb должен составлять 25% от размера буфера. В случае 800 мегабайт это будет 200М. Но тут есть одна проблема. Чтобы изменить размер лога нужно выполнить несколько действий. Поскольку мы изменили все нужные параметры перейдем к перезагрузке сервера. Для нашего лога нужно остановить сервис:

systemctl stop mariadb

Затем переместите файлы лога в /tmp:

mv /var/lib/mysql/ib_logfile[01] /tmp


И запустите сервис:

systemctl start mariadb

systemctl status mariadb


Тестирование результата

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

> USE база_данных;
> SELECT option_name, option_value FROM wpfc_options WHERE autoload = 'yes';


Первый раз он выполняется долго, может даже дольше чем обычно, но все последующие разы буквально мгновенно. Результат с более 3 секунд до 0,15. А если брать статистику из slow-log, то от более 12. Если в выводе утилиты для вас были предложены и другие оптимизации, то их тоже стоит применить.

Выводы

Как видите, оптимизация mysql это достаточно просто благодаря такому скрипту, но, в то же время, такая операция может очень сильно помочь, особенно высоконагруженным проектам. Еще лучше ускорить работу может только оптимизация запросов mysql. Не забывайте время от времени проверять параметры, чтобы быть уверенным что все в порядке. Если у вас остались вопросы, спрашивайте в комментариях!

На завершение лекция про производительность MySQL от Percona:

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, как показано ниже.

Если эти команды не показывают выходных данных, то сервер БД не работает. Поэтому клиент не может подключиться к нему. Чтобы запустить сервер, выполните команду systemctl.

Чтобы проверить состояние службы MySQL, используйте следующую команду:


Если в результате выполнения команды произошла ошибка службы MySQL, вы можете попробовать перезапустить службу и ещё раз проверить её состояние.


Если сервер работает (как показано) и вы по-прежнему видите эту ошибку, вам следует проверить, не заблокирован ли порт TCP/IP брандмауэром или любой другой службой блокировки портов.

Белкасофт , Удалённо , По итогам собеседования

Для поиска порта, который прослушивается сервером, используйте команду netstat .

Не удаётся подключиться к серверу MySQL

Ещё одна похожая и часто встречающаяся ошибка подключения — «(2003) Can’t connect to MySQL server on ‘server’ (10061)». Это означает, что в сетевом соединении было отказано.

Следует проверить, работает ли в системе сервер MySQL (смотрите выше) и на тот ли порт вы подключаетесь (как найти порт, можно посмотреть выше).

Похожие частые ошибки, с которыми вы можете столкнуться при попытке подключиться к серверу MySQL:

Ошибки запрета доступа в MySQL

В MySQL учётная запись (УЗ) определяется именем пользователя и клиентским хостом, с которого пользователь может подключиться. УЗ может также иметь данные для аутентификации (например, пароль).

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

В MySQL есть возможность создавать учётные записи, позволяющие пользователям клиентских программ подключаться к серверу и получать доступ к данным. Поэтому при ошибке доступа проверьте разрешение УЗ на подключение к серверу через клиентскую программу.

В консоли вводим команду:

Дать привилегии конкретному пользователю в БД по IP-адресу можно, используя следующие команды:

Ошибки запрещённого доступа могут также возникнуть из-за проблем с подключением к MySQL (см. выше).

Потеря соединения с сервером MySQL

С этой ошибкой можно столкнуться по одной из следующих причин:

  • плохое сетевое соединение;
  • истекло время ожидания соединения;
  • размер BLOB больше, чем max_allowed_packet .

В первом случае убедитесь, что у вас стабильное сетевое подключение (особенно, если подключаетесь удалённо).

Если проблема с тайм-аутом соединения (особенно при первоначальном соединении MySQL с сервером), увеличьте значение параметра connect_timeout .

В случае с размером BLOB нужно установить более высокое значение для max_allowed_packet в файле конфигурации /etc/my.cnf в разделах [mysqld] или [client] как показано ниже.

Если файл конфигурации недоступен, это значение можно установить с помощью следующей команды.

Слишком много подключений

Эта ошибка означает, что все доступные соединения используются клиентскими программами. Количество соединений (по умолчанию 151) контролируется системной переменной max_connections . Устранить проблему можно, увеличив значение переменной в файле конфигурации /etc/my.cnf .

Недостаточно памяти

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

Сначала нужно убедиться, что запрос правильный. Если это так, то нужно выполнить одно из следующих действий:

  • если клиент MySQL используется напрямую, запустите его с ключом --quick switch , чтобы отключить кешированные результаты;
  • если вы используете драйвер MyODBC, пользовательский интерфейс (UI) имеет расширенную вкладку с опциями. Отметьте галочкой «Do not cache result» (не кешировать результат).

Также может помочь MySQL Tuner. Это полезный скрипт, который подключается к работающему серверу MySQL и даёт рекомендации по настройке для более высокой производительности.

MySQL продолжает «падать»

Если такая проблема возникает, необходимо выяснить, заключается она в сервере или в клиенте. Обратите внимание, что многие сбои сервера вызваны повреждёнными файлами данных или индексными файлами.

Вы можете проверить состояние сервера, чтобы определить, как долго он работал.

Чтобы узнать время безотказной работы сервера, запустите команду mysqladmin .


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

Заключение

Самое важное при диагностике — понять, что именно вызвало ошибку. Следующие шаги помогут вам в этом:

Читайте также: