宝塔面板Mysql无法启动的解决方法汇总

常见问题:
  1、Mysql安装好后或迁移文件后无法启动
  2、Mysql异常关闭后无法启动
  3、Mysql停止后无法启动

 

一、Mysql安装好后或迁移文件后无法启动
  在Mysql刚刚安装好或者迁移文件后无法启动我们一般先检查Mysql的数据目录所有者是否mysql用户。
       例如我们宝塔环境是:
            Mysql数据目录: /www/server/data
            Mysql程序目录:/www/server/mysql
            Mysql主配置文件:/etc/my.cnf

 

       首先检查硬盘分区使用率是否已经满了
       执行下面的命令查看分区容量使用率
df -h

执行下面的命令查看分区inode使用率

df -i
使用ll命令查看目录详细信息
    [root@test server]# ll /www/server/
    total 24
    drwxr-x---   6 root     root     4096 Oct 30 17:51 data
    drwx--x--x  14 root     root      182 Oct 16 18:01 docker
    drwxrwxr-x  12 root     root      326 Oct 24 18:06 mysql
    drw-------. 14 root     root     4096 Oct 24 18:06 panel
可以看到data目录所有者是root,这时候启动mysql报错如下
    [root@test server]# /etc/init.d/mysqld start
    Starting MySQL. ERROR! The server quit without updating PID file (/www/server/data/test.com.pid).
我们先修改该目录的所有者为mysql
chown -R mysql.mysql data

启动数据库

/etc/init.d/mysqld start
可以看到已经启动成功了
    [root@test server]# /etc/init.d/mysqld start
    Starting MySQL... SUCCESS!
还不行检查你的selinux状态
如果返回值不值disable
运行命令暂时停止selinux
setenforce 0
再尝试启动

 

二、Mysql异常关闭后无法启动
  Mysql异常关闭是我们经常遇到的情况,重启服务器时没有预先关闭mysql,服务器断电,使用kill命令杀死mysql进程等都属于异常关闭,异常关闭往往会带来一些不可预料的后果。
  一般情况下异常关闭会导致二进制日志文件损坏
  执行
    rm -f /www/server/data/ib_logfile0
    rm -f /www/server/data/ib_logfile1
删除日志后再尝试启动

 

  遇到错误 Another MySQL daemon already running with the same unix socket 
  可以尝试删除sock文件后再启动
    rm -f /tmp/mysql.sock*
    rm -f /tmp/mysqlx.sock*
遇到错误 [ERROR] InnoDB: Cannot allocate memory for the buffer pool 时
表示当前mysql启动需要的内存不够,我们需要调整内存
    innodb_buffer_pool_size
    key_buffer_size

 

三、Mysql停止后无法启动

 

  Mysql正常停止后无法启动的原因
  1.显示停止成功实际停止失败,有残留进程,我们可以用ps来检查
ps -ef|grep mysql
2.磁盘空间满了导致mysql无法启动

 

  3.有时手动删除了binlog日志重启mysql也会导致无法启动,在错误日志里可以找到
          File ‘./mysql-bin.000001’ not found 字样
  解决方法:
    注释主配置文件的配置
           找到
log-bin=mysql-bin

改为

#log-bin=mysql-bin

或者清空

mysql-bin.index

附加一些使用案例:

2020-04-17 13:44:33 32265 [Warning] Insecure configuration for --pid-file: Location '/www/server/data' in the path is accessible to all OS users. Consider choosing a different directory.
2020-04-17 13:44:33 32265 [ERROR] /www/server/mysql/bin/mysqld: Table './mysql/db' is marked as crashed and should be repaired
2020-04-17 13:44:33 32265 [ERROR] Fatal error: Can't open and lock privilege tables: Table './mysql/db' is marked as crashed and should be repaired

mysql5.6没办法重启

做好磁盘快照后,服务器命令行执行以下命令试试

myisamchk -e  -c -r ../mysql/dbv

分别执行以下命令检查一下mysql状态 截个图出来#查看Mysql版本

mysql -V

#检查mysql相关配置

grep -E -i 'engine|data|mode' /etc/my.cnf

#检查磁盘状态

df -h

#检查默认3306端口状态

lsof -i :3306

#检查数据库目录权限

ls -al /www/server

 

服务器断电或者重启后造成Innodb存储引擎损坏解决方案

服务器断电|重启后造成InnoDB存储引擎损坏导致无法正常启动MySQL的解决方案
建议将本文通读一遍后再根据解决方案进行处理。
出现的原因:
正常情况下,数据库在做查询语句Select * From Table_Name时候,会正常返回完整的数据给用户,当在做查询的时候,或者InnoDB存储引擎后台操作意外退出或者中断,会导致InnoDB向前回滚恢复数据的时候失败。

 

对此错误,解决方案如下:
1、首先确定下错误是否和上述的错误信息是否一致,然后关闭Web服务(Apache或者Nginx)。
2、把MySQL的数据存储目录做个备份,备份是为了以防万一,如果有快照,尽量做个磁盘快照。
面板中默认的数据库存储路径在
/www/server/data
备份命令:

\cp -rp /www/server/data /www/backup/data_2022

3、到MySQL的配置文件中添加
面板的MySQL配置文件默认是  /etc/my.cnf

innodb_force_recovery 

设置完成后重启数据库

innodb_force_recovery默认是非0 的整数,一共有1--6  6个参数值,下面是参数解读:

1 (srv_force_ignore_corrupt)

启动MySQL服务,即使它检测到一个损坏的页面。试图使SELECT * FROM tbl_name跳过损坏的索引记录和页面,这有助于转储表。

2 (srv_force_no_background)

防止主线程和任何清除线程的运行。如果在清除操作中会发生意外退出,这个恢复值可以防止它退出。

3 (srv_force_no_trx_undo)

在崩溃恢复后不运行事务回滚。

4 (srv_force_no_ibuf_merge)

防止插入缓冲区的合并操作。如果它们会导致崩溃,则不做这些操作。不计算表的统计数据。这个值会永久地破坏数据文件。在使用这个值之后,要准备放弃并重新创建所有的二级索引。将InnoDB设置为只读。

5 (srv_force_no_undo_log_scan)

在启动数据库时不查看撤销日志。InnoDB甚至将不完整的事务视为已提交。这个值会永久地破坏数据文件。将InnoDB设置为只读。

6 (srv_force_no_log_redo)

不做与恢复有关的重做日志滚动。这个值会永久地破坏数据文件。使数据库页面处于过时的状态,这反过来又可能给B树和其他数据库结构带来更多的损坏。将InnoDB设置为只读。
你可以从表中SELECT来转储它们。如果innodb_force_recovery的值为3或更小,你可以DROP或CREATE表。当innodb_force_recovery值大于3时,也支持DROP TABLE。如果innodb_force_recovery的值大于4,则不允许DROP TABLE。

如果你知道一个给定的表在回滚时导致意外退出,你可以放弃它。如果你遇到由失败的大规模导入或ALTER TABLE引起的失控回滚,你可以杀死mysqld进程并将innodb_force_recovery设置为3以使数据库在没有回滚的情况下恢复,然后DROP引起失控回滚的表。

如果表数据中的损坏使你不能转储整个表的内容,带有ORDER BY primary_key DESC子句的查询可能能够转储表中损坏部分之后的部分。

如果需要一个高的innodb_force_recovery值来启动InnoDB,可能会有损坏的数据结构,导致复杂的查询(包含WHERE、ORDER BY或其他子句的查询)失败。在这种情况下,你可能只能运行基本的SELECT * FROM t查询。

4、上面的6个参数值,后面的包含前面的功能,如参数3,包含了参数1 和参数2 的所有功能,这里的参数总有一个可以将数据库启动,注意:若有无法启动的情况,请将二进制日志清除(没有做备份的请勿执行此命令):

rm -f /www/server/data/ib_*
rm -f /www/server/data/mysql-bin*

然后重启MySQL。
5、重启数据库后,下面进行备份数据库:
一般情况下在面板做计划任务的比较多:
图片[1]-宝塔面板Mysql无法启动的解决方法汇总 - THE FREE SKY-THE FREE SKY
添加好后记得点击执行按钮,数据库如果较大的话,备份可能需要点时间,
也可以在数据库管理界面,点击备份按钮进行备份
002419d04uf94c28lcs494
6、当备份完成后将现在的数据库服务停止,记得备份当数据库名和对应的密码,然后卸载当前的数据库
002658cw73777wj7799494
003000rqlcq07w3b0cjzcd
7、重新安装MySQL后,新建数据库,密码指定之前复制的
003352qddmdngcsppvdgz1
8、等到还原成功后,重启Nginx或者Apache,观察网站是否正常。

结语:服务器之所以被称为服务器,就是其强大的稳定能力和持续服务能力,除非必要,不要重启服务器,*时多做数据的备份,出现问题时不慌!

 

FAQ:
①、为什么要关闭Web服务(Nginx或者Apache)?
答:此时MySQL已经无法正常提供服务,如果一直开着Nginx或者Apache,会导致外部访问一直在请求数据库,生成大量的错误日志,如果磁盘容量小,则会很快出现磁盘空间不足
②、为什么要做快照或者备份?
答:在处理数据的时候,可能会因特殊情况导致无法启动MySQL,如果没有备份,或者快照,会导致现有的“数据”损坏,对数据库造成二次损毁
③、为什么要复制数据库名和对应的密码?
答:节省时间,面板上新建数据库会重新生成一个随机密码,当前如果您的网站中的数据库信息和运行的数据库的信息不一致,也是无法进行连接的,在重新创建数据库的时候直接以之前的数据库名和密码进行创建数据库,不用在到网站配置文件中修改信息,这样启动Web服务后就可以直接使用
④、如果我都尝试了,数据库还是无法启动怎么办?
答:MySQL官方给的解决方案都无法解决当前的问题,建议找专业的数据恢复公司。

© 版权声明
THE END
請多多支持
点赞12
评论 抢沙发

    暂无评论内容