首页 > 问答 > 关键词  > mysql最新资讯  > 正文

MySQL一直自动重启解决办法

2020-07-14 15:00 · 稿源:数据库干货铺

近期,测试环境出现了一次MySQL数据库不断自动重启的问题,导致的原因是强行kill -9 杀掉数据库进程导致,报错信息如下:

2019-07-24T01:14:53.769512Z0[Note]Executing'SELECT*FROMINFORMATION_SCHEMA.TABLES;'togetalistoftablesusingthedeprecatedpartitionengine.Youmayusethestartupoption'--disable-partition-engine-check'toskipthischeck.2019-07-24T01:14:53.769516Z0[Note]Beginningoflistofnon-nativelypartitionedtables01:14:53UTC-mysqldgotsignal11;
Thiscouldbebecauseyouhitabug.Itisalsopossiblethatthisbinary
oroneofthelibrariesitwaslinkedagainstiscorrupt,improperlybuilt,
ormisconfigured.Thiserrorcanalsobecausedbymalfunctioninghardware.
Attemptingtocollectsomeinformationthatcouldhelpdiagnosetheproblem.
Asthisisacrashandsomethingisdefinitelywrong,theinformation
collectionprocessmightfail.
PleasehelpusmakePerconaServerbetterbyreportingany
bugsathttp://bugs.percona.com/key_buffer_size=33554432read_buffer_size=8388608max_used_connections=0max_threads=501thread_count=4connection_count=0Itispossiblethatmysqldcoulduseupto
key_buffer_size+(read_buffer_size+sort_buffer_size)*max_threads=4478400Kbytesofmemory
Hopethat'sok;ifnot,decreasesomevariablesintheequation.Threadpointer:0x7f486900e000Attemptingbacktrace.Youcanusethefollowinginformationtofindout
wheremysqlddied.Ifyouseenomessagesafterthis,somethingwent
terriblywrong...
stack_bottom=7f4846172820thread_stack0x80000/usr/local/mysql5.7/bin/mysqld(my_print_stacktrace+0x2c)[0xed481c]/usr/local/mysql5.7/bin/mysqld(handle_fatal_signal+0x461)[0x7a15a1]/lib64/libpthread.so.0(+0xf7e0)[0x7f498697c7e0]/usr/local/mysql5.7/bin/mysqld(_ZN12ha_federated7rnd_posEPhS0_+0x2f)[0x12bcc3f]/usr/local/mysql5.7/bin/mysqld(_ZN7handler10ha_rnd_posEPhS0_+0x172)[0x804a12]/usr/local/mysql5.7/bin/mysqld(_ZN14Rows_log_event24do_index_scan_and_updateEPK14Relay_log_info+0x1e3)[0xe50e23]/usr/local/mysql5.7/bin/mysqld(_ZN14Rows_log_event14do_apply_eventEPK14Relay_log_info+0x716)[0xe50196]/usr/local/mysql5.7/bin/mysqld(_ZN9Log_event11apply_eventEP14Relay_log_info+0x6e)[0xe48fde]/usr/local/mysql5.7/bin/mysqld(_Z26apply_event_and_update_posPP9Log_eventP3THDP14Relay_log_info+0x1f0)[0xe8d6f0]/usr/local/mysql5.7/bin/mysqld(handle_slave_sql+0x163d)[0xe9a0fd]/usr/local/mysql5.7/bin/mysqld(pfs_spawn_thread+0x1b4)[0x1209414]/lib64/libpthread.so.0(+0x7aa1)[0x7f4986974aa1]/lib64/libc.so.6(clone+0x6d)[0x7f4984c6bc4d]
Tryingtogetsomevariables.
Somepointersmaybeinvalidandcausethedumptoabort.
Query(0):isaninvalidpointer
ConnectionID(threadID):2Status:NOT_KILLED
YoumaydownloadthePerconaServeroperationsmanualbyvisiting
http://www.percona.com/software/percona-server/.Youmayfindinformationinthemanualwhichwillhelpyouidentifythecauseofthecrash.

1. 初探过程

之前出现过类似的情况时,是因为内存不足,因日志中也有对应的提示:

key_buffer_size=33554432read_buffer_size=8388608max_used_connections=0max_threads=501thread_count=4connection_count=0Itispossiblethatmysqldcoulduseupto
key_buffer_size+(read_buffer_size+sort_buffer_size)*max_threads=4478400Kbytesofmemory
Hopethat'sok;ifnot,decreasesomevariablesintheequation.

此测试环境物理内存确实不大,且剩余内存也不足,而且是作为另一个测试环境的从库,内存分配的也少。

之前一些环境也出现过类似的情况,通过调整参数及释放内存的等处理后可以正常启动,于是尝试着关闭一些临时程序并调整MySQL上述几个参数的值,如:

