Восстановление базы данных mysql connect error

Vladislav S., Максим Кубрак,
Спасибо за ответы, подскажите что надо откорректировать в файлах, по видимому, резервная копия, которую я пытался восстановить была со старым паролем, может из-за этого проблемы.

Подскажите что откорректировать в файлах надо, боюсь накосячить.

Спасибо.

Это dbconn.php
<?
define(«BX_USE_MYSQLI», true);
define(«DBPersistent», false);
$DBType = «mysql»;
$DBHost = «localhost»;
$DBLogin = «kkniga_falinnikb»;
$DBPassword = «4k3fxlRU»;
$DBName = «kkniga_falinnikb»;
$DBDebug = false;
$DBDebugToFile = false;

define(«DELAY_DB_CONNECT», true);
define(«CACHED_b_file», 3600);
define(«CACHED_b_file_bucket_size», 10);
define(«CACHED_b_lang», 3600);
define(«CACHED_b_option», 3600);
define(«CACHED_b_lang_domain», 3600);
define(«CACHED_b_site_template», 3600);
define(«CACHED_b_event», 3600);
define(«CACHED_b_agent», 3660);
define(«CACHED_menu», 3600);

define(«BX_UTF», true);
define(«BX_FILE_PERMISSIONS», 0644);
define(«BX_DIR_PERMISSIONS», 0755);
@umask(~BX_DIR_PERMISSIONS);
define(«BX_DISABLE_INDEX_PAGE», true);
?>

Это .settings.php

<?php
return array (
 ‘utf_mode’ =>
 array (
   ‘value’ => true,
   ‘readonly’ => true,
 ),
 ‘cache_flags’ =>
 array (
   ‘value’ =>
   array (
     ‘config_options’ => 3600,
     ‘site_domain’ => 3600,
   ),
   ‘readonly’ => false,
 ),
 ‘cookies’ =>
 array (
   ‘value’ =>
   array (
     ‘secure’ => false,
     ‘http_only’ => true,
   ),
   ‘readonly’ => false,
 ),
 ‘exception_handling’ =>
 array (
   ‘value’ =>
   array (
     ‘debug’ => true,
     ‘handled_errors_types’ => 4437,
     ‘exception_errors_types’ => 4437,
     ‘ignore_silence’ => false,
     ‘assertion_throws_exception’ => true,
     ‘assertion_error_type’ => 256,
     ‘log’ => NULL,
   ),
   ‘readonly’ => false,
 ),
 ‘connections’ =>
 array (
   ‘value’ =>
   array (
     ‘default’ =>
     array (
       ‘className’ => ‘\Bitrix\Main\DB\MysqliConnection’,
       ‘host’ => ‘localhost’,
       ‘database’ => ‘******’,
       ‘login’ => ‘******’,
       ‘password’ => ‘******’,
       ‘options’ => 2,
     ),
   ),
   ‘readonly’ => true,
 ),
);

Не запускается сайт, не стартует mysql. Сообщение о том, что БД не запустилась выводится на любой странице кроме основной (она грузится).

[BitrixMainDBConnectionException]
Mysql connect error [127.0.0.1]: (2002) Connection refused (400)
/home/bitrix/www/bitrix/modules/main/lib/db/mysqliconnection.php:82
#0: BitrixMainDBMysqliConnection->connectInternal()
/home/bitrix/www/bitrix/modules/main/lib/data/connection.php:53
#1: BitrixMainDataConnection->getResource()
/home/bitrix/www/bitrix/modules/main/lib/db/mysqlisqlhelper.php:21
#2: BitrixMainDBMysqliSqlHelper->forSql(string)
/home/bitrix/www/bitrix/modules/main/lib/config/option.php:193
#3: BitrixMainConfigOption::load(string)
/home/bitrix/www/bitrix/modules/main/lib/config/option.php:38
#4: BitrixMainConfigOption::get(string, string, string)
/home/bitrix/www/bitrix/modules/main/lib/httprequest.php:394
#5: BitrixMainHttpRequest->prepareCookie(array)
/home/bitrix/www/bitrix/modules/main/lib/httprequest.php:71
#6: BitrixMainHttpRequest->__construct(object, array, array, array, array)
/home/bitrix/www/bitrix/modules/main/lib/httpapplication.php:49
#7: BitrixMainHttpApplication->initializeContext(array)
/home/bitrix/www/bitrix/modules/main/lib/application.php:130
#8: BitrixMainApplication->initializeExtendedKernel(array)
/home/bitrix/www/bitrix/modules/main/include.php:21
#9: require_once(string)
/home/bitrix/www/bitrix/modules/main/include/prolog_before.php:14
#10: require_once(string)
/home/bitrix/www/bitrix/modules/main/include/prolog.php:10
#11: require_once(string)
/home/bitrix/www/bitrix/header.php:1
#12: require(string)
/home/bitrix/www/catalog/index.php:2
#13: include_once(string)
/home/bitrix/www/bitrix/modules/main/include/urlrewrite.php:160
#14: include_once(string)
/home/bitrix/www/bitrix/urlrewrite.php:2

В файле /var/log/mysql/error.log следующие сообщения:

2021-12-28T04:42:48.871067Z 0 [Warning] Changed limits: max_open_files: 5000 (requested 16238)
2021-12-28T04:42:48.871323Z 0 [Warning] Changed limits: table_open_cache: 2477 (requested 8096)
2021-12-28T04:42:49.064840Z 0 [Warning] ‘NO_AUTO_CREATE_USER’ sql mode was not set.
2021-12-28T04:42:49.066759Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.33-36) starting as process 1615 …
2021-12-28T04:42:49.072036Z 0 [Note] InnoDB: PUNCH HOLE support available
2021-12-28T04:42:49.072080Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2021-12-28T04:42:49.072089Z 0 [Note] InnoDB: Uses event mutexes
2021-12-28T04:42:49.072096Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2021-12-28T04:42:49.072104Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.7
2021-12-28T04:42:49.072111Z 0 [Note] InnoDB: Using Linux native AIO
2021-12-28T04:42:49.072380Z 0 [Note] InnoDB: Number of pools: 1
2021-12-28T04:42:49.072522Z 0 [Note] InnoDB: Using CPU crc32 instructions
2021-12-28T04:42:49.074495Z 0 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M
2021-12-28T04:42:49.085615Z 0 [Note] InnoDB: Completed initialization of buffer pool
2021-12-28T04:42:49.089702Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2021-12-28T04:42:49.101559Z 0 [Note] InnoDB: Recovering partial pages from the parallel doublewrite buffer at /var/lib/mysql/xb_doublewrite
2021-12-28T04:42:49.105272Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2021-12-28T04:42:49.108314Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 4280861412938
2021-12-28T04:42:49.129319Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 4280862209170
2021-12-28T04:42:49.129579Z 0 [Note] InnoDB: Database was not shutdown normally!
2021-12-28T04:42:49.129592Z 0 [Note] InnoDB: Starting crash recovery.
2021-12-28T04:42:49.142699Z 0 [Note] InnoDB: Created parallel doublewrite buffer at /var/lib/mysql/xb_doublewrite, size 3932160 bytes
2021-12-28T04:42:49.147707Z 0 [ERROR] InnoDB: Trying to access page number 4294967295 in space 0, space name innodb_system, which is outside the tablespace bounds. Byte offset 0, len 16384, i/o type read. If you get this error at mysqld startup, please check that your my.cnf matches the ibdata files that you have in the MySQL server.
2021-12-28T04:42:49.147735Z 0 [ERROR] InnoDB: Server exits.

