Ошибки сокета
MySQL управляет соединениями с сервером базы данных с помощью файла сокета, особого файла, который упрощает связь между различными процессами. Файл сокета MySQL называется mysqld.sock, а в системах Ubuntu он обычно хранится в каталоге /var/run/mysqld/. Этот файл создается сервисом MySQL автоматически.
Иногда изменения в вашей системе или конфигурации MySQL могут привести к тому, что MySQL не сможет прочитать файл сокета, а это, в свою очередь, не даст вам получить доступ к вашим базам данных. Наиболее распространенная ошибка сокета выглядит следующим образом:
Существует несколько причин, по которым может возникнуть эта ошибка, и несколько возможных способов ее устранения.
Одной из распространенных причин этой ошибки является то, что сервис MySQL изначально остановлен или не запускается. Это означает, что он не смог создать файл сокета. Чтобы выяснить, является ли это причиной возникновения ошибки, попробуйте запустить сервис через systemctl:
Затем попробуйте снова получить доступ к MySQL. Если вы все еще получаете ошибку сокета, проверьте расположение, в котором MySQL ищет файл сокета. Эта информация находится в файле mysqld.cnf:
Найдите параметр socket в разделе :
Закройте этот файл, а затем убедитесь, что файл mysqld.sock существует, выполнив команду ls в каталоге, где MySQL будет его искать:
Если файл сокета существует, вы увидите его в выводе этой команды:
Если файл не существует, возможно, причина в том, что MySQL пытается его создать, но не имеет соответствующих прав для этого. Вы можете убедиться в наличии необходимых привилегий, передав права собственности на каталог пользователю и группе mysql:
Затем убедитесь, что у пользователя mysql есть соответствующие права доступа к каталогу. 755 подойдет в большинстве случаев:
Перезапустите сервис MySQL, чтобы он мог снова попытаться создать файл сокета:
Затем попробуйте получить доступ к командной строке MySQL еще раз. Если вы по-прежнему сталкиваетесь с ошибкой сокета, вероятно, существует более глубокая проблема. В этом случае вы должны просмотреть лог ошибок, чтобы найти в нем подсказки.
Проблемы с запросами
Иногда пользователи сталкиваются с проблемами при отправке запросов. В некоторых системах баз данных, включая MySQL, операторы запроса должны заканчиваться точкой с запятой (;), как в следующем примере:
Если вы забудете добавить точку с запятой в конец запроса, запрос будет продолжаться в новой строке. Завершите запрос, введя точку с запятой и нажав Enter.
Некоторые пользователи сталкиваются с тем, что запросы обрабатываются чрезвычайно медленно. Один из способов определить, какой оператор является причиной замедления, – включить и просмотреть лог медленных запросов MySQL. Для этого откройте файл mysqld.cnf, который используется для настройки параметров сервера MySQL. Этот файл обычно хранится в каталоге /etc/mysql/mysql.conf.d/:
Просмотрите файл и найдите такой фрагмент:
Эти закомментированные директивы определяют стандартные параметры конфигурации 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 любые запросы, которые выполняются без индексов. Этот параметр не требуется для работы лога, но может быть полезен для выявления неэффективных запросов.
Раскомментируйте эти строки, удалив символы #. В результате вы получите:
Примечание: В MySQL 8+ по умолчанию этих директив в файле mysqld.cnf нет. Вам нужно добавить в конец файла такие строки:
После включения лога медленных запросов сохраните и закройте файл. Затем перезапустите MySQL:
Эти параметры помогут найти проблемные операторы в логе медленных запросов. Вы можете сделать это с помощью less:
Определив запросы, вызывающие замедление, вы можете обратиться к мануалу Оптимизация запросов и таблиц MySQL и MariaDB, который поможет их оптимизировать.
Кроме того, MySQL включает оператор EXPLAIN, который предоставляет информацию о выполнении запросов. Эта страница из официальной документации MySQL рассказывает о том, как использовать EXPLAIN для выявления неэффективных запросов.
Базовые запросы описаны в мануале Запросы в MySQL.
Подготовка к запуску
Установка была «чистая» — все нужные пользователи, привилегии и базы заблаговременно забэкаплены, а каталог датадир очищен.
Конфиг /usr/local/etc/my.cnf изменил свое расположение, он переместился в /usr/local/etc/mysql/my.cnf по дефолту.
Из конфига пришлось убрать директивы управления кешем (8.0 их не поддерживает).
Так как клиенты пока не поддерживают аутентификацию новым методом caching_sha2_password, в конфиг добавлена строчка, активирующая старый метод:
default-authentication-plugin = mysql_native_password
Маленькое замечание. Эту строчку необходимо добавить до инициализации служебной базы mysql, так как пользователям при их создании сразу прописывается желаемый метод аутентификации.
Первоначальный запуск
При первом запуске штатным стартовым скриптом выскочила ошибка такого вида:
/usr/local/etc/rc.d/mysql-server: WARNING: failed precmd routine for mysql
Анализ ситуации показал, что, в частности, служебная база mysql не создается в полном объеме. Решение довольно простое — ручной запуск команды инициализации на пустой директории датадир:
# rm -rf /var/db/mysql/* # /usr/local/libexec/mysqld --initialize-insecure --user=mysql
В результате в директории /var/db/mysql/mysql появились файлы таблиц mysql, которых не оказалось при штатном запуске. В таблице пользователей создана учетная запись root@localhost без пароля.
После этого можно стартовать сервер стандартным образом:
# service mysql-server start
Настройка удаленного доступа
Многие веб-сайты и приложения запускаются с веб-сервера и базы данных, размещенных на одной машине. Однако со временем такая установка может стать неудобной, а еще ее сложно масштабировать. Общее решение такой проблемы – разделение этих функций путем настройки удаленной базы данных, что позволяет серверу и базе данных работать отдельно, на индивидуальных машинах.
Одна из наиболее распространенных проблем, с которыми сталкиваются пользователи при настройке удаленной базы данных MySQL, заключается в том, что их экземпляр настроен на прослушивание только локальных соединений. Это настройка по умолчанию для MySQL, но она не подходит для удаленной базы данных, поскольку MySQL не имеет возможности прослушивать внешний IP-адрес, по которому можно связаться с сервером. Чтобы изменить это, откройте файл mysqld.cnf:
В файле найдите строку bind-address:
По умолчанию это значение 127.0.0.1, что означает, что сервер будет слушать только локальные соединения. Вам нужно изменить эту директиву и указать внешний IP-адрес. В целях устранения неполадок вы можете установить в этой директиве IP-адрес с подстановочными символами *, :: или 0.0.0.0:
Примечание: В MySQL 8+ директивы bind-address по умолчанию нет в файле mysqld.cnf. В этом случае добавьте в конец файла следующую выделенную строку:
Сохраните и закройте файл. Затем перезапустите MySQL:
Теперь попробуйте получить удаленный доступ к БД.
Если сейчас вы можете получить доступ к своей БД, это подтверждает, что проблема была в директиве bind-address и вы ее устранили
Однако обратите внимание, что настройка bind-address на 0.0.0.0 небезопасна, так как позволяет подключаться к вашему серверу с любого IP-адреса. Если же вы все еще не можете получить доступ к базе данных удаленно, проблема может быть вызвана чем-то другим
В любом случае вам может быть полезно обратиться к мануалу Настройка удаленной базы данных MySQL для оптимизации производительности сайта в Ubuntu 18.04.
Недостаточно памяти
Если такая ошибка возникла, это может означать, что в MySQL недостаточно памяти для хранения всего результата запроса.
Сначала нужно убедиться, что запрос правильный. Если это так, то нужно выполнить одно из следующих действий:
- если клиент MySQL используется напрямую, запустите его с ключом , чтобы отключить кешированные результаты;
- если вы используете драйвер MyODBC, пользовательский интерфейс (UI) имеет расширенную вкладку с опциями. Отметьте галочкой «Do not cache result» (не кешировать результат).
Также может помочь MySQL Tuner. Это полезный скрипт, который подключается к работающему серверу MySQL и даёт рекомендации по настройке для более высокой производительности.
Настройка бесплатного ssl сертификата Lets Encrypt
Устанавливаем пакет certbot для получения бесплатного ssl сертификата от let’s encrypt. В репозиториях его пока нет, поэтому поставим вручную с сайта разрабочиков.
# cd ~ # wget https://dl.eff.org/certbot-auto # mv certbot-auto /usr/local/bin/certbot-auto # chown root /usr/local/bin/certbot-auto # chmod 0755 /usr/local/bin/certbot-auto
При первом запуске certbot-auto предложит установить зависимости, которые ему нужны для работы.
# certbot-auto
После установки зависимостей, certbot ругнется на то, что не смог настроить нам nginx, но и хорошо, мы уже сами все настроили. Наша следующая задача — получить бесплатные сертификаты. Для этого временно остановим nginx, если он вдруг оказался запущен и подтвердим владение доменами с помощью temporary webserver, который certbot поднимет сам на время верификации доменов.
# systemctl stop nginx # certbot-auto certonly
How would you like to authenticate with the ACME CA? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: Nginx Web Server plugin (nginx) 2: Spin up a temporary webserver (standalone) 3: Place files in webroot directory (webroot) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number then (press 'c' to cancel): 2 Plugins selected: Authenticator standalone, Installer None Please enter in your domain name(s) (comma and/or space separated) (Enter 'c' to cancel): z.serveradmin.ru Obtaining a new certificate Performing the following challenges: http-01 challenge for z.serveradmin.ru Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/z.serveradmin.ru/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/z.serveradmin.ru/privkey.pem Your cert will expire on 2020-01-05. To obtain a new or tweaked version of this certificate in the future, simply run certbot-auto again. To non-interactively renew *all* of your certificates, run "certbot-auto renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le
То же самое делаем для второго домена — pma.serveradmin.ru.
После того, как получили сертификаты, можно проверить конфиг nginx и запустить его. Ошибок быть не должно. Если они есть, то разбирайтесь с ними, возможно где-то ошиблись.
# nginx -t # systemctl start nginx
Настройка nginx на этом завершена. Он должен корректно запуститься и работать в рабочем режиме.
Теперь сделаем так, чтобы сертификаты автоматически обновлялись перед истечением срока действия. Для этого необходимо изменить конфигурации доменов. Они располагаются в директории /etc/letsencrypt/renewal. Так как мы генерировали сертификаты с помощью временного веб сервера, наш текущий конфиг z.serveradmin.ru.conf выглядит вот так:
# renew_before_expiry = 30 days version = 0.39.0 archive_dir = /etc/letsencrypt/archive/z.serveradmin.ru cert = /etc/letsencrypt/live/z.serveradmin.ru/cert.pem privkey = /etc/letsencrypt/live/z.serveradmin.ru/privkey.pem chain = /etc/letsencrypt/live/z.serveradmin.ru/chain.pem fullchain = /etc/letsencrypt/live/z.serveradmin.ru/fullchain.pem # Options used in the renewal process account = a9e5d37f80dafd9f0a2f9a2b019cbc3e authenticator = standalone server = https://acme-v02.api.letsencrypt.org/directory
Приводим его к следующему виду:
# renew_before_expiry = 30 days version = 0.39.0 archive_dir = /etc/letsencrypt/archive/z.serveradmin.ru cert = /etc/letsencrypt/live/z.serveradmin.ru/cert.pem privkey = /etc/letsencrypt/live/z.serveradmin.ru/privkey.pem chain = /etc/letsencrypt/live/z.serveradmin.ru/chain.pem fullchain = /etc/letsencrypt/live/z.serveradmin.ru/fullchain.pem # Options used in the renewal process account = a9e5d37f80dafd9f0a2f9a2b019cbc3e authenticator = webroot server = https://acme-v02.api.letsencrypt.org/directory post_hook = nginx -s reload `webroot_map` z.serveradmin.ru = /web/sites/z.serveradmin.ru/www
По аналогии делаете с остальными виртуальными хостами, для которых используете бесплатные сертификаты let’s encrypt. Осталось дело за малым — настроить автоматический выпуск новых ssl сертификатов, взамен просроченным. Для этого добавляем в /etc/crontab следующую строку:
# Cert Renewal 30 2 * * * root /usr/local/bin/certbot-auto renew --post-hook "nginx -s reload" >> /var/log/le-renew.log
Все, с сертификатами закончили. Двигаемся дальше в настройке web сервера.
Ошибки запрета доступа в MySQL
В MySQL учётная запись (УЗ) определяется именем пользователя и клиентским хостом, с которого пользователь может подключиться. УЗ может также иметь данные для аутентификации (например, пароль).
Причин для запрета доступа может быть много. Одна из них связана с учётными записями MySQL, которые сервер разрешает использовать клиентским программам при подключении. Это означает, что имя пользователя, указанное в соединении, может не иметь прав доступа к базе данных.
В MySQL есть возможность создавать учётные записи, позволяющие пользователям клиентских программ подключаться к серверу и получать доступ к данным. Поэтому при ошибке доступа проверьте разрешение УЗ на подключение к серверу через клиентскую программу.
Увидеть разрешённые привилегии учётной записи можно, выполнив в консоли команду
Входим в консоль (пример для Unix, для Windows консоль можно найти в стартовом меню):
В консоли вводим команду:
Дать привилегии конкретному пользователю в БД по IP-адресу можно, используя следующие команды:
Ошибки запрещённого доступа могут также возникнуть из-за проблем с подключением к MySQL (см. выше).