[mysqld]
max_connections=50

然后重新启动MySQL,结果依旧不断重启。

初步处理未果。

2. 添加innodb_force_recovery 解决不断重启

在配置文件my.cnf添加innodb_force_recovery 先处理不断重启的问题

[mysqld]
innodb_force_recovery=4

添加后,再次启动MySQL,此时不再出现反复重启。

查看数据库日志,有提示[Note] InnoDB: !!! innodb_force_recovery is set to 4 !!!如下:

因为此时可以打开数据库,于是尝试启动从库,但是此时报错,提示Table 'mysql.slave_relay_log_info' is read only.

此时再看错误日志,如下

因此,本次启动时,innodb_force_recovery 设置为 4,在MySQL 5.6.15 以后,当 innodb_force_recovery 的值大于等于 4 的时候,InnoDB 表处于只读模式,因启动复制时需要将信息写入表中,所以此时报错。

注: 因设置为1-3 时,依旧未生效,因此我在处理时设置的为4(4 以上的值可能永久导致数据文件损坏。如果生产环境出现类似问题务必先拷贝一份测试,在测试通过后再在生产环境处理)。此时可以将所有数据dump出,之后再恢复即可。

3.innodb_force_recovery 参数

innodb_force_recovery 可以设置为 1-6,大的值包含前面所有小于它的值的影响。