В чем может быть проблема? HELP!!!

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

This is for Mac OS X with the native installation of Apache HTTP and custom installation of MySQL.

The answer is based on @alec-gorge’s excellent response, but since I had to google some specific changes to have it configured in my configuration, mostly Mac OS X-specific, I thought I’d add it here for the sake of completeness.

Enable PHP5 support for Apache HTTP

Make sure the PHP5 support is enabled in /etc/apache2/httpd.conf.

Edit the file with sudo vi /etc/apache2/httpd.conf (enter the password when asked) and uncomment (remove ; from the beginning of) the line to load the php5_module module.

LoadModule php5_module libexec/apache2/libphp5.so

Start Apache HTTP with sudo apachectl start (or restart if it’s already started and needs to be restarted to re-read the configuration file).

Make sure that /var/log/apache2/error_log contains a line that tells you the php5_module is enabled — you should see PHP/5.3.15 (or similar).

[notice] Apache/2.2.22 (Unix) DAV/2 PHP/5.3.15 with Suhosin-Patch configured -- resuming normal operations

Looking up Socket file’s name

When MySQL is up and running (with ./bin/mysqld_safe) there should be debug lines printed out to the console that tell you where you can find the log files. Note the hostname in the file name — localhost in my case — that may be different for your configuration.

The file that comes after Logging to is important. That’s where MySQL logs its work.

130309 12:17:59 mysqld_safe Logging to '/Users/jacek/apps/mysql/data/localhost.err'.
130309 12:17:59 mysqld_safe Starting mysqld daemon with databases from /Users/jacek/apps/mysql/data

Open the localhost.err file (again, yours might be named differently), i.e. tail -1 /Users/jacek/apps/mysql/data/localhost.err to find out the socket file’s name — it should be the last line.

$ tail -1 /Users/jacek/apps/mysql/data/localhost.err
Version: '5.5.27'  socket: '/tmp/mysql.sock'  port: 3306  MySQL Community Server (GPL)

Note the socket: part — that’s the socket file you should use in php.ini.

There’s another way (some say an easier way) to determine the location of the socket’s file name by logging in to MySQL and running:

show variables like '%socket%';

Configuring PHP5 with MySQL support — /etc/php.ini

Speaking of php.ini…

In /etc directory there’s /etc/php.ini.default file. Copy it to /etc/php.ini.

sudo cp /etc/php.ini.default /etc/php.ini

Open /etc/php.ini and look for mysql.default_socket.

sudo vi /etc/php.ini

The default of mysql.default_socket is /var/mysql/mysql.sock. You should change it to the value you have noted earlier — it was /tmp/mysql.sock in my case.

Replace the /etc/php.ini file to reflect the socket file’s name:

mysql.default_socket = /tmp/mysql.sock
mysqli.default_socket = /tmp/mysql.sock

Final verification

Restart Apache HTTP.

sudo apachectl restart 

Check the logs if there are no error related to PHP5. No errors means you’re done and PHP5 with MySQL should work fine. Congrats!

Суть и причины возникновения ошибки установки соединения с базой данных

Чтобы понять, что означает “Ошибка установки соединения с базой данных” (Error establishing a database connection) разберемся, как работает WordPress и выясним, что такое база данных.

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

База данных — это и есть совокупность информации, организованная так, чтобы при необходимости компьютер смог ее найти и обработать. Все сведения о вашем WordPress сайте хранится в базе данных на серверах вашего хостинг- провайдера. Любое действие на сайте приводит кому, что WordPress посылает запрос на нужную информацию в базу данных. Если запрос успешно обработан, то пользователь получает нужную информацию.

Одним из наиболее важных файлов в WordPress является wp-config.php файл. Он находится в корневой директории и содержит сведения о конфигурации вашего сайта, в том числе и информацию о подключении к базе данных. Важно, чтобы эта информация была прописана в строго определенном порядке:

• Database Name — Имя базы данных
• Database Username — Имя пользователя базы данных
• Database Password — Пароль пользователя базы данных
• Database Host — Сервер базы данных

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

Первые шаги устранения ошибки установки соединения

Рассмотрим основные причины ошибки установки соединения с базой данных и способы их устранения.

Скачать файл

Прежде всего, настоятельно рекомендуем создать резервную копию всей важной информации и обновлять ее после каждого значимого изменения. Тогда вы гарантированно не потеряете данные. А в случае серьезной ошибки и восстановления базы данных, не столкнетесь с необходимостью создания сайта с нуля. Для создания резервной копии используются плагины Duplicator или All-in-One WP Migration.

Есть много программных модулей для резервного копирования, но они не смогут вам помочь при отсутствии доступа в админку.

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

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

3 способа устранения ошибки установки соединения с БД

Проверка памяти сервера

Предположим, вы проверили учетные данные в фале wp-config.php и убедились в их корректности. Следующим шагом следует проверить сервер на наличие памяти. Довольно часто ошибка соединения возникает из-за перегруженности сервера. Если сервер хостинг-провайдера испытывает трудности, то и ваш сайт WordPress будет замедляться.

В первую очередь удостоверимся, что MySQL работает, и памяти для обработки данных WordPress достаточно.

Подключитесь к удаленному серверу через SSH, используя IP-адрес сервера:

