Как сбросить пароль root в MySQL на Linux: пошаговая инструкция

root в Linux и root в MySQL — разные учётные записи

Администратор ОС может управлять процессом, файлами и запуском службы. Учётная запись MySQL получает права внутри СУБД. Связь между ними зависит от способа аутентификации, а не от совпадения имени.

В MySQL учётная запись определяется парой 'User'@'Host'. Например, 'root'@'localhost' и 'root'@'другое-имя' — разные записи. Не меняйте все строки с User=root одним широким действием. Правила именования приведены в руководстве MySQL.

Выберите способ восстановления до остановки MySQL

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

Шаг 1. Определите продукт, службу и служебные пути

Имя mysql в командной строке ещё не доказывает, что установлен Oracle MySQL: это может быть совместимый клиент или MariaDB. Получите версию клиента, путь программы и список служб:

mysql --version
command -v mysql
command -v mysqld
systemctl list-units --type=service --all | grep -Ei 'mysql|mariadb'
ps -eo pid,ppid,user,args | grep -E '[m]ysqld|[m]ariadbd'

После определения фактического unit посмотрите его запуск. Имя mysql.service ниже условно: в другой поставке оно может быть mysqld.service или шаблонным экземпляром.

unit='mysql.service'
systemctl cat "$unit"
systemctl show "$unit" -p User -p Group -p ExecStart -p EnvironmentFiles
systemctl status "$unit" --no-pager

Зафиксируйте бинарный файл, конфигурацию, пользователя службы, datadir, сокет и журналы. При нескольких экземплярах каждый пункт должен относиться к одному серверу. Не угадывайте datadir по первой найденной папке. Отличия systemd-пакетов описаны в документации производителя.

Шаг 2. Проверьте существующий вход через Unix-сокет

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

sudo mysql --protocol=SOCKET

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

SELECT VERSION(), @@hostname, @@port, @@socket, @@datadir;
SELECT USER(), CURRENT_USER();
SELECT User, Host, plugin, account_locked
FROM mysql.user
WHERE User = 'root';

USER() отражает заявленный контекст соединения, CURRENT_USER() — запись, определившую доступ. Эти сведения помогают не изменить не того пользователя. Не выводите authentication_string в общую заявку: для этой задачи парольные хеши не нужны.

Если root уже работает через auth_socket, вопрос «какой у него пароль» может быть поставлен неверно. Не переводите его на парольный вход только ради привычного вида команды. MySQL описывает socket-аутентификацию отдельно.

Шаг 3. Штатно измените пароль нужной парольной записи

При действующем административном входе и подтверждённом парольном плагине используйте ALTER USER. Укажите точную пару User/Host. Секрет в примере — обозначение для замены, не рекомендуемый рабочий пароль:

ALTER USER 'root'@'localhost'
  IDENTIFIED BY '<НОВЫЙ_УНИКАЛЬНЫЙ_ПАРОЛЬ>';

Для обычного ALTER USER перезапуск сервиса и FLUSH PRIVILEGES не требуются. Сохраните действующий административный сеанс до проверки нового подключения. Если запись использует внешний или socket-плагин, сначала определите цель изменения; команда для парольной записи не является универсальной миграцией способа входа.

Перед вводом секрета проверьте историю клиента, терминальную запись сессии и журналы. Не передавайте пароль как -pПароль или аргумент shell-скрипта. Полезны синтаксис ALTER USER и рекомендации по защите паролей.

Если входа нет: подготовьте окно, копии и границы доступа

• Согласуйте простой. Какие сайты, обмены и задания используют экземпляр; кто проверит их после запуска.
• Проверьте восстановление данных. Наличие файлов копии без понятного способа возврата не равно готовому плану.
• Сохраните настройки. Исходные конфигурационные файлы, unit/drop-in, владельцы, права и параметры запуска.
• Уточните топологию. Репликация, Group Replication, InnoDB Cluster, оркестратор и резервирование требуют отдельного плана.
• Ограничьте локальный доступ. Даже без TCP доступ к Unix-сокету могут иметь локальные процессы.
• Подготовьте аварийную консоль. Работа не должна зависеть от единственного приложения, использующего эту БД.

Копирование работающего datadir обычным cp не создаёт гарантированно согласованную резервную копию InnoDB. Используйте подходящий механизм резервирования; холодную файловую копию рассматривают после корректной остановки с учётом внешних tablespace, ключей и конфигурации.

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

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

unit='mysql.service'
sudo systemctl stop "$unit"
systemctl is-active "$unit"
pgrep -a mysqld
sudo ss -ltnp
sudo ss -lxnp

Для systemctl is-active ожидается inactive, а ненулевой код при остановленном сервисе сам по себе не является ошибкой восстановления. Статус failed требует разбора. pgrep может показать другой экземпляр: сопоставьте PID и аргументы, не завершайте все процессы по имени.

