容器中的mysql遷移RDS，會(huì)話卻“爆了”

1事件起源

?整個(gè)事件的起源還要從筆者最近入職了一家區(qū)塊鏈金融公司來說起（為了保密性，不便透露公司名字），公司業(yè)務(wù)發(fā)展比較迅猛，突破百萬用戶也是近在眼前。整個(gè)系統(tǒng)都在阿里云上運(yùn)行，每天都能看到用戶的不斷增長(zhǎng)，即興奮又擔(dān)憂，為什么這么說呢？

?由于筆者過來的時(shí)候這里業(yè)務(wù)就已經(jīng)上線了，系統(tǒng)接過來之后，快速了解了所有的應(yīng)用服務(wù)都是在docker swarm跑起來的，也包括mysql數(shù)據(jù)庫，以至于筆者就有了遷庫的想法，按照這種用戶量發(fā)展下去，mysql在容器中運(yùn)行用不了多久肯定會(huì)撐不住。

?筆者就開始隱隱的擔(dān)憂起來，畢竟不想每天提心吊膽的做運(yùn)維。所以立馬重新規(guī)劃了新的方案和大家一起探討，最終總監(jiān)和相關(guān)技術(shù)負(fù)責(zé)人都敲定用RDS做為數(shù)據(jù)庫新的方案，周星馳的功夫中也說道過：“天下武功，唯快不破”。就立馬開始動(dòng)身干起來。

2遷移計(jì)劃

2.1原架構(gòu)圖

分析架構(gòu)圖

1、從入口層（CDN）---> 到安全層（WAF） ---> 最后到達(dá)應(yīng)用層 （ECS集群）；
2、Docker Swarm打通了ECS集群中的每臺(tái)服務(wù)器，在每臺(tái)ECS宿主機(jī)安裝Docker engine并部署了公司需要的應(yīng)用服務(wù)和數(shù)據(jù)庫（nginx、php、redis、mysql等）；
3、mysql容器通過宿主機(jī)的本地（目錄）掛載到容器中實(shí)現(xiàn)數(shù)據(jù)持久化；
4、業(yè)務(wù)項(xiàng)目以php為主，php也是運(yùn)行在容器中，通過php指定的配置文件連接到mysql容器中。

其中一個(gè)庫的 docker-compose yaml文件

筆者就隨便展示一下其中一個(gè)庫的yaml文件，比較簡(jiǎn)單：

version: "3"
services:
  ussbao:
    # replace username/repo:tag with your name and image details
    image: 隱藏此鏡像信息
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
    environment:
      MYSQL_ROOT_PASSWORD: 隱藏此信息
    volumes:
      - "/data//mysql/db1/:/var/lib/mysql/"
      - "/etc/localtime:/etc/localtime"
      - "/etc/timezone:/etc/timezone"
networks:
  default:
    external:
      name: 隱藏此信息

從上面的信息可以看出來，每個(gè)庫只運(yùn)行了一個(gè)mysql容器，并沒有主從或讀寫分離的方案。而且也沒有對(duì)數(shù)據(jù)庫進(jìn)行做任何優(yōu)化，數(shù)據(jù)庫這樣跑下去讓筆者很擔(dān)憂，正常來說，都會(huì)把數(shù)據(jù)庫獨(dú)立部署運(yùn)行。

2.2調(diào)整后架構(gòu)圖

?從上圖可以看出來，筆者只是把mysql獨(dú)立出來了，開通RDS實(shí)例來跑數(shù)據(jù)庫，當(dāng)然還開通了其它的一些服務(wù)（比如oss、云redis等），這些不是本文的重點(diǎn)，就沒有畫出來。nginx和php服務(wù)還是在docker swarm中運(yùn)行。本文只是對(duì)遷移后出了問題的庫進(jìn)行分享，下面來看看遷移的方案吧。

2.3 遷移流程方案

開通RDS實(shí)例 ---> 備份sql ----> 導(dǎo)入到RDS ---> 修改數(shù)據(jù)庫配置文件 --->測(cè)試驗(yàn)證

1、根據(jù)業(yè)務(wù)量規(guī)劃開通RDS實(shí)例，創(chuàng)建數(shù)據(jù)庫和用戶；
2、提前做好RDS白名單，添加允許訪問RDS的IP地址；
3、mysqldump 備份docker 中的mysql;
4、把備份好的.sql文件導(dǎo)入到RDS中；
5、修改php項(xiàng)目的數(shù)據(jù)庫配置文件；
6、清空php項(xiàng)目的緩存文件或目錄；
7、測(cè)試驗(yàn)證；
8、RDS定時(shí)備份；

?具體遷移細(xì)節(jié)就不展示了，筆者是在夜深人靜的時(shí)候進(jìn)行遷移操作的，確定大半夜沒人訪問我們的APP和網(wǎng)站了才開干的。

?我們的業(yè)務(wù)情況還有點(diǎn)像股市，我們是晚上12點(diǎn)不許操作和交易，第2天早上9點(diǎn)開盤，9點(diǎn)鐘是并發(fā)的高峰期，就像朝陽大悅城上午開門一樣，大批的顧客同時(shí)并發(fā)過來了。

