微服务架构下,MySQL 读写分离后,数据库 CPU 飙升卡壳问题解析

标签: dev | 发表时间:2019-09-21 00:00 | 作者:
出处:http://itindex.net/relian

前言

最近系统(基于SpringCloud+K8s)上线,运维团队早上8点左右在群里反馈,系统登录无反应!我的第一反应是Mysql数据库扛不住了。

排查问题也是一波三折,有网络问题,也有mysql读写分离后数据库参数优化问题。

问题回顾

1、运维团队早上8点左右在群里反馈,系统登录无反应。

2、DevOps团队通过查看Kibana日志,发现ELK、k8s集群、Redis、Mongodb、Nigix、文件服务器全部报:”Connect Unknown Error“,惊出一身冷汗。。。


心里嘀咕难道K8s容器也挂了?那还怎么玩?

3、查看监控短信,连续收到数据库读写分离Master-Slave警告信息


问题定位

1、Connect Unknown Error

经过从k8s团队确认,在早上8点左右出现了网络中断,持续了大概1分钟左右,导致k8s平台剔除响应超时的微服务节点,同时不断的启动新的容器。通过日志分析,8点半左右容器平台恢复正常,但是前台页面查询数据很慢(后来定位是Mysql数据库服务器CPU占用92%,导致数据库服务器处理应用请求很慢)。

2、Mysql读写分离Master-Slave警告信息

MHA架构

Mysql读写分离是采用MHA架构,一主两从(Master-Slave)。

Master负责数据的写操作,同时通过binlog日志同步到两个Slave从库,从库负责应用程序的查询操作。

在报Connect Unknown Error异常后,我们检查了Mysql服务器,发现Master节点CPU占用92%(应用层读写请求全部路由到了Master节点原因导致),而两个Slave节点全部处于空闲状态,并且主从数据不同步了。


3、数据库DBA通过查看mysql的show processlist命令,发现有大量的“create sort index(排序索引)”Sql语句(约36个)

经排查发现有个cms_article表有几百万的数据,客户端分页查询请求,虽然只取10条数据行,但是实际查询了几百万行数据,而且要在数据库内存中进行了几百万数据内存排序。所以出现了大量的create sort index排序索引。而且频繁执行Create Sort Index 会造成Mysql占满服务器CPU,导致服务器请求无响应,甚至假死状态!

解决办法

1、Connect Unknown Error

k8s平台自动剔除响应超时的微服务节点,同时启动新的容器,直至恢复到故障前的容器节点水平,依靠k8s平台自我修复。


2、Mysql读写分离Master-Slave警告信息

恢复步骤

1、重启Master-Slave节点,应用层读写请求正常,但是主从数据还是不同步,经定位是mysql同步线程Slave_IO_Running和Slave_SQL_Running都为No。

2、晚上重启Slave_IO_Running和Slave_SQL_Running线程

只有Slave_IO_Running和Slave_SQL_Running都为yes,则表示同步成功。


3、数据库DBA通过查看mysql的show processlist命令,发现有大量的“create sort index(排序索引)”Sql语句(约36个)

innodb_buffer_pool_size从500M调整为300G(服务器共500G内存)

innodb_buffer_pool_size

用于缓存索引和数据的内存大小, 这个当然是越多越好, 数据读写在内存中非常快, 减少了对磁盘的读写。

当数据提交或满足检查点条件后才一次性将内存数据刷新到磁盘中。然而内存还有操作系统或数据库其他进程使用, 一般设置 buffer pool 大小为总内存的 1/5 至 1/4。若设置不当, 内存使用可能浪费或者使用过多。

对于繁忙的服务器, buffer pool 将划分为多个实例以提高系统并发性, 减少线程间读写缓存的争用。

buffer pool 的大小首先受 innodb_buffer_pool_instances 影响, 当然影响较小。

Mysql性能调优总结

预计44W用户 峰值在线人数 5万左右。

1、innodb_buffer_pool_size=500M

太小,严重影响数据库性能。服务器共500G内存,但只给mysql缓冲池分配了500M,非常影响数据库性能,且造成资源浪费。建议设置为服务器内存的60%。

2、expire_logs_days=7

太短,只能保留7天的binlog,只能恢复7天内的任意数据。建议设置为参数文件里被覆盖的90天的设置。