ssh 8host@ <server IP>

Затем убедимся, работает ли MySQL с помощью утилиты netstat. Она позволяет отслеживать проблемы, связанные с производительностью сети. Чтобы увидеть список TCP-портов, которые прослушиваются, и имена программ, используйте команду:

sudo netstat -plt

где флаги –p, –l и –t означают program (программы), listening (прослушивание) и TCP соответственно.

В результате выполнения команды вы увидите список. Найдите в нем mysqld – это сервер MySQL:

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

sudo systemctl start mysql

Заметьте, что в некоторых версиях и дистрибутивах Linux используется mysqld или mysql-server, а не mysql. Попробуйте разные варианты, чтобы определить, какой из них применяется в вашей системе.

После выполнения этой команды сервер запустится. Проверьте это с помощью sudo netstat -plt, как описано ранее.

По какой причине сервер MySQL может завершить работу? Эта система очень эффективна и производительна, но не всегда стабильна. Если количество одновременно выполняемых задач велико, то она существенно замедляется. Чтобы минимизировать возможные проблемы, нужно следить за объемом доступной памяти.

Проверьте log-файлы и ищите в них сообщения об ошибках. Для поиска используйте команду zgrep:

zgrep -a «allocate memory» /var/log/mysql/error.log*

В результате выполнения данной команды вы увидите все log-файлы, содержащие error.log и ‘allocate memory’. Поиск будет выполняться по файлам в директории /var/log/mysql/.

На выводе вы можете увидеть подобную строку:

2017-04-11T17:38:22.604644Z 0 [ERROR] InnoDB: Cannot allocate memory for the buffer pool

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

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

Если команда zgrep не выдала списка log-файлов, то сервер не испытывает проблем с нехваткой памяти. Значит проблемы установки соединения с базой данных может быть связана неверными учетными данными MySQL.

Проверка учётных данных MySQL

Если вы поменяли хостинг-провайдера или переместили установку WordPress на новый сервер, то информация в файле wp-config.php становится неактуальной. Вам необходимо поменять соответствующие строки в файле, иначе подключение к базе данных будет невозможно.

Чтобы найти этот файл используйте команду find:

sudo find / -name «wp-config.php»

Данная команда будет искать файл с указанным именем в корневой папке. Если он будет найден, то на выходе вы увидите путь к найденному файлу:

/var/www/html/wp-config.php

Чтобы открыть его в текстовом редакторе nano, напишите:

sudo nano /var/www/html/wp-config.php

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

/** The name of the database for WordPress */

define(‘DB_NAME’, ‘database_name’);

/** MySQL database username */

define(‘DB_USER’, ‘database_username’);

/** MySQL database password */

define(‘DB_PASSWORD’, ‘database password’);

Вместо ‘database_name’, ‘database_username’ и ‘database_password’ должны быть указаны корректные данные о вашей БД. При необходимости отредактируйте их. На забудьте сохранить файл и выйти из редактора, нажатием CTRL-O, CTRL-X.

Чтобы убедиться, что проблема решена, попробуйте подключиться к базе данных. Для этого наберите команду:

mysqlshow -u database_username -p

Затем введите пароль. Если имя пользователя или пароль не верные, то вы увидите ошибку Access denied. В противном случае на экран будет выведена информация обо всех базах данных, к которым у вас есть доступ.

+———————+

|Databases |

+———————+

| information_schema |

| database_name |

+———————+

Если вы видите имя нужной базы данных в списке, то в файле wp-config.php указаны корректные данные. Теперь можно перезапустить WordPress сайт.

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

Восстановление базы данных WordPress

Случается, что база данных WordPress оказывается поврежденной. Причин, по которым такое происходит, может быть несколько:

• неудачное обновление;
• сбой базы данных;
• некорректный плагин.

Непосредственно на сайте в таком случае вы все также увидите сообщение — «ошибка установки соединения с базой данных».

Попытаемся восстановить БД. Откройте файл wp-config.php с помощью текстового редактора:

sudo nano /var/www/html/wp-config.php

Вставьте в файл строку:

define(‘WP_ALLOW_REPAIR’, true);

Таким образом включается функция восстановления базы данных. Сохраните файл и закройте его.

Затем откройте браузер и перейдите по следующему URL:

http://www.example.com/wp-admin/maint/repair.php

Не забудьте заменить www.example.com на URL вашего сайта или укажите IP.

Тогда вы увидите следующее сообщение на экране:

WordPress can automatically look for some common database problems and repair them.

Выберите вариант Repair Database. В появившейся странице вы увидите процент проверенных и восстановленных данных.

После восстановления вернитесь к файлу wp-config.php. Удалите из него функцию, ответственную за восстановление базы данных. Это необходимо сделать из соображений безопасности, иначе доступ к восстановлению БД будет у всех.

Если после восстановления базы данных WordPress все еще выдает ошибку о проблеме соединения, восстановите базу данных из бэкапа (резервной копии).

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

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

Дополнительные методы устранения ошибки установки соединения с БД

Следующие способы устранения ошибки установки соединения с базой данных категорически не рекомендуется использовать начинающим администраторам WordPress! Переходите к ним только в том случае, если не помогли методы, описанные ранее. Не используйте их, если у вас нет валидной резервной копии вашего сайта!

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

• Обновление настройки в wp_options

Некоторые пользователи отмечали, что ошибка была устранена после выполнения запроса к БД через phpMyAdmin:

[sql]UPDATE wp_options SET option_value=’ http://your_site.ru’ WHERE option_name=’siteurl’;[/sql]

Где вместо ’your_site.ru ‘укажите URL вашего сайта.

• Подключение к базе данных с правами root

Если вы используете виртуальный сервер и можете воспользоваться root правами, то попробуйте подключиться к БД через файл test.php. В случае успеха, попробуйте также подключиться к БД вашего сайта через файл wp-config.php. Затем проверьте работу сайта.

Работать на сервере под учётной записью root – большая ошибка. Обязательно создайте нового пользователя через phpMyAdmin. Не забудьте внести в wp-config.php файл логин и пароль созданного пользователя.

Профилактика возникновения ошибки установки соединения с базой данных

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

