服务器意外断电MySQL无法启动

1.背景

客户反映无法登录系统。再三询问之下,客户说出一个情况:服务器因信息中心人为原因,最近总是意外断电。更多精彩文章请关注公众号『Pythonnote』或者『全栈技术精选』

what?服务器这么儿戏吗?这么不安全吗?不管什么情况,先去现场检查一番。

2.尝试过程

1.登录服务器启动服务。2.检查服务运行状态,发现 MySQL 容器一直处于尝试重启状态。3.检查 docker 日志,筛选 MySQL 容器报错部分。4.提示:数据库由于非正常情况关闭,正在尝试恢复,重新启动。然后一直处于启动报错关闭、启动报错关闭......5.先检查 SQL 备份文件是否正常,虽然有,但是文件大小明显不对,完蛋。。只能寄希望于断电那一刻的数据恢复了。更多精彩文章请关注『全栈技术精选』6.在 MySQL 的配置文件中有一项配置项 【innodb_force_recovery】代表强制恢复,它的值从1-6效果不断加强。越强,数据损坏的可能性越大,但是数据库正常启动的概率也越大。因此不能一上来就加足马力,最好是逐级递增尝试。7.在设置为 4 时,容器终于正常启动。但此时并不代表正常,因为此时数据库所有表的状态为锁定只读状态。我们只需要将此时的数据导出备份即可。8.导出最后一刻数据库后,将其导入到另一备用数据库中,恢复数据接入系统正常使用。

以上步骤是事后梳理而成,其实真实解决过程中问题不断,sql 导出文件无法使用,数据库问题,服务器问题,各种小问题不断。但是为了突出问题本身,不能将其他不相干的问题一一记录,否则会干扰大家问题解决。更多精彩文章请关注公众号『Pythonnote』

3.解决

1.在配置文件/etc/mysql/my.cnf中添加如下语句

[mysqld]
innodb_force_recovery = 4

innodb_force_recovery参数的值从 1-6 依次尝试,恢复等级越来越强。

1.重新启动 mysql 之后表都是只读状态,此时可以备份数据库2.将备份文件导入到新的数据库中更多精彩文章请关注公众号『Pythonnote』或者『全栈技术精选』

4.后记

生产环境所有操作必须三思而后行,在重大的压力、各种状况不断的情况下,很难保持一个清醒的头脑,不要自乱阵脚,让问题更复杂。

-----------------------

微信公众号:全栈技术精选 (ID: Pythonnote)

个人博客:https://www.pythonnote.cn

-----------------------

处理一下出现的日志 Plugin 'FEDERATED' is disabled. 2017-11-15 19:23:46 16c0 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator. 2017-11-15 19:23:46 1404 [Note] InnoDB: Using atomics to ref count buffer pool pages 2017-11-15 19:23:46 1404 [Note] InnoDB: The InnoDB memory heap is disabled 2017-11-15 19:23:46 1404 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions 2017-11-15 19:23:46 1404 [Note] InnoDB: Memory barrier is not used 2017-11-15 19:23:46 1404 [Note] InnoDB: Compressed tables use zlib 1.2.3 2017-11-15 19:23:46 1404 [Note] InnoDB: Not using CPU crc32 instructions 2017-11-15 19:23:46 1404 [Note] InnoDB: Initializing buffer pool, size = 9.0G 2017-11-15 19:23:46 1404 [Note] InnoDB: Completed initialization of buffer pool 2017-11-15 19:23:46 1404 [Note] InnoDB: Highest supported file format is Barracuda. 2017-11-15 19:23:46 1404 [Note] InnoDB: Log scan progressed past the checkpoint lsn 9219742510 2017-11-15 19:23:46 1404 [Note] InnoDB: Database was not shutdown normally! 2017-11-15 19:23:46 1404 [Note] InnoDB: Starting crash recovery. 2017-11-15 19:23:46 1404 [Note] InnoDB: Reading tablespace information from the .ibd files... 2017-11-15 19:23:46 1404 [Note] InnoDB: Restoring possible half-written data pages 2017-11-15 19:23:46 1404 [Note] InnoDB: from the doublewrite buffer... InnoDB: Doing recovery: scanned up to log sequence number 9219763629 InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 0 row operations to undo InnoDB: Trx id counter is 275040768 2017-11-15 19:23:47 1404 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed 2017-11-15 19:23:48 1404 [Note] InnoDB: 128 rollback segment(s) are active. InnoDB: Starting in background the rollback of uncommitted transactions 2017-11-15 19:23:48 fc8 InnoDB: Rolling back trx with id 275035944, 0 rows to undo 2017-11-15 19:23:48 fc8 InnoDB: Assertion failure in thread 4040 in file fut0lst.ic line 83 InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 2017-11-15 19:23:48 1404 [Note] InnoDB: Waiting for purge to start 2017-11-15 19:23:48 1404 [Note] InnoDB: 5.6.21 started; log sequence number 9219763629 2017-11-15 19:23:48 1404 [Note] Server hostname (bind-address): '*'; port: 3306 2017-11-15 19:23:48 1404 [Note] IPv6 is available. 2017-11-15 19:23:48 1404 [Note] - '::' resolves to '::'; 2017-11-15 19:23:48 1404 [Note] Server socket created on IP: '::'. 2017-11-15 19:23:48 1404 [Note] Event Scheduler: Loaded 0 events 2017-11-15 19:23:48 1404 [Note] D:\Documents\mysql\bin\mysqld.exe: ready for connections. Version: '5.6.21' socket: '' port: 3306 MySQL Community Server (GPL)
您好!对于MySQL断电无法启动的问题,可以尝试以下几个解决方法: 1. 检查日志文件:MySQL通常会在启动或运行过程中生成日志文件,可以查看日志文件以了解具体错误信息。日志文件的路径可能在MySQL的配置文件中定义,一般是在MySQL的数据目录下,文件名可能是"error.log"或类似的名称。 2. 检查数据库文件完整性:断电可能导致数据库文件损坏,可以尝试使用MySQL自带的工具进行修复。可以使用以下命令尝试修复数据库文件: ``` mysqlcheck --repair --all-databases ``` 注意:在执行修复命令之前,建议先备份数据库文件。 3. 检查MySQL配置文件:断电后,MySQL的配置文件可能发生了变化,可以检查配置文件中的参数是否正确。主要关注以下几个参数: - datadir:指定MySQL数据目录的路径,确保路径正确。 - innodb_force_recovery:如果使用InnoDB存储引擎,可以尝试将该参数设置为1,以启动MySQL并恢复数据。 配置文件的路径可能在不同的操作系统和MySQL版本中有所不同,一般是在MySQL安装目录下的"my.cnf"或"my.ini"文件。 4. 检查文件权限:确保MySQL数据目录和日志文件的权限正确,MySQL需要有足够的权限来读写这些文件。可以使用以下命令修复权限问题: ``` chown -R mysql:mysql /var/lib/mysql chown -R mysql:mysql /var/log/mysql ``` 注意:根据实际情况修改路径和用户名。 如果以上方法无法解决问题,可以提供具体的错误信息和操作系统、MySQL版本等相关信息,以便更准确地进行故障排查。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值