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

1事件起源

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

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

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

2遷移計劃

2.1原架構圖

分析架構圖

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

其中一個庫的 docker-compose yaml文件

筆者就隨便展示一下其中一個庫的yaml文件，比較簡單：

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: 隱藏此信息

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

2.2調整后架構圖

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

2.3 遷移流程方案

開通RDS實例 ---> 備份sql ----> 導入到RDS ---> 修改數據庫配置文件 --->測試驗證

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

?具體遷移細節就不展示了，筆者是在夜深人靜的時候進行遷移操作的，確定大半夜沒人訪問我們的APP和網站了才開干的。

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

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

#!/bin/bash
#數據庫IP
dbserver='*******'
#數據庫用戶名
dbuser='ganbing'
#數據庫密碼
dbpasswd='************'
#備份數據庫,多個庫用空格隔開
dbname='db1 db2 db3'
#備份時間
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 "備份時間為${backtime},備份數據庫 ${dbname} 開始" >> ${logpath}/${dbname}_back.log

#正式備份數據庫
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
    #為節約硬盤空間，將數據庫壓縮
    tar zcf ${DB}-${backtime}.tar.gz ${DB}-${backtime}.sql > /dev/null
    #刪除原始文件，只留壓縮后文件
    rm -f ${DB}-${backtime}.sql
    #刪除15天前備份，也就是只保存15天內的備份
    find $backpath -name "*.tar.gz" -type f -mtime +15 -exec rm -rf {} \; > /dev/null 2>&1
    echo "數據庫 ${dbname} 備份成功!!" >> ${logpath}/${dbname}_back.log
  else
  #備份失敗則進行以下操作
  echo "數據庫 ${dbname} 備份失敗!!" >> ${logpath}/${dbname}_back.log
  fi
done

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

到了1點鐘，確定沒問題后發通知到群里，發微信給領導表示已遷移完成，進行很順利，然后筆者打車回家，睡覺。

3雪崩來臨

其實這一晚筆者睡得也不踏實，到了8點半就醒了，因為我們9點鐘開盤，會有大量的客戶涌進，每天開始產生新的交易（買入和賣出）,給大家看下截圖：

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

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

4緊急處理

4.1 排查問題

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

進入會話去看看，發現會話“炸鍋了”，發現幾百頁的select都擠在ub_user_calculate這個表中,這個表是數據量相對大一些，這張表目前有200多萬條數據：
![]

自然反應就是去查看此表的結構，發現此表沒有索引，被驚訝到了，竟然沒有索引，這...... 然后筆者返回源數據庫查看這張表，也發現沒有索引，由此可以確定我導過來的這張表就是沒有創建索引，如下圖：

分析：當數據庫中出現訪問表的SQL沒創建索引導致全表掃描，如果表的數據量很大掃描大量的數據，執行效率過慢，占用數據庫連接，連接數堆積很快達到數據庫的最大連接數設置，新的應用請求將會被拒絕導致故障發生。

4.2 解決問題

趕緊把此事反應給開發負責人，表明問題根源找到了，會話鎖死了，由其中的一張表沒有索引而導致的，問詢問需要給哪幾個字段加索引。然后接著操作增加索引：

點擊保存后，發現創建索引的sql一直卡死著,，如下圖所示：


突然想起來還有一堆會話在那里，先kill 掉所有會話吧，不然索引肯定創建不了，然后又發現會話根本殺不完，如下圖：

怎么辦呢？會話殺不完...

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

入口也斷了，索引也加上了，發現CPU還下去，如下圖：

為了快速讓CPU降下去，重啟這個實例吧：

實例重啟完后，CPU下去了，會話也下去了：

開啟入口層的域名訪問吧，在次觀察現在的會話和CPU等況，如下圖：

這就對了，會話也正常了，通知領導業務恢復。。。

筆者后期補的一張圖：在來看一下服務器CPU情況（遷移MYSQL后的情況），明顯逐漸好轉。

5索引使用策略及優化

創建索引

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

使用索引注意事項

• 使用like關鍵字時，前置%會導致索引失效。
• 使用null值會被自動從索引中排除，索引一般不會建立在有空值的列上。
• 使用or關鍵字時，or左右字段如果存在一個沒有索引，有索引字段也會失效。
• 使用!=操作符時，將放棄使用索引。因為范圍不確定，使用索引效率不高，會被引擎自動改為全表掃描。
• 不要在索引字段進行運算。
• 在使用復合索引時，最左前綴原則，查詢時必須使用索引的第一個字段，否則索引失效；并且應盡量讓字段順序與索引順序一致。
• 避免隱式轉換，定義的數據類型與傳入的數據類型保持一致。

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

6總結

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

本章內容到此結束，喜歡我的文章，請點擊最上方右角處的《關注》！！！