Если процесс продолжает работать, выясните роль supervisor, контейнера или другого unit. Не используйте kill -9 как обычный шаг перед сбросом. Принудительное завершение процесса не заменяет согласованную остановку СУБД.

Шаг 5. Подготовьте одноразовый файл без открытого секрета в shell

Вариант init-file сохраняет обычную проверку привилегий и выполняет заранее подготовленный SQL при старте. Файл содержит новый пароль открытым текстом, поэтому ему нужен ограниченный доступ и короткий срок существования.

Ниже — пример для установки, где каталог /var/lib/mysql-files уже предусмотрен и разрешён политиками. Проверьте его назначение, владельца, права и отсутствие публикации. Не меняйте права существующего каталога рекурсивно:

sudo stat -c '%U:%G %a %n' /var/lib/mysql-files
sudo test ! -e /var/lib/mysql-files/reset-root.sql || exit 1
sudo install -o root -g mysql -m 0640 /dev/null /var/lib/mysql-files/reset-root.sql
sudoedit /var/lib/mysql-files/reset-root.sql

В защищённом редакторе сохраните одну строку, подставив новый уникальный секрет и проверенную запись:

ALTER USER 'root'@'localhost' IDENTIFIED BY '<НОВЫЙ_УНИКАЛЬНЫЙ_ПАРОЛЬ>';

Не вводите секрет через echo в командной строке, не оставляйте редакторские backup-файлы в общем каталоге. Серверный пользователь mysql должен читать файл, остальные пользователи — не получать доступ. Если группа или путь в вашей поставке другие, адаптируйте пример. Назначение переменной описано в справочнике init_file.

Шаг 6. Запустите тот же сервер с временными параметрами

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

Подготовьте закрытый временный каталог для сокета и PID. Указанный путь — пример; он должен быть разрешён AppArmor/SELinux и политиками вашей ОС.

sudo test ! -e /run/mysql-recovery || exit 1
sudo install -d -o mysql -g mysql -m 0700 /run/mysql-recovery

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

sudo -u mysql /usr/sbin/mysqld \
  --defaults-file=/etc/mysql/my.cnf \
  --init-file=/var/lib/mysql-files/reset-root.sql \
  --skip-networking \
  --mysqlx=0 \
  --socket=/run/mysql-recovery/mysql.sock \
  --pid-file=/run/mysql-recovery/mysqld.pid

defaults-file указывается первым серверным параметром после имени программы. skip-networking закрывает классический TCP, mysqlx=0 в этом примере отключает X Plugin. Не объявляйте сервер изолированным без фактической проверки слушателей и прав сокета.

Сохраните первый терминал, дождитесь штатной готовности в журнале. Ошибки чтения файла, политик ОС, keyring или занятого datadir сначала разбирают. Запуск под root без передачи серверу пользователя mysql может изменить владельца создаваемых файлов и помешать следующему старту.

Шаг 7. Проверьте результат через конкретный локальный сокет

Во втором терминале подключитесь именно к временному сокету. Для парольного плагина укажите -p без пароля в аргументах:

sudo mysql --protocol=SOCKET \
  --socket=/run/mysql-recovery/mysql.sock \
  -u root -p

Проверьте версию, пути и нужную запись. Нельзя считать успешный запуск процесса доказательством выполнения строки из init-file.

SELECT VERSION(), @@hostname, @@socket, @@datadir;
SELECT USER(), CURRENT_USER();
SELECT User, Host, plugin, account_locked
FROM mysql.user WHERE User = 'root';

После успешного исполнения удалите только подготовленный одноразовый файл, предварительно сверив точный путь. Это удаление рабочего секрета, а не каталога базы:

sudo rm -- /var/lib/mysql-files/reset-root.sql

Не используйте маску и не удаляйте весь mysql-files. Если файл не исполнился, сохраните обезличенную диагностику в закрытом месте; не оставляйте секрет в общих логах. Полная последовательность init-file приведена в официальной инструкции MySQL.

Шаг 8. Завершите временный процесс и верните обычную службу

Пока временный экземпляр работает, из второго терминала запросите штатное завершение с новым паролем:

sudo mysqladmin --protocol=SOCKET \
  --socket=/run/mysql-recovery/mysql.sock \
  -u root -p shutdown

Дождитесь завершения mysqld в первом терминале и подтвердите, что процесс с тем же datadir остановлен. Затем верните исходный unit. Если вы добавляли init-file или аварийные ключи в постоянную конфигурацию, удалите только свои добавления до запуска.

sudo systemctl start "$unit"
systemctl status "$unit" --no-pager
sudo journalctl -u "$unit" --since '-15 min' --no-pager

Проверяйте ошибки и код завершения каждой команды. Временный каталог можно удалить только после завершения процесса и проверки его содержимого; не выполняйте рекурсивное удаление по неподтверждённой переменной. Параметры mysqladmin описаны в руководстве клиента.

Резервный вариант: skip-grant-tables с обязательным возвратом защиты

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

Для уже остановленного отдельного экземпляра можно использовать тот же подтверждённый запуск, заменив init-file на skip-grant-tables. В примере явно закрыты TCP и X Plugin:

sudo -u mysql /usr/sbin/mysqld \
  --defaults-file=/etc/mysql/my.cnf \
  --skip-grant-tables --skip-networking --mysqlx=0 \
  --socket=/run/mysql-recovery/mysql.sock \
  --pid-file=/run/mysql-recovery/mysqld.pid

В другом терминале подключитесь без пароля, обязательно указав этот сокет:

sudo mysql --protocol=SOCKET \
  --socket=/run/mysql-recovery/mysql.sock -u root

Сначала загрузите таблицы привилегий, затем меняйте пароль. Без первого шага ALTER USER в аварийном режиме может быть недоступен:

FLUSH PRIVILEGES;
ALTER USER 'root'@'localhost'
  IDENTIFIED BY '<НОВЫЙ_УНИКАЛЬНЫЙ_ПАРОЛЬ>';

Далее выполните штатное завершение, верните обычную службу и проверьте защиту отдельным соединением. Этот вариант не используется одновременно с init-file. Команду FLUSH PRIVILEGES здесь нельзя превращать в обязательный шаг после каждого обычного ALTER USER.

MySQL 8.4, старые плагины и MariaDB: что не переносить из форумов

Не включайте устаревший плагин только потому, что приложение давно не обновляли. Сначала определите поддерживаемые версии драйвера и СУБД, проверьте соединение на стенде и составьте план обновления. Состояние mysql_native_password в ветке 8.4 указано в официальном описании.

Диагностика: ошибка входа не всегда означает неверный пароль

Читая journalctl и error log, сохраняйте исходное время, сообщение и контекст. В заявку передавайте обезличенные строки, а не init-file с новым паролем. Настройки клиента могут подставлять другой сокет, логин или пароль; сверяйте option files и фактическую команду.

Сайт, Битрикс, обмены: где после ротации потеряется соединение

Ротация административного root не должна влиять на приложение с отдельной правильно настроенной учётной записью. Но на практике встречаются сайты и задания, подключённые прямо под root. До работ найдите эти зависимости и назначьте владельцев проверки.

• Параметры подключения сайта, защищённые конфигурации и переменные окружения.
• Планировщик cron/systemd timers, обмены и сценарии выгрузки.
• Мониторинг и средства резервного копирования.
• Репликационные и административные подключения, если они настроены через эту запись.
• Пулы соединений, долгоживущие PHP-процессы и фоновые обработчики.

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

Приёмка: проверьте доступ и отсутствие аварийных настроек

После обычного запуска снова создайте административное подключение согласованным способом. Для парольной записи используйте -p, для socket-аутентификации — соответствующий контекст ОС. Затем проверьте режим:

SELECT VERSION(), @@hostname, @@socket, @@datadir;
SELECT USER(), CURRENT_USER();
SHOW VARIABLES LIKE 'skip_grant_tables';
SHOW VARIABLES LIKE 'init_file';

• skip_grant_tables = OFF, одноразовый init_file не задан.
• Сервис запущен штатно, сервер использует исходный datadir и нужные параметры.
• Новый пароль проверен отдельным соединением именно для нужной User/Host-записи.
• При парольной схеме вход с неправильным паролем не проходит; socket-схема оценивается по собственному механизму.
• Слушатели и права сокетов соответствуют рабочему проекту, а не случайно открытому аварийному серверу.
• Сайт, обмен, копирование и мониторинг прошли согласованные проверки.
• Файл с секретом удалён, временные настройки и доступы закрыты, секрет сохранён в защищённом хранилище.

Не открывайте 3306 наружу для проверки результата. Подключение к MySQL и выбор транспорта рассматриваются в отдельном разделе руководства.

Если после восстановления стало хуже: возвращайте управляемое состояние

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

1. Сохраните ошибки и время, остановите дальнейшие случайные изменения.
2. Завершите временный экземпляр штатно; не запускайте службу поверх него.
3. Удалите только добавленные вами аварийные параметры, сохраните исходные настройки и владельцев файлов.
4. Верните обычный запуск и проверьте нужный datadir, сервис и доступ.
5. Если данные действительно повреждены, перейдите к отдельному плану восстановления с оценкой допустимых потерь.

Не лечите пароль удалением каталога mysql, повторным --initialize, восстановлением чужой системной схемы или рекурсивным chmod 777. Проблемы ключей шифрования и повреждения InnoDB требуют отдельной диагностики.

Материалы для окна восстановления

Сопровождение Linux, MySQL и размещение сервисов

Частые вопросы и границы инструкции

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