• Тщательно выбирайте хостинг-провайдера, который подходит именно для работы с CMS WordPress. Он должен иметь хорошую техподдержку, обеспечивать высокую скорость и стабильность. Зачастую проблемы в работе сайта связаны именно с хостингом.
• Регулярно делайте бэкап. Вы можете самостоятельно выбрать один из плагинов, например, UpdraftPlus, Duplicator или All-in-One WP Migration.

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

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

Mysql connect error localhost 2002 No such file or directory 400

Сайт на движке Bitrix может работать исправно и вдруг в самый неподходящий момент при заходе на сайт может возникнуть ошибка «Mysql connect error localhost 2002 No such file or directory 400».

1. Закончилось свободное место на диске.
2. Некорректные данные для подключения к базе данных.
3. Проблема с базой данных.

Первым делом нужно зайти в панель управления хостингом и проверить, не закончилось ли место на диске (в разных системах может быть по-разному, к примеру — Инструменты — Свободное место). Если гипотеза подтвердилась, идем в менеджер файлов — www/названиеСайта/bitrix/backup — удаляем лишние бэкапы, либо пишем запрос в техподдержку хостинга, чтобы почистили место на диске, заодно можно будет в дальнейшем сделать так, чтобы на диске оставлять резерв, чтобы место внезапно не кончалось в будущем.

Возможно, на сайте не включен дебаг-режим и ошибки вы не увидите, чтобы включить дебаг-режим: менеджер файлов — www/названиеСайта/bitrix/php_interface — в файле dbconn.php в $DBDebug и $DBDebugToFile заменить с false на true.

Чтобы изменить настройки подключения к базе данных, в том же файле dbconn.php можно изменить значения в $DBLogin, $DBPassword, $DBName на нужные. Также настройки подключения к БД хранятся в файле www/названиеСайта/bitrix.settings.php (поля database, login, password соответственно).

Если повреждена база данных, зайти в резервные копии в панели управления хостингом и восстановить базу данных из резервной копии (на момент, когда база работала нормально).

Источник

Упал mysql. Нужна помощь

Имеем BitrixVM 7.3.0
На виртуалке закончилось свободное место. В результате сайт стал выдавать такое:

[BitrixMainDBConnectionException] Mysql connect error [localhost]: (2002) Connection refused (400)
/home/bitrix/www/bitrix/modules/main/lib/db/mysqliconnection ­.php:65
#0: BitrixMainDBMysqliConnection->connectInternal()
/home/bitrix/www/bitrix/modules/main/lib/db/mysqliconnection ­.php:122
#1: BitrixMainDBMysqliConnection->queryInternal(string, array, NULL)
/home/bitrix/www/bitrix/modules/main/lib/db/connection.php:330
#2: BitrixMainDBConnection->query(string)
/home/bitrix/www/bitrix/modules/main/lib/config/option.php:226
#3: BitrixMainConfigOption::load(string, NULL)
/home/bitrix/www/bitrix/modules/main/lib/config/option.php:53
#4: BitrixMainConfigOption::get(string, string, string)
/home/bitrix/www/bitrix/modules/main/lib/httprequest.php:370
#5: BitrixMainHttpRequest->prepareCookie(array)
/home/bitrix/www/bitrix/modules/main/lib/httprequest.php:68
#6: BitrixMainHttpRequest->__construct(object, array, array, array, array)
/home/bitrix/www/bitrix/modules/main/lib/httpapplication.php:46
#7: BitrixMainHttpApplication->initializeContext(array)
/home/bitrix/www/bitrix/modules/main/lib/application.php:122
#8: BitrixMainApplication->initializeExtendedKernel(array)
/home/bitrix/www/bitrix/modules/main/include.php:23
#9: require_once(string)
/home/bitrix/www/bitrix/modules/main/include/prolog_before.php:14
#10: require_once(string)
/home/bitrix/www/bitrix/modules/main/include/prolog.php:10
#11: require_once(string)
/home/bitrix/www/bitrix/header.php:1
#12: require(string)
/home/bitrix/www/crm/deal/index.php:2
#13: include_once(string)
/home/bitrix/www/bitrix/modules/main/include/urlrewrite.php:159
#14: include_once(string)
/home/bitrix/www/bitrix/urlrewrite.php:2

В консоль доступ есть. Диск расширили, места достаточно.

Но Mysql не стартует.

systemctl status mysql говорит:

● mysqld.service — MySQL Server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
Active: activating (start) since Wed 2018-07-25 11:28:59 MSK; 2s ago
Docs: man:mysqld(8)
http://dev.mysql.com/doc/refman/en/using-systemd.html
Process: 18166 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)
Control: 18184 (mysqld)
CGroup: /system.slice/mysqld.service
├─18184 /usr/sbin/mysqld —daemonize —pid-file=/var/run/mysqld/mysqld.pid
└─18187 /usr/sbin/mysqld —daemonize —pid-file=/var/run/mysqld/mysqld.pid

Jul 25 11:28:59 bitrix systemd[1]: Starting MySQL Server.

journalctl -xe говорит:

— Unit mysqld.service has failed.
—
Jul 25 11:26:08 bitrix systemd[1]: mysqld.service failed.
Jul 25 11:26:08 bitrix systemd[1]: mysqld.service holdoff time over, scheduling restart.
Jul 25 11:26:08 bitrix systemd[1]: Starting MySQL Server.
— Subject: Unit mysqld.service has begun start-up
— Defined-By: systemd
— Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
—
— Unit mysqld.service has begun starting up.
Jul 25 11:26:12 bitrix mysqld[15962]: Unable to determine if daemon is running: Success
Jul 25 11:26:12 bitrix systemd[1]: mysqld.service: control process exited, code=exited status=1
Jul 25 11:26:12 bitrix systemd[1]: Failed to start MySQL Server.
— Subject: Unit mysqld.service has failed
— Defined-By: systemd
— Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Подскажите, куда дальше копать?

юрий белов, попробуйте остановить nginx, httpd и запустить: mysql, httpd, nginx.
Либо у Вас памяти нехватает на запуск, либо

Источник

Adblock
detector

During our work in support, we see this again and again: “I try to connect to MySQL and am getting a 1045 error”, and most times it comes accompanied with “…but I am sure my user and password are OK”.  So we decided it was worth showing other reasons this error may occur.

MySQL 1045 error Access Denied triggers in the following cases:

1) Connecting to wrong host:

If not specifying the host to connect (with -h flag), MySQL client will try to connect to the localhost instance while you may be trying to connect to another host/port instance.

