|
|
|
|
挪动端

运维的苦,谁懂?一次“心有余悸”的迁库阅历!(有彩蛋)

IT 运维工程师不断是个“苦逼”的职业,“锄禾日当午,不如运维苦,对着破电脑,一调一下战书”是对运维任务的一个抽象的描绘。上面看看本文作者一次惊心肉跳的数据库迁徙阅历。

作者:甘兵泉源:51CTO技能栈|2018-04-28 09:35

人工智能+区块链的开展趋向及使用调研陈诉


【51CTO.com原创稿件】IT 运维工程师不断是个“苦逼”的职业,“锄禾日当午,不如运维苦,对着破电脑,一调一下战书”是对运维任务的一个抽象的描绘。上面看看本文作者一次惊心肉跳的数据库迁徙阅历。

事情来源

整个事情的来源还要从我近来入职了一家区块链金融公司提及,公司业务开展比拟迅猛,打破百万用户也是近在面前目今。

整个零碎都在阿里云上运转,每天都能看到用户的不时增长,即高兴又担心,为什么这么说呢?

由于我过去的时分,公司业务就曾经上线了,零碎接过去之后,疾速理解了一切的使用效劳都是在 Docker Swarm 跑起来的,也包罗 MySQL 数据库。

依照这种用户量开展下去,MySQL 在容器中运转用不了多久一定会撑不住,以致于我就有了迁库的想法。

我开端隐隐的担心起来,终究不想每天胆战心惊的做运维。以是立刻重新计划了新的方案和各人一同讨论。

终极总监和相干技能担任人都敲定用 RDS 做为数据库新的方案,周星驰的工夫中也说到:“天下武功,唯快不破”,于是就开端干起来。

迁徙方案

原架构图

如上图所示,剖析一下原来的架构图:

  • 从入口层(CDN)→到平安层(WAF)→最初抵达使用层 (ECS集群)。
  • Docker Swarm 买通了 ECS 集群中的每台效劳器,在每台 ECS 宿主机装置 Docker engine 并摆设了公司需求的使用效劳和数据库(Nginx、PHP、Redis、MySQL等)。
  • MySQL 容器经过本文件挂载到容器中完成数据耐久化。
  • 业务项目以 PHP 为主,PHP 也是运转在容器中,经过 PHP 指定的设置装备摆设文件衔接到 MySQL 容器中。

随意展现一下此中一个库的 docker-compose yaml 文件:

  1. version: "3" 
  2. services: 
  3.   ussbao: 
  4.     # replace username/repo:tag with your name and image details 
  5.     image: 隐蔽此镜像信息 
  6.     deploy: 
  7.       replicas: 1 
  8.       restart_policy: 
  9.         condition: on-failure 
  10.     environment: 
  11.       MYSQL_ROOT_PASSWORD: 隐蔽此信息 
  12.     volumes: 
  13.       - "/data//mysql/db1/:/var/lib/mysql/" 
  14.       - "/etc/localtime:/etc/localtime" 
  15.       - "/etc/timezone:/etc/timezone" 
  16. networks: 
  17.   default
  18.     external: 
  19.       name: 隐蔽此信息 

从下面的信息可以看出来,每个库只运转了一个 MySQL 容器,并没有主从或读写别离的方案。

并且也没有对数据库做任何优化,数据库如许跑下去让笔者很担心,正常来说,都市把数据库独立摆设运转。

调解后架构图

从上图可以看出来,笔者只是把 MySQL 独立出来了,守旧 RDS 实例来跑数据库,固然还守旧了其他的一些效劳(比方 OSS、云 Redis 等),这些不是本文的重点,就没有画出来。

Nginx 和 PHP 效劳照旧在 Docker Swarm 中运转。本文只是对迁徙后出了题目的库停止分享,上面来看看迁徙的方案吧。

迁徙流程方案

迁徙流程的方案:守旧 RDS 实例→备份 SQL→导入到 RDS→修正数据库设置装备摆设文件→测实验证。

迁徙步调如下:

  • 依据业务量计划守旧 RDS 实例,创立数据库和用户
  • 提早做好 RDS 白名单,添加容许拜访 RDS 的 IP 地点
  • mysqldump 备份 Docker 中的 MySQL
  • 把备份好的 .sql 文件导入到 RDS 中
  • 修正 PHP 项目标数据库设置装备摆设文件
  • 清空 PHP 项目标缓存文件或目次
  • 测实验证
  • RDS 定时备份

详细迁徙细节就不展现了,我是在夜深人静的时分停止迁徙操纵的,确定泰半夜没人拜访我们的 App 和网站了才开干的。

