开发者社区> 扬仔8888> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

511数据库无法启动故障

简介: 主机重启后mysql5.7无法通过systemctl启动
+关注继续查看

数据库mysq服务无法启动

临时解决办法:

经人提醒用mysqld_safe方式直接启动(自打脸1024次)

事件回顾


赞到爆活动粉丝猛增导致数据库主机CPU满载,系统卡顿

解决过程

  1.  将数据库关闭,操作命令:systemctl stop  mysqld
  2. 将数据库重启一次检验是否可正常重启 systemctl start  mysqld可正常启动
  3. 将数据库关闭
  4. 在阿里云控制台将数据库主机扩容至16C/32G高性能计算型ECS
  5. 登陆数据库主机systemctl start  mysqld无法启动,日志报错如下


mysql报错信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=300
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 127390 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x35)[0xf4c845]
/usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0x7dd584]
/lib64/libpthread.so.0(+0xf370)[0x7f814fcb7370]
/usr/lib64/mysql/plugin/server_audit.so(get_db_mysql57+0x12)[0x7f81107123e2]
/usr/lib64/mysql/plugin/server_audit.so(+0xa541)[0x7f8110712541]
/usr/sbin/mysqld[0x7dd6c6]
/usr/sbin/mysqld(_Z24plugin_foreach_with_maskP3THDPFcS0_P13st_plugin_intPvEijS3_+0x1b9)[0xd3e349]
/usr/sbin/mysqld(_Z18mysql_audit_notifyP3THD30mysql_event_general_subclass_tiPKcm+0x3d6)[0x7de326]
/usr/sbin/mysqld(my_message_sql+0x6f)[0x7cf28f]
/usr/sbin/mysqld(my_error+0xf6)[0xf47246]
/usr/sbin/mysqld(my_register_filename+0x29a)[0xf49b5a]
/usr/sbin/mysqld(my_create+0x6c)[0xf46a9c]
/usr/sbin/mysqld[0x7d0c60]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x16c0)[0x7d7fb0]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f814e697b35]
/usr/sbin/mysqld[0x7cd49d]
The manual page at http: class="bash plain">//dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
2018-05-11T06:49:23.670507Z mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

被上图中的第8行日志

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 127390 K  bytes of memory

Hope that's ok; if not, decrease some variables in the equation.

所迷惑,我们一直在修改上面的几个参数,但是数据库仍然无法启动

根据原因探索

  • 检查/etc/init.d/mysqld系统启动脚本,其中有一段代码是判断PID文件是否存在,如果/etc/my.cnf文件里无配置就会用/var/run/mysqld/mysqld.pid默认配置文件

代码如下

mysqld启动脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
get_mysql_option(){
    result=$(/usr/bin/my_print_defaults "$1" | sed -n "s/^--$2=//p" | tail -n 1)
    if [ -z "$result" ]; then
        # not found, use default
        result="$3"
    fi
}
get_mysql_option mysqld datadir "/var/lib/mysql"
datadir="$result"
get_mysql_option mysqld socket "$datadir/mysql.sock"
socketfile="$result"
get_mysql_option mysqld_safe log-error "/var/log/mysqld.log"
errlogfile="$result"
get_mysql_option mysqld_safe pid-file "/var/run/mysqld/mysqld.pid"
mypidfile="$result"

  • 检查/var/run下并无此文件,因为主机重启后系统会自动将此文件删除

三种解决方案:

原理解析:/etc/init.d/mysqld原理其实就是调用mysqld_safe来启动数据库

  • 方法一:给/etc/my.cnf添加配置让mysql到自己的数据目录下写/mydata/mysqld.pid

    [mysqld_safe]

    log-error=/mydata/mysqld.log

    pid-file=/mydata/mysqld.pid
    结果:systemctl start mysqld会一直卡在那,systemctl不正常结束返回,此时数据库是已经正常起来了,而操作系统命令systemctl找不到/var/run/mysqld/mysqld.pid而卡在那(失败)

  • 方法二:更换启动方式,直接用mysqld_safe --defaults-file=/etc/my.cnf启动,此方法是默认到/mydata目录下创建mysqld.pid文件,但是关闭时用
    mysqladmin  shutdown -uroot   -P6033 -p方式来关闭,还要输入密码较麻烦而且做开机启动也麻烦
  • 方法三:修改/etc/init.d/mysqld启动脚本添加自动创建/var/run/mysqld文件夹

    如果文件夹不存在就自动创建

    1
    2
    3
    4
    5
    6
    test -d /var/run/mysqld
    if [ $? -eq 1  ]
    then
    mkdir /var/run/mysqld/
    chown mysql:mysql /var/run/mysqld
    fi

    主机重启可自动将数据库拉起。