Fix: Double check if you are trying to connect to localhost, or be sure to specify host and port if it’s not localhost:

2) User does not exist:

Fix: Double check if the user exists:

If the user does not exist, create a new user:

3) User exists but client host does not have permission to connect:

Fix: You can check to see which host user/host MySQL allows connections with the following query:

If you need to check from which IP the client is connecting, you can use the following Linux commands for server IP:

or for public IP:

You can then create a user with correct Host (client IP), or with ‘%’ (wildcard) to match any possible IP:

4) Password is wrong, or the user forgot his password:

Fix: Check and/or reset password:

You cannot read user passwords in plain text from MySQL as the password hash is used for authentication, but you can compare hash strings with “PASSWORD” function:

We can see that PASSWORD(‘forgotten’) hash does not match the authentication_string column, which means password string=’forgotten’ is not the correct password to log in. Also, in case the user has multiple hosts (with different password), he may be trying to connect using the password for the wrong host.

In case you need to override the password you can execute the following query:

5) Special characters in the password being converted by Bash:

Fix: Prevent bash from interpreting special characters by wrapping password in single quotes:

6) SSL is required but the client is not using it:

Fix: Adding –ssl-mode flag (–ssl flag is deprecated but can be used too)

You can read more in-depth on how to configure SSL in MySQL in the blog post about “Setting up MySQL SSL and Secure Connections” and “SSL in 5.6 and 5.7“.

7) PAM backend not working:

Fix: Double check user/password is correct for the user to authenticate with the PAM currently being used.

In my example, I am using Linux shadow files for authentication. In order to check if the user exists:

To reset password:

Finally, if you are genuinely locked out and need to circumvent the authentication mechanisms in order to regain access to the database, here are a few simple steps to do so:

1. Stop the instance
2. Edit my.cnf and add skip-grant-tables under [mysqld] (this will allow access to MySQL without prompting for a password). On MySQL 8.0, skip-networking is automatically enabled (only allows access to MySQL from localhost), but for previous MySQL versions it’s suggested to also add –skip-networking under [mysqld]
3. Start the instance
4. Access with root user (mysql -uroot -hlocalhost); 

5. Issue the necessary GRANT/CREATE USER/SET PASSWORD to correct the issue (likely setting a known root password will be the right thing: SET PASSWORD FOR ‘root’@’localhost’ = ‘S0vrySekr3t’). Using grant-skip-tables won’t read grants into memory and GRANT/CREATE/SET PASSWORD statements won’t work straight away. First, you need to execute “FLUSH PRIVILEGES;” before executing any GRANT/CREATE/SET PASSWORD statement, or you can modify mysql.users table with a query which modifies the password for User and Host like “UPDATE mysql.user SET authentication_string=PASSWORD(‘newpwd’) WHERE User=’root’ and Host=’localhost’;”

6. Stop the instance
7. Edit my.cnf and remove skip-grant-tables and skip-networking
8. Start MySQL again
9. You should be able to login with root from the localhost and do any other necessary corrective operations with root user.
   

Learn more about Percona Server for MySQL

Восстановление работоспособности после падения mysql, разберем специфику восстановления низкоуровневых подсистем InnoDB.

Почему падает бд

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

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

Убедимся что проблема действительно есть

df -h

[root@centos-75-64-minimal ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md2 437G 98G 317G 100% /
devtmpfs 32G 0 32G 0% /dev
tmpfs 32G 0 32G 0% /dev/shm
tmpfs 32G 1.2M 32G 1% /run
tmpfs 32G 0 32G 0% /sys/fs/cgroup
/dev/md1 488M 143M 320M 31% /boot
tmpfs 6.3G 0 6.3G 0% /run/user/600
tmpfs 6.3G 0 6.3G 0% /run/user/0

Место на диске кончилось, и БД не в состояние больше писать, отчистим место и попробуем перезапустить mysql, если же mysql не запускается то первым делом останавливаем mysql, в зависимости от ОС команда моет отличаться.

service mysqld restart

service mysql restart

/etc/init.d/mysqld restart

В нашем случае база не запустилась, по этому полностью останавливаем mysql

service mysqld stop

service mysql stop

/etc/init.d/mysqld stop

И убеждаемся что демон полностью остановлен и все процессы тоже, должен остаться только один процесс

[root@centos-75-64-minimal ~]# ps aux | grep mysql 
root     1903   0.0 0.0 112708 972 pts/3 S+ 19:46 0:00 grep --color=auto mysq 

Если mysql все еще есть, то убиваем процесс

 kill -9 "номер процесса" 

Запускаем заново mysql

service mysqld start

service mysql start

/etc/init.d/mysqld start

Демон не запускается

service mysql start 
Redirecting to /bin/systemctl start mysql.service 
Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.

В какие логи смотреть

Смотрим логи

journalctl -xe

PageUp и PageDown

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

Сам демон mysql может сообщить полезную информацию

service mysqld status

service mysql status

/etc/init.d/mysqld status

Redirecting to /bin/systemctl status mysql.service 
● mysqld.service - MySQL Server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Mon 2019-02-18 18:20:59 MSK; 18min ago
Docs: man:mysqld(8)
http://dev.mysql.com/doc/refman/en/using-systemd.html
Process: 25723 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQL D_OPTS (code=exited, status=1/FAILURE)
Process: 25699 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)
Main PID: 14443 (code=killed, signal=KILL)
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Failed to start MySQL Server.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Unit mysqld.service entered failed state.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service failed.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service holdoff time over, scheduling ...rt.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: start request repeated too quickly for mysqld...ice
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Failed to start MySQL Server.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Unit mysqld.service entered failed state.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service failed.
Hint: Some lines were ellipsized, use -l to show in full.
[root@centos-75-64-minimal mysql]# service mysql status
Redirecting to /bin/systemctl status mysql.service
● mysqld.service - MySQL Server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Mon 2019-02-18 18:20:59 MSK; 18min ago
Docs: man:mysqld(8)
http://dev.mysql.com/doc/refman/en/using-systemd.html
Process: 25723 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS (code=exited, status=1/FAILURE)
Process: 25699 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)
Main PID: 14443 (code=killed, signal=KILL)

Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Failed to start MySQL Server.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Unit mysqld.service entered failed state.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service failed.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service holdoff time over, scheduling restart.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: start request repeated too quickly for mysqld.service
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Failed to start MySQL Server.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Unit mysqld.service entered failed state.
Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service failed.

