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

?由於筆者過來的時候這裏業務就已經上線了，系統接過來之後，快速了解了所有的應用服務都是在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多萬條數據庫：
![]

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

4.2 解決問題

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

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


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

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

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

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

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

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

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

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

5總結

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

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

本想把docker中運行的mysql遷移至RDS中，確沒想到mysql會話“炸鍋了”