转载自:MySQL提示:The server quit without updating PID file问题的解决办法_变成习惯-优快云博客
今天网站web页面提交内容到数据库,发现出错了,一直提交不了,数找了下原因,发现数据写不进去!第一反应,重启mysql数据库,一直执行中,停止不了也启动不了,直觉告诉我磁盘满了 !
用df命令查了下,果然磁盘满了,因为当时分区采用系统默认,不知道为什么不能自动扩容!以后在处理这个问题!如图所示:
复制代码代码如下:
[root@snsgou ~]# df
文件系统 1K-块 已用 可用 已用% 挂载点
/dev/mapper/vg_snsgou-lv_root
51606140 47734848 1249852 100% /
tmpfs 1953396 88 1953308 1% /dev/shm
/dev/sda1 495844 37062 433182 8% /boot
/dev/mapper/vg_snsgou-lv_home
229694676 191796 217835016 1% /home
[root@snsgou ~]#
删除了些没用的日志后,重新启动数据库还是出错。
复制代码代码如下:
[root@snsgou mysql]# service mysql restart
MySQL server PID file could not be found![失败]
Starting MySQL...The server quit without updating PID file (/usr/local/mysql/data/snsgou.pid).[失败]
Google了下 ,问题可能的原因有多种,具体什么原因最好的办法是先查看下错误日志:
1、可能是/usr/local/mysql/data/mysql.pid文件没有写的权限
解决方法 :给予权限,执行 “chown -R mysql:mysql /var/data” “chmod -R 755 /usr/local/mysql/data” 然后重新启动mysqld!
2、可能进程里已经存在mysql进程
解决方法:用命令“ps -ef|grep mysqld”查看是否有mysqld进程,如果有使用“kill -9 进程号”杀死,然后重新启动mysqld!
3、可能是第二次在机器上安装mysql,有残余数据影响了服务的启动。
解决方法:去mysql的数据目录/data看看,如果存在mysql-bin.index,就赶快把它删除掉吧,它就是罪魁祸首了。本人就是使用第三条方法解决的 !
4、mysql在启动时没有指定配置文件时会使用/etc/my.cnf配置文件,请打开这个文件查看在[mysqld]节下有没有指定数据目录(datadir)。
解决方法:请在[mysqld]下设置这一行:datadir = /usr/local/mysql/data
5、skip-federated字段问题
解决方法:检查一下/etc/my.cnf文件中有没有没被注释掉的skip-federated字段,如果有就立即注释掉吧。
6、错误日志目录不存在
解决方法:使用“chown” “chmod”命令赋予mysql所有者及权限
7、selinux惹的祸,如果是centos系统,默认会开启selinux
解决方法:关闭它,打开/etc/selinux/config,把SELINUX=enforcing改为SELINUX=disabled后存盘退出重启机器试试。
8、用的root用户安装,解决办法是在/etc/my.cnf [mysqld] 中添加参数user=root
9、在/var/lib/mysql/ 下找到mysql-bin.index文件, 删除该文件
最后PS:查看MySQL运行日志
tail -f /alidata/server/mysql/data/iZ25so808sgZ.err
10、查看MySQL报错日志
从日志内容来看,MySQL 在服务器磁盘空间占满mysql运行异常,表空间损坏,导致重启之后无法正常恢复,线程在数据页中读取不到需要的 page 和数据。
需要做特殊操作,让 MySQL 跳过恢复,启动 MySQL,然后把数据导出来,再重建数据库导入。
MySQL 有个一个特性:Forcing InnoDB Recovery,启用这个特性需要设置 innodb_force_recovery 大于 0。
innodb_force_recovery 可以设置为 1-6,大的值包含前面所有小于它的值的影响。
018-07-15T04:40:13.995234Z 0 [Note] InnoDB: Uncompressed page, stored checksum in field1 643411285, calculated checksums for field1: crc32 2478637551/3971325484, innodb 1335711502, none 3735928559, stored checksum in field2 0, calculated checksums for field2: crc32 2478637551/3971325484, innodb 713899775, none 3735928559, page LSN 45 984470675, low 4 bytes of LSN at page end 0, page number (if stored to page already) 2, space id (if created with >= MySQL-4.1.1 and stored already) 1386836
InnoDB: Page may be an 'inode' page
2018-07-15T04:40:13.995255Z 0 [Note] InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try to fix the corruption by dumping, dropping, and reimporting the corrupt table. You can use CHECK TABLE to scan your table for corruption. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery.
2018-07-15T04:40:13.995265Z 0 [ERROR] [FATAL] InnoDB: Aborting because of a corrupt database page in the system tablespace. Or, there was a failure in tagging the tablespace as corrupt.
2018-07-15 12:40:13 0x7fe733636700 InnoDB: Assertion failure in thread 140630976325376 in file ut0ut.cc line 916
解决:
vi /etc/my.cnf 在 [mysqld]中新增
[mysqld]
innodb_force_recovery = 6
然后再重新启动mysql,恢复正常。
恢复启动后,你会发现所有表都是只读状态,无法增删改,因为设置为6时,是为恢复数据时使用,在启动正常后需设置为0,然后再重启mysql服务,就可恢复正常增删改。
修复完成后,会发现有些表增删改查时都是抛出以下异常:
[Err] 2013 - Lost connection to MySQL server during query
经过日志分析,发现是之前的表数据文件损坏,mysql中check table 发现表有损坏,但表是innodb类型不能修复。
Innodb 自检过程中checksum与退出时不一致便会去recover;
2018-07-23T06:11:38.767992Z 135 [ERROR] InnoDB: Database page corruption on disk or a failed file read of page [page id: space=1386836, page number=2]. You may have to recover from a backup.
解决方法:
将数据库配置中my.cnf 添加以下配置
innodb_force_recovery=1
然后重启mysql,然后再查询该表是否可以正常查询,然后将该表导出成mysql文件。
然后删除该表。再将my.cng中的innodb_force_recovery=1 删除掉,再重启mysql服务。
然后再将上一步骤导出的mysql文件脚本导入到数据库。
转载自