?所以那天晚上在12點(diǎn)15分準(zhǔn)時(shí)開干，按計(jì)劃和提前準(zhǔn)備的配置、命令、腳本進(jìn)行操作的。把docker 中運(yùn)行的mysql遷移到RDS上非常順利，好幾個(gè)庫遷移不到半個(gè)小時(shí)就結(jié)束了，并且把網(wǎng)站和APP的流程都跑了一遍，也都是妥妥的，最終把提前準(zhǔn)備好備份腳本放在crontab中定時(shí)執(zhí)行，可以來看下腳本內(nèi)容：

#!/bin/bash
#數(shù)據(jù)庫IP
dbserver='*******'
#數(shù)據(jù)庫用戶名
dbuser='ganbing'
#數(shù)據(jù)庫密碼
dbpasswd='************'
#備份數(shù)據(jù)庫,多個(gè)庫用空格隔開
dbname='db1 db2 db3'
#備份時(shí)間
backtime=`date +%Y%m%d%H%M`
out_time=`date +%Y%m%d%H%M%S`
#備份輸出路徑
backpath='/data/backup/mysql/'
logpath=''/data/backup/logs/'

echo "################## ${backtime} #############################" 
echo "開始備份" 
#日志記錄頭部
echo "" >> ${logpath}/${dbname}_back.log
echo "-------------------------------------------------" >> ${logpath}/${dbname}_back.log
echo "備份時(shí)間為${backtime},備份數(shù)據(jù)庫 ${dbname} 開始" >> ${logpath}/${dbname}_back.log

#正式備份數(shù)據(jù)庫
for DB in $dbname; do
  source=`/usr/bin/mysqldump  -h ${dbserver} -u ${dbuser} -p${dbpasswd} ${DB} > ${backpath}/${DB}-${out_time}.sql` 2>> ${backpath}/mysqlback.log;
  #備份成功以下操作
  if [ "$?" == 0 ];then
    cd $backpath
    #為節(jié)約硬盤空間，將數(shù)據(jù)庫壓縮
    tar zcf ${DB}-${backtime}.tar.gz ${DB}-${backtime}.sql > /dev/null
    #刪除原始文件，只留壓縮后文件
    rm -f ${DB}-${backtime}.sql
    #刪除15天前備份，也就是只保存15天內(nèi)的備份
    find $backpath -name "*.tar.gz" -type f -mtime +15 -exec rm -rf {} \; > /dev/null 2>&1
    echo "數(shù)據(jù)庫 ${dbname} 備份成功!!" >> ${logpath}/${dbname}_back.log
  else
  #備份失敗則進(jìn)行以下操作
  echo "數(shù)據(jù)庫 ${dbname} 備份失敗!!" >> ${logpath}/${dbname}_back.log
  fi
done

echo "完成備份"
echo "################## ${backtime} #############################"

到了1點(diǎn)鐘，確定沒問題后發(fā)通知到群里，發(fā)微信給領(lǐng)導(dǎo)表示已遷移完成，進(jìn)行很順利，然后筆者打車回家，睡覺。

3雪崩來臨

其實(shí)這一晚筆者睡得也不踏實(shí)，到了8點(diǎn)半就醒了，因?yàn)槲覀?點(diǎn)鐘開盤，會(huì)有大量的客戶涌進(jìn)，每天開始產(chǎn)生新的交易（買入和賣出）,給大家看下截圖：

果不其然，9點(diǎn)過后，筆者打開APP，一切正常，點(diǎn)擊切換幾個(gè)界面后，發(fā)現(xiàn)其中一個(gè)功能的請(qǐng)求超時(shí)了，一直在轉(zhuǎn)，然后緊接著其它功能也超時(shí)了。完了，出問題了。趕緊開筆記本查問題，過了一會(huì)兒群里就開始沸騰了（反映好多客戶打開APP都顯示請(qǐng)求超時(shí)了），我的電話也立馬響了，技術(shù)總監(jiān)打來的，問我怎么回事，我說正在開筆記本排查。

這個(gè)時(shí)候，我要說明一下：運(yùn)維人員此時(shí)需要冷靜并且安靜的處理問題，公司領(lǐng)導(dǎo)千萬別催得太急以免打亂處理人的思路。我們總監(jiān)臨場(chǎng)處理能力做得真是非常到位，馬上跟我說不用擔(dān)心上面壓力，有他扛著，叫我只管排查和解決問題。

4緊急處理

4.1 排查問題

筆記本打開后，首先想到的就是RDS數(shù)據(jù)庫出了問題，登錄阿里云，進(jìn)入RDS中的DMS數(shù)據(jù)管理控制臺(tái)，一進(jìn)去就傻眼了 “CPU爆了”，這么多連接數(shù)，如下圖：

進(jìn)入會(huì)話去看看，發(fā)現(xiàn)會(huì)話“炸鍋了”，發(fā)現(xiàn)幾百頁的select都擠在ub_user_calculate這個(gè)表中,這個(gè)表是數(shù)據(jù)量相對(duì)大一些，這張表目前有200多萬條數(shù)據(jù)：
![]

自然反應(yīng)就是去查看此表的結(jié)構(gòu)，發(fā)現(xiàn)此表沒有索引，被驚訝到了，竟然沒有索引，這...... 然后筆者返回源數(shù)據(jù)庫查看這張表，也發(fā)現(xiàn)沒有索引，由此可以確定我導(dǎo)過來的這張表就是沒有創(chuàng)建索引，如下圖：

分析：當(dāng)數(shù)據(jù)庫中出現(xiàn)訪問表的SQL沒創(chuàng)建索引導(dǎo)致全表掃描，如果表的數(shù)據(jù)量很大掃描大量的數(shù)據(jù)，執(zhí)行效率過慢，占用數(shù)據(jù)庫連接，連接數(shù)堆積很快達(dá)到數(shù)據(jù)庫的最大連接數(shù)設(shè)置，新的應(yīng)用請(qǐng)求將會(huì)被拒絕導(dǎo)致故障發(fā)生。

4.2 解決問題

趕緊把此事反應(yīng)給開發(fā)負(fù)責(zé)人，表明問題根源找到了，會(huì)話鎖死了，由其中的一張表沒有索引而導(dǎo)致的，問詢問需要給哪幾個(gè)字段加索引。然后接著操作增加索引：

點(diǎn)擊保存后，發(fā)現(xiàn)創(chuàng)建索引的sql一直卡死著,，如下圖所示：


突然想起來還有一堆會(huì)話在那里，先kill 掉所有會(huì)話吧，不然索引肯定創(chuàng)建不了，然后又發(fā)現(xiàn)會(huì)話根本殺不完，如下圖：

怎么辦呢？會(huì)話殺不完...

沒辦法，先把訪問入口切斷吧，反正現(xiàn)在用戶訪問也超時(shí)，就毅然絕對(duì)先把域名停了，訪問入口給切斷了，然后在增加索引，索引加上了。

入口也斷了，索引也加上了，發(fā)現(xiàn)CPU還下去，如下圖：

為了快速讓CPU降下去，重啟這個(gè)實(shí)例吧：

實(shí)例重啟完后，CPU下去了，會(huì)話也下去了：

開啟入口層的域名訪問吧，在次觀察現(xiàn)在的會(huì)話和CPU等況，如下圖：

這就對(duì)了，會(huì)話也正常了，通知領(lǐng)導(dǎo)業(yè)務(wù)恢復(fù)。。。

筆者后期補(bǔ)的一張圖：在來看一下服務(wù)器CPU情況（遷移MYSQL后的情況），明顯逐漸好轉(zhuǎn)。

5索引使用策略及優(yōu)化

創(chuàng)建索引

• 在經(jīng)常查詢而不經(jīng)常增刪改操作的字段加索引。
• order by與group by后應(yīng)直接使用字段，而且字段應(yīng)該是索引字段。
• 一個(gè)表上的索引不應(yīng)該超過6個(gè)。
• 索引字段的長(zhǎng)度固定，且長(zhǎng)度較短。
• 索引字段重復(fù)不能過多，如果某個(gè)字段為主鍵，那么這個(gè)字段不用設(shè)為索引。
• 在過濾性高的字段上加索引。

使用索引注意事項(xiàng)

• 使用like關(guān)鍵字時(shí)，前置%會(huì)導(dǎo)致索引失效。
• 使用null值會(huì)被自動(dòng)從索引中排除，索引一般不會(huì)建立在有空值的列上。
• 使用or關(guān)鍵字時(shí)，or左右字段如果存在一個(gè)沒有索引，有索引字段也會(huì)失效。
• 使用!=操作符時(shí)，將放棄使用索引。因?yàn)榉秶淮_定，使用索引效率不高，會(huì)被引擎自動(dòng)改為全表掃描。
• 不要在索引字段進(jìn)行運(yùn)算。
• 在使用復(fù)合索引時(shí)，最左前綴原則，查詢時(shí)必須使用索引的第一個(gè)字段，否則索引失效；并且應(yīng)盡量讓字段順序與索引順序一致。
• 避免隱式轉(zhuǎn)換，定義的數(shù)據(jù)類型與傳入的數(shù)據(jù)類型保持一致。

參考：https://help.aliyun.com/document_detail/52274.html?spm=a2c4g.11174283.6.812.ZGPyBQ

6總結(jié)

1、此次故障雖然是表沒有索引造成的，但是筆者是有責(zé)任的，沒有挨個(gè)表檢查一下表的結(jié)構(gòu)；
2、通過此次故障也可以看出來開發(fā)在設(shè)計(jì)表的真的要非常的重視，注意細(xì)節(jié)；
3、還有就是之前在容器中運(yùn)行的mysql也時(shí)不時(shí)的出現(xiàn)CPU瓶頸（比如CPU使用率偶爾會(huì)達(dá)到80%以上），筆者應(yīng)該就要提前發(fā)現(xiàn)這些問題，徹底排查找出問題所在原因在進(jìn)行遷庫的操作。

本章內(nèi)容到此結(jié)束，喜歡我的文章，請(qǐng)點(diǎn)擊最上方右角處的《關(guān)注》！?。?/p>