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

1事件起源

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

惠來(lái)ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場(chǎng)景，ssl證書未來(lái)市場(chǎng)廣闊！成為成都創(chuàng)新互聯(lián)公司的ssl證書銷售渠道，可以享受市場(chǎng)價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：13518219792（備注：SSL證書合作）期待與您的合作！

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

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

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ù)庫(kù)（nginx、php、redis、mysql等）；
3、mysql容器通過(guò)宿主機(jī)的本地（目錄）掛載到容器中實(shí)現(xiàn)數(shù)據(jù)持久化；
4、業(yè)務(wù)項(xiàng)目以php為主，php也是運(yùn)行在容器中，通過(guò)php指定的配置文件連接到mysql容器中。

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

筆者就隨便展示一下其中一個(gè)庫(kù)的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: 隱藏此信息

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

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

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

2.3 遷移流程方案

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

1、根據(jù)業(yè)務(wù)量規(guī)劃開通RDS實(shí)例，創(chuàng)建數(shù)據(jù)庫(kù)和用戶；
2、提前做好RDS白名單，添加允許訪問RDS的IP地址；
3、mysqldump 備份docker 中的mysql;
4、把備份好的.sql文件導(dǎo)入到RDS中；
5、修改php項(xiàng)目的數(shù)據(jù)庫(kù)配置文件；
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ā)的高峰期，就像朝陽(yáng)大悅城上午開門一樣，大批的顧客同時(shí)并發(fā)過(guò)來(lái)了。

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

#!/bin/bash
#數(shù)據(jù)庫(kù)IP
dbserver='*******'
#數(shù)據(jù)庫(kù)用戶名
dbuser='ganbing'
#數(shù)據(jù)庫(kù)密碼
dbpasswd='************'
#備份數(shù)據(jù)庫(kù),多個(gè)庫(kù)用空格隔開
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ù)庫(kù) ${dbname} 開始" >> ${logpath}/${dbname}_back.log

#正式備份數(shù)據(jù)庫(kù)
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ù)庫(kù)壓縮
    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ù)庫(kù) ${dbname} 備份成功!!" >> ${logpath}/${dbname}_back.log
  else
  #備份失敗則進(jìn)行以下操作
  echo "數(shù)據(jù)庫(kù) ${dbname} 備份失敗!!" >> ${logpath}/${dbname}_back.log
  fi
done

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

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

3雪崩來(lái)臨

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

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

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

4緊急處理

4.1 排查問題

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

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

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

分析：當(dāng)數(shù)據(jù)庫(kù)中出現(xiàn)訪問表的SQL沒創(chuàng)建索引導(dǎo)致全表掃描，如果表的數(shù)據(jù)量很大掃描大量的數(shù)據(jù)，執(zhí)行效率過(guò)慢，占用數(shù)據(jù)庫(kù)連接，連接數(shù)堆積很快達(dá)到數(shù)據(jù)庫(kù)的最大連接數(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一直卡死著,，如下圖所示：


突然想起來(lái)還有一堆會(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ǔ)的一張圖：在來(lái)看一下服務(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)該超過(guò)6個(gè)。
• 索引字段的長(zhǎng)度固定，且長(zhǎng)度較短。
• 索引字段重復(fù)不能過(guò)多，如果某個(gè)字段為主鍵，那么這個(gè)字段不用設(shè)為索引。
• 在過(guò)濾性高的字段上加索引。

使用索引注意事項(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、通過(guò)此次故障也可以看出來(lái)開發(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)行遷庫(kù)的操作。

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

當(dāng)前標(biāo)題：容器中的mysql遷移RDS，會(huì)話卻“爆了”
分享網(wǎng)址：http://muchs.cn/article12/piohgc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、網(wǎng)站內(nèi)鏈、企業(yè)建站、網(wǎng)站策劃、動(dòng)態(tài)網(wǎng)站、云服務(wù)器

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)