Как мы видим в данном случае информативности оно не добавило, просто mysql не желает стартовать.

Можно более подробно посмотреть в error логе mysql

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

Нужно убедиться что логирование включено, для этого в my.cnf должна быть директива

log-error = путь до файла лога 

Так же она может быть написана в другом конфиге подключаемом через include, для быстрого поиска воспользоватсья данной командой:

find  /etc/mysql/ -type f -exec grep -l "log-error" {} ; 

2019-02-12T17:10:41.002325Z 0 [Warning] Could not increase number of max_open_files to more than 5000 (request: 80192)
2019-02-12T17:10:41.002565Z 0 [Warning] Changed limits: table_open_cache: 2392 (requested 18432)
2019-02-12T17:10:41.147060Z 0 [Warning] 'NO_AUTO_CREATE_USER' sql mode was not set.
2019-02-12T17:10:41.148006Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.23-25) starting as process 3314 ..
2019-02-12T17:10:41.153630Z 0 [Warning] InnoDB: Using innodb_file_format is deprecated and the parameter may be removed in future releases. See http://dev.mysql.com/doc/refman/5.7/en/innodb-file-format.html
2019-02-12T17:10:41.153694Z 0 [Note] InnoDB: PUNCH HOLE support available
2019-02-12T17:10:41.153702Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-02-12T17:10:41.153705Z 0 [Note] InnoDB: Uses event mutexes
2019-02-12T17:10:41.153708Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-02-12T17:10:41.153711Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.7
2019-02-12T17:10:41.153715Z 0 [Note] InnoDB: Using Linux native AIO
2019-02-12T17:10:41.153902Z 0 [Note] InnoDB: Number of pools: 1
2019-02-12T17:10:41.153973Z 0 [Note] InnoDB: Using CPU crc32 instructions
2019-02-12T17:10:41.174468Z 0 [Note] InnoDB: Initializing buffer pool, total size = 18G, instances = 8, chunk size = 128M
2019-02-12T17:10:41.371813Z 0 [Note] InnoDB: Completed initialization of buffer pool
2019-02-12T17:10:41.401599Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2019-02-12T17:10:41.414873Z 0 [Note] InnoDB: Recovering partial pages from the parallel doublewrite buffer at /var/lib/mysql/xb_doublewrite
2019-02-12T17:10:41.425080Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2019-02-12T17:10:41.444212Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 21193390186
2019-02-12T17:10:41.444235Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 21193394424
2019-02-12T17:10:41.444432Z 0 [Note] InnoDB: Database was not shutdown normally!
2019-02-12T17:10:41.444436Z 0 [Note] InnoDB: Starting crash recovery.
2019-02-12T17:10:41.546953Z 0 [Note] InnoDB: Created parallel doublewrite buffer at /var/lib/mysql/xb_doublewrite, size 31457280 bytes
2019-02-12T17:10:41.576387Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=3] log sequence number 108677477433 is in the future! Current system log sequence number 21193394506.
2019-02-12T17:10:41.576432Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/
forcing-innodb-recovery.html for information about forcing recovery.
2019-02-12T17:10:41.576647Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=2] log sequence number 132140291279 is in the future! Current system log sequence number 21193394506.
2019-02-12T17:10:41.576670Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/
forcing-innodb-recovery.html for information about forcing recovery.
2019-02-12T17:10:41.576922Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=4] log sequence number 21194400206 is in the future! Current system log sequence number 21193394506.
2019-02-12T17:10:41.576948Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/
forcing-innodb-recovery.html for information about forcing recovery.
2019-02-12T17:10:41.577209Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=11] log sequence number 132140749179 is in the future! Current system log sequence number 21193394506.
2019-02-12T17:10:41.577226Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/
forcing-innodb-recovery.html for information about forcing recovery.
2019-02-12T17:10:41.577858Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=6] log sequence number 132140702919 is in the future! Current system log sequence number 21193394506.
2019-02-12T17:10:41.577877Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/
forcing-innodb-recovery.html for information about forcing recovery.
2019-02-12T17:10:41.578094Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=330] log sequence number 132140702919 is in the future! Current system log sequence number 21193394506.
2019-02-12T17:10:41.578112Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/
forcing-innodb-recovery.html for information about forcing recovery.
2019-02-12T17:10:41.578328Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=790] log sequence number 21193512754 is in the future! Current system log sequence number 21193394506.
2019-02-12T17:10:41.578344Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/
forcing-innodb-recovery.html for information about forcing recovery.
2019-02-12T17:10:41.578555Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=45] log sequence number 21194412806 is in the future! Current system log sequence number 21193394506.

Что происходит

Была повреждена одна или более таблиц бд, особенно это относится к InnoDB

Как правило если исправить эту ошибку то работоспособность БД восстановится.

В противном случае нам прийдётся делать дамп всех БД и переустанавливать mysql

Востанавливаем базы данных

Когда innodb вообще не запускается, нам прийдутся зайти в защитный режим, для этого добавим в /etc/my.cnf

innodb_force_recovery = 1

Место положение файла зависит от ОС

И попробуем заново запустить mysql.

Если старт не происходит, увеличиваем цифру с шагом в единицу и пытаемся запустить бд.

innodb_force_recovery = 2

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

В моем случае старт пошёл на =2, но одна из бд падала при обращение к ней и заработала только на 6.

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

Делаем дамп всех БД, обычно рекомендуют сделать mysqldump -u root -p —all-databases —skip-lock-tables > alldb.sql с вариациями, но нам нужно понять кто не корректно и где дамптися так что я делаю по другому.

В начале посмотрим можем ли мы прочитать названия БД

mysql -uroot -p******** -e'show databases;'

[root@centos-75-64-minimal mysql]# mysql -uroot -p******s -e’show databases;'
±--------±
| Database |
±--------±
| information_schema |
| dbami-com |
| dbhikvisionpro |
| performance_schema |
| sitemanager |
| sys |
±--------±

У нас есть список БД и мы можем сделать дамп каждой по отдельности.

Создадим директорию для бэкапов, я делаю это не в /tmp поскольку может понадобиться перезагрузиться а в зависимости от способа монтирования, она может перетереться при загрузке

 mkdir -p /var/backup/mysql 

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

for i in `mysql -uroot -p******** -e'show databases;' | grep -v information_schema | grep -v performance_schema | grep -v Database`; do mysqldump -uroot -p******** $i > /var/backup/mysql/$i.sql || echo "$i $?";done 