总结

        此次故障处理心得

                <p class="title">心得</p>
                        <span class="aui-icon icon-warning">Icon</span>
            <div class="message-content">
                        <p>1:一直被mysql的报错迷惑不断调试各个buffer的size大小,</p><p>2:忘记了尝试用mysqld_safe来启动</p><p>3:从库没能在第一时间切换成主库,这个在接下来的时候进行方案设计和实施</p><p>4:业务逻辑没有实现读写分离从库一直空闲而主库却已经累死</p><p>5:慢查询超时未告警部署</p><p>6:直接导致丢失大量可能性粉丝</p>
                </div>
</div>

为赞到爆的运营人员的公关和开发人员的应急点赞。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
重磅嘉宾畅聊大数据&AI开源话题,零距离感受激荡开源江湖
「开源人说」第四期——大数据& AI专场在今年云栖大会举办,阿里巴巴开源委员会大数据AI领域副主席王峰和阿里云AI开源项目EasyRec负责人施兴现场分享热门开源项目背后的故事。开源中国创始人&CTO红薯,白鲸开源联合创始人代立冬,浙大博导赵俊博,InfoQ总编辑王一鹏、Apache软件基金会成员李钰等嘉宾圆桌共话,对开源热点及痛点问题展开激烈讨论。
193170 0
拥抱开源,云原生时代下的开源牧码人的初心与坚守
王峰 阿里巴巴开源委员会大数据AI领域副主席 阿里云开源大数据平台负责人 Flink中文社区发起人
97757 0
「开源人说」|大咖齐聚首,大数据&AI开源话题对碰
「开源人说」第四期——大数据& AI专场在今年云栖大会举办,阿里巴巴开源委员会大数据AI领域副主席王峰和阿里云AI开源项目EasyRec负责人施兴现场分享热门开源项目背后的故事。开源中国创始人&CTO红薯,白鲸开源联合创始人代立冬,浙大博导赵俊博,InfoQ总编辑王一鹏、Apache软件基金会成员李钰等嘉宾圆桌共话,对开源热点及痛点问题展开激烈讨论。
138226 0
从JDK8飞升到JDK17,再到未来的JDK21
2022年,Spring6和 SpringBoot3都推出了,在此之前,Java社区很坚挺,一直是"新版任你发,我用Java 8",不管新版本怎么出,很少有人愿意升级。 这一次,Spring 直接来了个大招,SpringBoot3和Spring6的最低依赖就是JDK17!跨过 JDK 8-16,直接升级到 JDK 17。那么为什么是 JDK 17呢?
25447 0
干货!6个方面,32条总结教你提升职场经验
初入职场总是会感觉到迷茫,一身力气没有地方发挥,希望成长过程不要走弯路,本文从成长的捷径、功夫在日常、学会被管理、思维转换、要栓住情绪、成为 Leader 六个方面,总结了 32 条职场经验
28576 0
「开源人说」| 大数据王峰——云原生时代,做不忘初心开源牧码人
王峰 阿里巴巴开源委员会大数据AI领域副主席 阿里云开源大数据平台负责人 Flink中文社区发起人
141215 0
5个编写技巧,有效提高单元测试实践
结合单测的实践,本文总结了几点单元测试的好处与编写技巧,希望分享给大家。
24824 0
谈谈我工作中的23个设计模式
从基础的角度看,设计模式是研究类本身或者类与类之间的协作模式,是进行抽象归纳的一个很好的速成思路。后面阅读设计模式后,为了加深理解,对相关图片进行了描绘和微调。 从技术的角度已经有很多好的总结,本文会换一种角度思考,既然设计模式研究的是类与类的关系,我们作为工作的个体,一些工作中的策略是不是也可以进行类比,可以更好地去思考这些模式?答案是肯定的。
24883 0
Python3,5行代码,让你拥有无限量壁纸美图,终于告别手动下载了。
Python3,区区5行代码,让能拥有无限量壁纸美图,YYDS。
5900 0
阿里云物联网平台设备分发实战
物联网平台通过设备分发实现设备跨地域、跨实例或跨账号的分发。分发后,物联网平台下发新的连接地址给设备,设备本地固化收到信息之后,直接连接新的地址,免去二次烧录设备信息。本文主要演示指定地域的分发方式,设备完成分发后,通过向认证中心请求新的连接地址,重新建立连接。
2731 0
+关注
文章
问答
文章排行榜
最热
最新
相关电子书
更多
高可用数据库的搭建与备份恢复策略验证实战
立即下载
数据库异地备份及不还原快速查询备份集最佳实践
立即下载
数据库2025 V3
立即下载