3、long_query_time=10

太长,建议设置为2秒,让慢查询日志记录更多的慢查询。

4、transaction-isolation = read-committed

建议注释掉,使用数据库默认的事务隔离级别

5、innodb_lock_wait_timeout = 5

设置得太小,会导致事务因锁等待超过5秒,就被回滚。建议和云门户设置得保持一致,云门户大小为120。

6、autocommit = 0

#建议改为mysql默认的自动提交(autocommit=1),提升性能,方便日常操作。

相关 [微服务 架构 mysql] 推荐:

微服务架构下,MySQL 读写分离后,数据库 CPU 飙升卡壳问题解析

- - IT瘾-dev
最近系统(基于SpringCloud+K8s)上线,运维团队早上8点左右在群里反馈,系统登录无反应. 我的第一反应是Mysql数据库扛不住了. 排查问题也是一波三折,有网络问题,也有mysql读写分离后数据库参数优化问题. 1、运维团队早上8点左右在群里反馈,系统登录无反应. 2、DevOps团队通过查看Kibana日志,发现ELK、k8s集群、Redis、Mongodb、Nigix、文件服务器全部报:”Connect Unknown Error“,惊出一身冷汗.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

面向服务与微服务架构

- - CSDN博客推荐文章
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务,和我最近几年工作的实践比较相关感觉深受启发. 本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过.

微服务架构实践感悟

- - mindwind
从去年初开始接触微服务架构的一些理念,然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念. 最近关于微服务架构的讨论还是多起来,因为国外一些著名互联网公司(如:Amazon、Netflix 等)从实践中摸索出了一套新的大型系统架构方法论,并取得了成功,树立了很好的示范,然后这套方法论渐渐就被一些技术理论派 人士命名为微服务架构(Microservices).

微服务架构成功之路

- - CSDN博客推荐文章
本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/07/success-of-microservices. 近年来,在软件开发领域关于微服务的讨论呈现出火爆的局面,有人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发;同时,反对之声也很强烈,持反对观点的人表示微服务增加了系统维护、部署的难度,导致一些功能模块或代码无法复用,同时微服务允许使用不同的语言和框架来开发各个系统模块,这又会增加系统集成与测试的难度,而且随着系统规模的日渐增长,微服务在一定程度上也会导致系统变得越来越复杂.

微服务架构-模块迁移

- - 人月神话的BLOG
对于遗留的单体应用,要进行微服务架构的改造往往比一个全新应用基于微服务架构实现更加困难. 对于单体应用的微服务架构改造,最常见的方式仍然是将低耦合的模块逐步迁出. 下面以一个采购系统中招投标模块迁出为例进一步思考单体应用的微服务架构改造步骤. 在整个模型中我们将模型进行简化,当迁出一个功能模块进行微服务化的时候,首先要考虑的就是对该模块进行集成架构分析,考虑该模块和外围的集成情况,其次才是考虑该模块内部的私有数据.

SOA和微服务架构沟通(2.8)

- - 人月神话的BLOG
今天在广州交流SOA和微服务架构,特对关键内容做简单记录. 对于SOA和微服务架构的区别,在知乎一个回答里面我已经进行了详细的说明,即微服务架构强调的第一个重点就是 业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用. 这些小应用之间通过服务完成交互和集成.

微服务下的数据架构

- - IT瘾-dev
微服务是一个软件架构模式,对微服务的讨论大多集中在容器或其他技术是否能很好的实施微服务,而本文将从以下几个角度来和大家分享在微服务架构下进行数据设计需要关注的地方,旨在帮助大家在构建微服务架构时,提供一个从数据方面的视角:. 按照 Martin Fowler 的定义,微服务是一个软件架构模式,通过开发一系列的小型服务的方式来实现一个应用.

微服务架构之事件驱动架构 - 简书

- -
为了解决传统的单体应用(Monolithic Application)在可扩展性、可靠性、适应性、高部署成本等方面的问题,许多公司(比如Amazon、eBay和NetFlix等)开始使用微服务架构(Microservice Architecture)构建自己的应用. 微服务(Microservices) 是一种软件架构风格 (Software Architecture Style),它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础,利用模组化的方式组合出复杂的大型应用程序,各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯.