【问题标题】:How to start MySQL after failure?MySQL失败后如何启动?
【发布时间】:2022-01-26 15:24:29
【问题描述】:

重新启动服务器后,我无法再启动 mysql。

我遵循了这里发布的几个解决方案:

我运行以下命令来启动服务:

mysql
>> ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
sudo service mysql start
>> Job for mysql.service failed because the control process exited with error code.
See "systemctl status mysql.service" and "journalctl -xe" for details.
systemctl status mysql.service
>> mysql.service - MySQL Community Server
     Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Wed 2022-01-26 15:18:33 UTC; 47s ago
    Process: 2612 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=1/FAILURE)
 journalctl -xe
>> Startup of the manager took 379405 microseconds.
Jan 26 14:33:24 sumentserver polkit-agent-helper-1[2223]: pam_unix(polkit-1:auth): authentication failure; logname= uid=1001 euid=0 tty= >
-- Reboot --
Jan 26 14:44:33 sumentserver systemd[1685]: Reached target Paths.
-- Subject: A start job for unit UNIT has finished successfully
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- A start job for unit UNIT has finished successfully.

服务器有 Ubuntu 20.4

关于我能做什么的任何提示?

【问题讨论】:

  • 它没有提供关于失败原因的足够信息。通常正在生成一个日志文件(/var/log/mysql/...),这是否不能提供有关失败原因的线索?
  • 什么版本的 MySQL?你最近升级了吗?您的操作系统是否带有不同的 MySQL 副本?

标签: mysql authentication


【解决方案1】:

我今天遇到了同样的问题,问题的根源可能不同,但是仔细阅读/var/log/mysql/error.log它应该指向错误。

我删除了一张不需要.MYD.MYI 文件的表。这是一个错误,我应该删除表,但我的服务器的内存使用率为 100%。

我所做的是阅读错误:

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

同时保持两个终端打开, 第一次运行

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

在第一个终端上运行,然后在第二个终端上运行

sudo systemctl stop mysql.service   ---to shut it down
sudo systemctl start mysql.service  ---to try and start up and see the reason why it is not starting.

对我来说是:

2022-01-26T16:30:36.213788Z 0 [Note] InnoDB: Database was not shutdown normally!
2022-01-26T16:30:36.213802Z 0 [Note] InnoDB: Starting crash recovery.
2022-01-26T16:30:36.213830Z 0 [ERROR] InnoDB: Tablespace 605 was not found at ./contratti/ip_log2_bak.ibd.
2022-01-26T16:30:36.213840Z 0 [ERROR] InnoDB: Set innodb_force_recovery=1 to ignore this and to permanently lose all changes to the tablespace.
2022-01-26T16:30:36.644359Z 0 [ERROR] InnoDB: Cannot continue operation.
2022-01-26T16:30:38.045091Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2022-01-26T16:30:38.062994Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.34-log) starting as process 2843 ...
2022-01-26T16:30:38.416074Z 0 [Note] InnoDB: PUNCH HOLE support available

我可以通过添加/etc/mysql/mysql.conf.d/mysqld.cnf来修复

innodb_force_recovery = 2

来自MySQL docs

如果您能够使用 innodb_force_recovery 转储您的表 值3以下,那么你比较安全,只有一些数据 损坏的单个页面丢失。

在此更改之后,我停止并重新启动 MySQL,它运行良好。

【讨论】:

  • 这是一个很好的提示。就我而言,它导致我: 2022-01-26T15:10:01.855905Z 0 [ERROR] [MY-000077] [Server] /usr/sbin/mysqld: Error while setting value 'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER, NO_ENGINE_SUBS> 配置已修复。非常感谢!这节省了一天!
  • ip_log2 是你的一张桌子吗?
  • @RickJames 是的,是的。这是来自另一台服务器的single table replicated 的表。 ip_log2_bak 是一个带有 MyISAM 引擎的旧数据的表。我执行了以下命令。将ip_log2_bak 重命名为ip_log2_bak_old。使用 InnoDB 引擎创建另一个 ip_log2_bak 并使用 insert into ip_log2_bak (select * from ip_log2_bak_old) 。由于物理内存,这卡住了,所以我从 var/lib/mysql/database/ip_log2_bak.MYD MYI 中删除了ip_log2_bak 文件。愚蠢的错误
【解决方案2】:

根据@Ergest Basha 的调试评论,在检查日志后,它看起来像是配置问题:

2022-01-26T15:10:01.855905Z 0 [错误] [MY-000077] [服务器] /usr/sbin/mysqld: 设置值时出错'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBS>

回滚到默认值

【讨论】:

猜你喜欢
  • 2013-11-30
  • 1970-01-01
  • 1970-01-01
  • 2018-10-05
  • 1970-01-01
  • 2021-05-31
  • 1970-01-01
  • 2012-09-16
  • 1970-01-01
相关资源
最近更新 更多