Если дамп прошёл успешно, то можно запускать

mysqlcheck --auto-repair -o --all-databases

Если и он справился удачно то можно попробовать удалить innodb_force_recovery из my.cnf и перезагрузить mysql

Но мы будем разбирать менее оптимистичный сценарий.

[root@centos-75-64-minimal mysql]# for i in `mysql -uroot -e’show databases;' | grep -v information_schema | grep -v performance_schema | grep -v Database`; do mysqldump -uroot -no-create-info $i > /var/backup/mysql/$i.sql || echo «$i $?«;done
mysqldump: Error: 'Lost connection to MySQL server during query' when trying to dump tablespaces
mysqldump: Couldn’t execute 'SHOW VARIABLES LIKE 'ndbinfo_version'': MySQL server has gone away (2006)
dbhikvisionpro 2
mysqldump: Got error: 2002: Can’t connect to local MySQL server through socket '/var/lib/mysqld/mysqld.sock' (111) when trying to connect
sitemanager 2
mysqldump: Got error: 2002: Can’t connect to local MySQL server through socket '/var/lib/mysqld/mysqld.sock' (111) when trying to connect

Как мы видим что-то пошло не так, при обращение к одной из бд произошла ошибка, и она привела к падению всего mysql, дальше дамп был не возможен. В данном случае mysql пришлось снимать kill −9 поскольку другим способом демон не желал ни работать ни корректно останавливаться.

Посмотрим что нам удалось выгрузить:

root@centos-75-64-minimal mysql]# ls -la
total 597616
drwxr-xr-x 2 root root 4096 Feb 18 19:43 .
drwxr-xr-x 3 root root 4096 Feb 18 19:37 ..
-rw-r—r— 1 root root 611926379 Feb 18 19:43 dbami-com.sql
-rw-r—r— 1 root root 1563 Feb 18 19:43 dbhikvisionpro.sql
-rw-r—r— 1 root root 0 Feb 18 19:43 sitemanager.sql