我们的业务状况有点像股市,我们是早晨 12 点不许操纵和买卖,第 2 天早上 9 点收盘,9 点钟是并发的顶峰期,就像向阳大悦城上午开门一样,大批的主顾同时并发过去了。

以是那天早晨在 12 点 15 分定时开干,按方案和提早预备的设置装备摆设、下令、剧本停止操纵的。

把 Docker 中运转的 MySQL 迁徙到 RDS 上十分顺遂,好几个库的迁徙不到半个小时就完毕了,而且把网站和 App 的流程都跑了一遍,也都是妥妥的。

终极把提早预备好的备份剧本放在 crontab 中定时实行,可以看下剧本内容:

  1. #!/bin/bash 
  2. #数据库IP 
  3. dbserver='热情*' 
  4. #数据库用户名 
  5. dbuser='ganbing' 
  6. #数据库暗码 
  7. dbpasswd='纨绔子弟' 
  8. #备份数据库,多个库用空格离隔 
  9. dbname='db1 db2 db3' 
  10. #备份工夫 
  11. backtime=`date +%Y%m%d%H%M` 
  12. out_time=`date +%Y%m%d%H%M%S` 
  13. #备份输入途径 
  14. backpath='/data/backup/mysql/' 
  15. logpath=''/data/backup/logs/' 
  16.  
  17. echo "################## ${backtime} #############################"  
  18. echo "开端备份"  
  19. #日记记载头部 
  20. echo "" >> ${logpath}/${dbname}_back.log 
  21. echo "-------------------------------------------------" >> ${logpath}/${dbname}_back.log 
  22. echo "备份工夫为${backtime},备份数据库 ${dbname} 开端" >> ${logpath}/${dbname}_back.log 
  23.  
  24. #正式备份数据库 
  25. for DB in $dbname; do 
  26.   source=`/usr/bin/mysqldump  -h ${dbserver} -u ${dbuser} -p${dbpasswd} ${DB} > ${backpath}/${DB}-${out_time}.sql` 2>> ${backpath}/mysqlback.log; 
  27.   #备份乐成以下操纵 
  28.   if [ "$?" == 0 ];then 
  29.     cd $backpath 
  30.     #为浪费硬盘空间,将数据库紧缩 
  31.     tar zcf ${DB}-${backtime}.tar.gz ${DB}-${backtime}.sql > /dev/null 
  32.     #删除原始文件,只留紧缩后文件 
  33.     rm -f ${DB}-${backtime}.sql 
  34.     #删除15天前备份,也便是只保管15天内的备份 
  35.     find $backpath -name "*.tar.gz" -type f -mtime +15 -exec rm -rf {} ; > /dev/null 2>&1 
  36.     echo "数据库 ${dbname} 备份乐成!!" >> ${logpath}/${dbname}_back.log 
  37.   else 
  38.   #备份失败则停止以下操纵 
  39.   echo "数据库 ${dbname} 备份失败!!" >> ${logpath}/${dbname}_back.log 
  40.   fi 
  41. done 
  42.  
  43. echo "完成备份" 
  44. echo "################## ${backtime} #############################" 

到了 1 点钟,确定没题目后发告诉到群里,发微信给向导表现已迁徙完成,停止很顺遂,然后笔者打车回家,睡觉。

雪崩降临

实在这一晚笔者睡得也不踏实,到了 8 点半就醒了,由于我们 9 点钟收盘,会有少量的客户涌进,每天开端发生新的买卖(买入和卖出),给各人看下截图:

果不其然,9 点当时,我翻开 App,统统正常,点击切换几个界面后,发明此中一个功用的恳求超时了,不断在转,然后紧接着其他功用也超时了。

完了,出题目了。赶忙开电脑查询题,过了一下子群里就开端沸腾了(反应很多多少客户翻开 App 都表现恳求超时了),我的德律风也第临时间响了,技能总监打来的,问我怎样回事,我说正在开电脑排查。

告急处置

排查询题

电脑翻开后,起首想到的便是 RDS 数据库出了题目,登录阿里云,进入 RDS 中的 DMS 数据办理控制台,一出来就傻眼了 “CPU 爆了”,这么多衔接数,如下图:

进入会话去看看,发明会话“炸锅了”,发明几百页的 select 都挤在 ub_user_calculate 这个表中,这个表数据量绝对大一些,现在有 200 多万条数据,如下图:

我的天然反响便是去检查此表的构造,但发明此表没有索引,我被诧异到了,居然没有索引,这......

然后笔者前往源数据库检查这张表,也发明没有索引,由此可以确定我导过去的这张表便是没有创立索引,如下图:

当数据库中呈现拜访表的 SQL 没创立索引,会招致全表扫描,假如表的数据量很大,扫描少量的数据,实行服从过慢,占用数据库衔接,衔接数聚集很快到达数据库的最大衔接数设置,新的使用恳求将会被回绝招致毛病发作。

处理题目

我赶忙把此事反应给开辟担任人,标明题目本源找到了,会话锁去世了,是由此中的一张表没有索引而招致的,问询需求给哪几个字段加索引。

然后接着操纵添加索引:

点击保管后,发明创立索引的 SQL 不断卡去世着,如下图所示:

忽然想起来另有一堆会话在那边,先 Kill 失一切会话吧,否则索引一定创立不了,然后又发明会话基本杀不完,如下图:

怎样办呢?会话杀不完...没方法,先把拜访入口堵截吧,横竖如今用户拜访也超时,就决然决议先把域名停了,拜访入口给堵截了,然后在添加索引。索引加上了,发明 CPU 还下不去,如下图:

为了疾速让 CPU 降下去,重启这个实例吧:

实例重启完后,CPU 下去了,会话也下去了:

开启入口层的域名拜访吧,再次察看如今的会话和 CPU 等况,如下图:

这就对了,会话也正常了,告诉向导业务规复。

再来看一下效劳器 CPU 的状况(迁徙 MySQL 后的状况),分明逐步恶化。

索引运用战略及优化

创立索引留意事变:

  • 在常常盘问而不常常增编削操纵的字段加索引。
  • order by 与 group by 后应间接运用字段,并且字段应该是索引字段。
  • 一个表上的索引不该该超越 6 个。
  • 索引字段的长度牢固,且长度较短。
  • 索引字段反复不克不及过多,假如某个字段为主键,那么这个字段不必设为索引。
  • 在过滤性高的字段上加索引。

运用索引留意事变:

  • 运用 like 要害字时,前置 % 会招致索引生效。
  • 运用 null 值会被主动从索引中扫除,索引普通不会树立在有空值的列上。
  • 运用 or 要害字时,or 左右字段假如存在一个没有索引,有索引字段也会生效。
  • 运用 != 操纵符时,将保持运用索引。由于范畴不确定,运用索引服从不高,会被引擎主动改为全表扫描。
  • 不要在索引字段停止运算。
  • 在运用复合索引时,最左前缀准绳,盘问时必需运用索引的第一个字段,不然索引生效;而且应只管即便让字段次序与索引次序分歧。
  • 防止隐式转换,界说的数据范例与传入的数据范例坚持分歧。

参考链接:https://help.aliyun.com/document_detail/52274.html?spm=a2c4g.11174283.6.812.ZGPyBQ

总结

这次毛病固然是表没有索引形成的,但是我是有责任的,没有挨个表反省一下表的构造。

经过这次毛病也可以看出来开辟在设计表的时分真的要十分的注重,留意细节。

另有便是之前在容器中运转的 MySQL 也时时时的呈现 CPU 瓶颈(比方 CPU 运用率偶然会到达 80% 以上),我应该提早发明这些题目,彻底排查找出题目地点缘由再停止迁库的操纵。

福利来啦

扫描下方二维码。存眷51CTO技能栈大众号,欢送在技能栈微信大众号留言讨论,您运维任务中最触目惊心的“救火故事”,小编将选出留言最精美的 10 名网友,送出《Docker从入门到实战》图书一本~运动停止工夫 5 月 4 日 12 时整,特殊道谢机器产业出书社为本次运动提供的图书资助。

内容简介

深度分析 Docker 的中心观点、完成原理、使用本领和生态零碎;片面涵盖 Docker 四大办理东西、三大组件、集群编排;引见上百个实战案例,提拔入手才能;以 Docker 以后的盛行版本为例解说 Swarm 集群办理。

甘兵,初级运维工程师,6 年运维任务经历。曾就职于国度互联网应急中央、天音控股等企业。拥有丰厚零碎运维经历,大型网络架构设计经历。热衷于开源技能的研讨,存眷的技能偏向 Docker、DevOps 等。

【51CTO原创稿件,协作站点转载请注明原文作者和来由为51CTO.com】

【编辑引荐】

  1. 29条运维工程师必会适用通博8888官网下令
  2. 腾讯IT老兵:云端微效劳架构下的运维考虑
  3. 从0到1,滴滴DB主动化运维架构理论
  4. 阿里千亿买卖面前,运维怎样做到“0”毛病公布?
  5. 企业纷繁上云 IT运维怎样借力AI完成智能化
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
各人都在看
猜你喜好

读 书 +更多

Wicked Cool Java中文版

本书次要引见由Sun微零碎公司创立的Java编程言语。 除了中心内容外,Java另有很多收费的财产,即开放源代码的库。本书便是为了引见这些库...

订阅51CTO邮刊

点击这里检查样刊

订阅51CTO邮刊