「这是我参与11月更文挑战的第1天，活动详情查看：2021最后一次更文挑战」
起因
最近在进行网站检查的时候突然发现我的一个子网站挂了,提示error establishing a database connection, 如果是网站刚建立那好解决,80%的概率是数据连接参数不正确,或者是数据库端口没有开放
但是我这个网站运行很长一段时间了,之前一直好好的,突然之间就挂了, 而且这个数据库我使用的是docker进行维护,同时,在同一个mysql容器中我放置了好几个网站的数据,其他网站运行却是正常的
而且我通过第三方连接数据库的工具可以正常连接到被挂网站的数据库
通过以上情况可以排除以下原因:
mysql容器没有问题- 数据库端口和连接参数也没问题(已经检查过配置文件,没有被外部篡改过)
- 网站程序正常运行
这种情况下该如何处理呢? 当然是找日志了
第一步:查看主程序日志,没问题
第二步:查看mysql容器日志,发现问题
docker logs --tail=50 mysql
Table './wordpress_wai/wp_options' is marked as crashed and should be repaired when using LOCK TABLES
数据库没有问题,但是表有问题
解决方案
对表进行修复即可：
首先登录mysql选择指定的数据库,然后执行以下命令:
-
执行修复指令
repair table wp_option -
检查表的状态
check table wp_option
修复前最好先备份数据库
mysqldump -uroot -p密码 数据库名 >xxxxx.sql
如果表损坏比较严重,可能无法备份数据库
如果你不知道如何查看mysql日志,那么直接运行备份数据库指令,也能帮你检查数据库是否存在问题
修复完成后无需重启mysql容器, 直接刷新网址即可正常访问
2021年9月1日补充
突然数据库又崩了, 网站同样提示error establishing a database connection
我查看docker日志 报如下错误:
Database page corruption on disk or a failed file read of page [page id: space=0, page number=5]. You may have to recover from a backup
此时mysql容器已经进不去了, 百度了一下说是数据库受损 要在my.cnf配置文件中添加innodb_force_recovery=1
可是我在conf目录下并没有找到my.cnf文件 不知道是被谁给删了 难道被入侵了
只好新建一个配置文件看看可不可行
vim my.cnf
然后将以下内容拷贝进去:
[mysqld]
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
datadir = /var/lib/mysql
secure-file-priv= NULL
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Custom config should go here
!includedir /etc/mysql/conf.d/
wq保存退出 然后重启mysql容器, 重新访问网站 还是不行
紧接着我在配置文件末尾添加了innodb_force_recovery=1
[mysqld]
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
datadir = /var/lib/mysql
secure-file-priv= NULL
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Custom config should go here
!includedir /etc/mysql/conf.d/
innodb_force_recovery=1
保存重启后, 网站正常访问, 问题解决
但是mysql容器日志一直提示:
[ERROR] [MY-012803] [InnoDB] innodb_force_recovery is on. We do not allow database modifications by the user. Shut down mysqld and edit my.cnf to set innodb_force_recovery=0
于是我把innodb_force_recovery值设为0 网站没问题 暂且就这样
关于innodb_force_recovery参数
- Mode 1当遇到损坏页时，不使 MySQL 崩溃
- Mode 2不运行后台操作
- Mode 3不会尝试回滚事务
- Mode 4不计算统计数据或应用存储/缓冲的变化
- Mode 5在启动过程中不查看撤消日志
- Mode 6在启动时不从重做日志（ib_logfiles）前滚