Как мы видим, дамп корректно был завершена только для одной dbami-com.sql (не нулевой размер, dbhikvisionpro, это или часть некорректного дампа, или в нашем случае, ошибка была в первой же таблице по этому дамп содержал только общий заголовок и не имел внутри вообще никакой информации. Все последующие БД не имели размера поскольку sql уже не отвечал.

[root@centos-75-64-minimal mysql]# cat dbhikvisionpro.sql
— MySQL dump 10.13 Distrib 5.7.23–25, for Linux (x86_64)
-
— Host: localhost Database: dbhikvisionpro
— --------------------------
— Server version 5.7.23–25
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
/*!50717 SELECT COUNT(*) INTO @rocksdb_has_p_s_session_variables FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'performance_schema' AND TABLE_NAME = 'session_variables' */;
/*!50717 SET @rocksdb_get_is_supported = IF (@rocksdb_has_p_s_session_variables, 'SELECT COUNT(*) INTO @rocksdb_is_supported FROM performance_schema.session_variables WHERE VARIABLE_NAME='rocksdb_bulk_load'', 'SELECT 0') */;
/*!50717 PREPARE s FROM @rocksdb_get_is_supported */;
/*!50717 EXECUTE s */;
/*!50717 DEALLOCATE PREPARE s */;
/*!50717 SET @rocksdb_enable_bulk_load = IF (@rocksdb_is_supported, 'SET SESSION rocksdb_bulk_load = 1', 'SET @rocksdb_dummy_bulk_load = 0') */;
/*!50717 PREPARE s FROM @rocksdb_enable_bulk_load */;
/*!50717 EXECUTE s */;
/*!50717 DEALLOCATE PREPARE s */;

Проверим догадку, так ли это, зайдем в mysql и попробуем посмотреть список таблиц.

mysql> use dbhikvisionpro
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with
Databases changed~
Mysql>
show tables;
mysql> show tables;
No connection. Trying to reconnect…
ERROR 2002 (HY000): Can’t connect to local MySQL server through socket '/var/lib/mysqld/mysqld.sock' (111)
ERROR:

SQL не могла вернуть даже список таблиц, мало того от этого запроса упала вся БД и не отвечала до полной отчистки памяти, принудительно через

 ps aux | grep mysql 

и

kill -9 ***

Убедившись что mysql полностью остановлен мы заново его запускаем.

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

cd /var/lib/mysql/ваша бд/

Получаем список таблиц

Внимание! Такой способ возможен только при условии что innodb_file_per_table=1

ls *.ibd | grep -v "FTS"| cut -d '.' -f 1

[root@centos-75-64-minimal dbhikvisionpro]# ls *.ibd | grep -v «FTS»| cut -d '.' -f 1
b_abtest
b_admin_notify
b_admin_notify_lang
b_adv_banner_2_country
b_adv_banner_2_day
b_adv_banner_2_group
b_adv_banner_2_page
b_adv_banner_2_site
b_adv_banner_2_stat_adv
b_adv_banner_2_weekday
b_adv_banner
b_adv_contract_2_page
b_adv_contract_2_site
b_adv_contract_2_type
b_adv_contract_2_user
b_adv_contract_2_weekday
b_adv_contract
b_adv_type
b_agent
b_app_password
b_b24connector_buttons
b_bitrixcloud_option
b_blog_category
b_blog_comment
b_blog_group
b_blog
b_blog_image
b_blog_post_category
...

Имея список таблиц сделаем дамп каждой таблицы по отдельности и и будем смотреть что у нас с ними.

Создаем папку для дампа таблиц

mkdir /tmp/dbhikvisionpro

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

for i in `ls *.ibd | grep -v "FTS"| cut -d '.' -f 1`; do mysqldump -uroot dbhikvisionpro $i > /tmp/dbhikvisionpro/$i.sql || echo "$i $?";done 

# for i in `ls *.ibd | grep -v «FTS»| cut -d '.' -f 1`; do mysqldump -uroot dbhikvisionpro $i > /tmp/dbhikvisionpro/$i.sql || echo «$i $?«;done
mysqldump: Error: 'Lost connection to MySQL server during query' when trying to dump tablespaces
mysqldump: Couldn’t execute 'SHOW VARIABLES LIKE 'ndbinfo_version'': MySQL server has gone away (2006)
b_xml_tree_import_1c 2
mysqldump: Got error: 2002: Can’t connect to local MySQL server through socket '/var/lib/mysqld/mysqld.sock' (111) when trying to connect

И видим что при обращение к таблице b_xml_tree_import_1c , код ответа 2, и опять упала бд, все последующие так же не читаются.

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

Делаем исключение битых таблиц grep -v исключает таблицу

for i in `ls *.ibd | grep -v "FTS"| grep -v "b_xml_tree_import_1c" | grep -v "b_session" | cut -d '.' -f 1`; do mysqldump -uroot dbhikvisionpro $i > /tmp/dbhikvisionpro/$i.sql || echo "$i $?";done 

drwxrwxrwt. 18 root 4096 Feb 18 21:36.
-rw-r-r- 1 root 7459 Feb 18 21:35 b_abtest.sql
-rw-r-r- 1 root 3166 Feb 18 21:35 b_admin_notify_lang.sql
-rw-r-r- 1 root 3318 Feb 18 21:35 b_admin_notify.sql
-rw-r-r- 1 root 3301 Feb 18 21:35 b_adv_banner_2_country.sql
-rw-r-r- 1 root 3140 Feb 18 21:35 b_adv_banner_2_day.sql
-rw-r-r- 1 root 3028 Feb 18 21:35 b_adv_banner_2_group.sql
-rw-r-r- 1 root 3163 Feb 18 21:35 b_adv_banner_2_page.sql
-rw-r-r- 1 root 3031 Feb 18 21:35 b_adv_banner_2_site.sql
-rw-r-r- 1 root 3055 Feb 18 21:35 b_adv_banner_2_stat_adv.sql
-rw-r-r- 1 root 3109 Feb 18 21:35 b_adv_banner_2_weekday.sql
-rw-r-r- 1 root 5759 Feb 18 21:35 b_adv_banner.sql
-rw-r-r- 1 root 3183 Feb 18 21:35 b_adv_contract_2_page.sql
-rw-r-r- 1 root 3102 Feb 18 21:35 b_adv_contract_2_site.sql
-rw-r-r- 1 root 3110 Feb 18 21:35 b_adv_contract_2_type.sql
-rw-r-r- 1 root 3160 Feb 18 21:36 b_adv_contract_2_user.sql
-rw-r-r- 1 root 5984 Feb 18 21:36 b_adv_contract_2_weekday.sql
-rw-r-r- 1 root 4099 Feb 18 21:36 b_adv_contract.sql
-rw-r-r- 1 root 3274 Feb 18 21:36 b_adv_type.sql
-rw-r-r- 1 root 11749 Feb 18 21:36 b_agent.sql
-rw-r-r- 1 root 3515 Feb 18 21:36 b_app_password.sql
-rw-r-r- 1 root 3153 Feb 18 21:36 b_b24connector_buttons.sql
-rw-r-r- 1 root 3424 Feb 18 21:36 b_bitrixcloud_option.sql
-rw-r-r- 1 root 3063 Feb 18 21:36 b_blog_category.sql
-rw-r-r- 1 root 3934 Feb 18 21:36 b_blog_comment.sql
-rw-r-r- 1 root 3054 Feb 18 21:36 b_blog_group.sql
-rw-r-r- 1 root 3402 Feb 18 21:36 b_blog_image.sql
-rw-r-r- 1 root 3175 Feb 18 21:36 b_blog_post_category.sql
-rw-r-r- 1 root 3200 Feb 18 21:36 b_blog_post_param.sql
-rw-r-r- 1 root 5096 Feb 18 21:36 b_blog_post.sql
-rw-r-r- 1 root 3155 Feb 18 21:36 b_blog_site_path.sql
-rw-r-r- 1 root 3178 Feb 18 21:36 b_blog_socnet_rights.sql
-rw-r-r- 1 root 2987 Feb 18 21:36 b_blog_socnet.sql
-rw-r-r- 1 root 4513 Feb 18 21:36 b_blog.sql
-rw-r-r- 1 root 3343 Feb 18 21:36 b_blog_trackback.sql
-rw-r-r- 1 root 3054 Feb 18 21:36 b_blog_user2blog.sql
……

Теперь у нас есть все таблицы и мы можем смотреть каждую по отдельности. Убедившись что все с ними хорошо, поэтому нам больше не нужны таблицы по отдельности, нам нужен один файл.

for i in `ls *.ibd | grep -v "FTS"| grep -v "b_xml_tree_import_1c" | grep -v "b_session" | cut -d '.' -f 1`; do mysqldump -uroot dbhikvisionpro $i >> /tmp/dbhikvisionpro/dbhikvisiononpro.sql || echo "$i $?";done 

В результате получаем полноценный дамб за исключением двух таблиц. Как вариант в mysqldump есть —ignore-table=DATABASE.table1 но там нужно писать баш скрипт и многие жалуются что он не работает корректно, в моем же случае цикл у меня уже был сделал и не принципиально как он будет делаться.

Все что нам остаётся удалить проблемные БД, если не получается их удалить то проверяем диск на вероятные сбои как физические так и логические, если же все хорошо но база не удаляется, остаётся только полностью переустановить mysql.

Заново инициализируем mysql

Поскольку все БД мы уже получили, нам нужно восстановить работоспособность mysql, DROP TABLES не помогает, в связи с этим, мы удалим физически все БД и инициализируем чистый mysql

Остановим mysql

systemctl stop mysqld

Удалим полностью папку mysql

rm -rf /var/lib/mysqld

Инициализируем новую БД

mysqld --initialize-insecure --basedir=/usr --datadir=/var/lib/mysql

Создаем сокет

mkfifo /var/lib/mysqld/mysqld.sock

Права

chown -R mysql /var/lib/mysqld/mysqld.sock

Нам нужно установить root пароль, устанавливаем environment

systemctl set-environment MYSQLD_OPTS="--skip-grant-tables"

Заходим в mysql без пароля

systemctl start mysqld	mysql -u root

Обновляем пароль root

mysql> UPDATE mysql.user SET authentication_string = PASSWORD('MyNewPassword')
-> WHERE User = 'root' AND Host = 'localhost';
mysql> FLUSH PRIVILEGES;
mysql> quit

новый вариант, просто делаем и тот и тот

mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY 'MyNewPass';

Останавливаем sql и возвращаемся в нормальный режим

systemctl stop mysqld
systemctl unset-environment MYSQLD_OPTS
systemctl start mysqld

Проверяем

mysql -u root -p