1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。尽管检测到了损坏的page仍强制服务运行。一般设置为该值即可,然后dump出库表进行重建。2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行,如主线程需要执行fullpurge操作,会导致crash。阻止masterthread和任何purgethread运行。若crash发生在purge环节则使用该值。3(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。4(SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。如果可能导致崩溃则不要做这些操作。不要进行统计操作。该值可能永久损坏数据文件。若使用了该值,则将来要删除和重建辅助索引。5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志,InnoDB存储引擎会将未提交的事务视为已提交。此时InnoDB甚至把未完成的事务按照提交处理。该值可能永久性的损坏数据文件。6(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。恢复时不做redologroll-forward。使数据库页处于废止状态,继而可能引起B树或者其他数据库结构更多的损坏。

注意:

  • 为了安全,当设置参数值大于 0 后,可以对表进行 select, create, drop 操作,但 insert, update 或者 delete 这类操作是不允许的。
  • MySQL 5.6.15 以后,当 innodb_force_recovery 的值大于等于 4 的时候,InnoDB 表处于只读模式。
  • 在值小于等于 3 时可以通过 select 来 dump 表,可以 drop 或者 create 表。
  • MySQL 5.6.27 后大于 3 的值也支持 DROP TABLE; 如果事先知道哪个表导致了崩溃则可 drop 掉这个表。
  • 如果碰到了由失败的大规模导入或大量 ALTER TABLE 操作引起的 runaway rollback,则可 kill 掉 mysqld 线程然后设置 innodb_force_recovery = 3 使数据库重启后不进行 rollback。然后删除导致 runaway rollback 的表; 如果表内的数据损坏导致不能 dump 整个表内容。那么附带 order by primary_key desc 从句的查询或许能够 dump 出损坏部分之后的部分数据;

本文转载自微信公众号【数据库干货铺】。

举报

  • 相关推荐
  • 违停者屡次开门杀车主自费装护栏:没有办法的办法

    浙江车主周先生因私家车位旁通道常被违停车辆占用,导致车门多次被撞受损。为解决这一问题,他自费在车位上安装护栏。此前周先生曾尝试联系物业、交警处理,但效果不佳,违停车主态度强硬甚至否认撞车事实。法律界人士指出,若护栏完全在私人产权范围内属正当防护,但若侵占公共区域则可能违法。物业有权拆除违规安装的护栏。这反映了当前小区停车管理难题,也凸显了部分车主缺乏公共意识的问题。

  • 新郎凌晨准备接亲被父亲挂错档撞倒 母亲急得直跺脚

    ​7月13日,辽宁一场本应喜庆的婚礼因突发意外牵动人心。凌晨三点,新郎正为接亲做最后准备时,其父亲在倒车过程中不慎挂错档位,车辆失控撞倒儿子,现场顿时一片混乱。 据知情人士透露,事发时新郎父亲因紧张误将倒车档挂成前进档,车辆猛然向前冲出。正在车旁整理衣物的新郎被撞个正着,瞬间倒地。目睹这一幕的母亲急得直跺脚,而犯错的父亲更是自责到当场落

  • 忆联 Docker+MySQL 流控方案:打造安全高效存储底座,释放 AI 极致性能

    文章探讨了在AI时代背景下,基于Docker部署MySQL数据库的高效解决方案。通过Docker容器化技术,MySQL实现了灵活部署、资源高效利用和稳定隔离性,成为AI应用的首选数据库方案。测试结果显示,采用PCIe5.0企业级SSD配合Namespace技术和QoS优化策略,能精准控制性能偏差在2%以内,在混合读写场景下更可控制在1%以内。该方案显著提升了存储资源管理效率,为AI应用提供稳定可靠的数据存储支持,同时降低企业TCO成本,推动数据价值释放。

  • ppt自动生成工具最好用的3个

    文章介绍了当前AI生成PPT工具的发展现状,重点推荐了"秒出PPT"这一专业平台。该平台具有三大特色功能:1)智能对话式生成,支持中途修改需求;2)提供三种编辑模式(纯文本、纯设计和文本+设计);3)支持导入文档自动排版,提供"保持原文"和"AI智能修改"两种模式。平台还拥有丰富的模板库,支持在线更换颜色、字体等设计元素。虽然需要购买会员,但相比市面上质量参差不齐的同类产品,该工具在交互体验和功能完整性上表现突出。

  • 网友称赞雨天给顾客电瓶车搭雨披 胖东来:一直有这项服务

    近日,有河南许昌网友发布视频称,大雨来临前,胖东来工作人员给顾客的电动车都盖上了雨披,引不少网友点赞。 今日,胖东来工作人员回应称,一直有这项服务,商场会根据天气来置备雨披。 不过雨披也是有限的,只能说尽量给每辆车都盖上,有时候暴雨来了,还是免不了有车辆会被淋湿。

  • 韩国脑洞大开!带粘液的“人类鼻毛仿生过滤器” 可有效解决电脑灰尘问题

    灰尘沉积对电子设备有害,尤其是在需要良好散热的地方。尽管防尘过滤已成为现代PC和笔记本电脑的标配,但简单的网格结构在阻挡颗粒物 (PM) 方面效果不佳。 最近,韩国科学家一篇受粘液覆盖的鼻毛的天然过滤能力启发”的研究论文或许能提供一些答案。 这项研究概述了传统空气过滤器过滤效果不佳的问题,并提出了一种模拟人类鼻腔通道的过滤器,其内部填充了一层�

  • 加速Robotaxi部署 滴滴自动驾驶进入爆发前夜

    滴滴自动驾驶在第十七届国际交通技术设备展上亮相新一代L4级量产车型,配备33个传感器,展现技术突破。公司宣布将持续加大研发投入,与广汽埃安成立合资公司加速无人驾驶商业化落地。目前滴滴Robotaxi车队已在北京、广州等城市稳定运营超1800天无重大事故,并计划年内部署千台车辆。凭借多年技术积累和资本支持(累计融资超15.5亿美元),滴滴正迈向规模化商业运营新阶段。近期与广州市政府达成战略合作,进一步拓展智慧交通应用场景,标志着其自动驾驶技术进入爆发前夜。

  • 自动化测试首选服务商:Testin云测有何核心优势?

    文章探讨了AI技术如何重构自动化测试体系。传统自动化测试面临维护成本高、跨平台兼容性差等痛点,而AI通过智能用例生成、缺陷预测、自适应测试等能力实现质变:1)NLP技术将需求文档自动转化为可执行测试用例;2)机器学习分析历史数据预测高风险模块;3)计算机视觉实现跨平台UI元素识别。Testin云测构建了覆盖设备层到场景层的完整测试生态,通过云原生架构支持2000+终端实时调度,结合AI中台实现测试效率提升1.5倍,助力某金融机构降低年度质量成本超千万元。AI与自动化测试的深度融合,正推动质量保障体系向智能化、集约化演进。

  • 罗马仕辟谣倒闭 称定将努力解决一切问题

    近日,充电宝品牌罗马仕因产品自燃及大规模召回事件备受舆论关注。日前有消息称,该公司自7月1日起已内部通知员工全面停工停产,工资仅发放至6月,引发市场对其经营状况的猜测。 对此,罗马仕官方微博于深夜发布声明,明确否认倒闭传闻并表示“感谢社会各界的关心”。

  • 园区网络解决方案|锐捷网络发布 RG-UNC AS 系列:让中小网络运维化繁为简

    锐捷RG-UNC AS系列产品针对中小规模网络运维痛点,提供轻量化解决方案。其核心优势包括:1)统一管理多厂商异构设备,简化运维流程;2)智能告警系统实现故障分钟级定位,运维效率提升70%;3)终端准入可视化,支持IPv4/v6地址动态规划;4)国产化适配,支持多种部署模式。典型案例显示,该方案能整合分散网管系统,将IP地址利用率提升50%,使运维模式从"被动救火"转向"主动管控"。产品采用"基础守护+进阶拓展"架构,可伴随业务发展平滑升级,助力企业数字化转型。