艾銻知識 | mysql,redis數(shù)據(jù)備份方案

2020-02-10 18:27 作者：admin 瀏覽量：

 
這次的肺炎疫情對中國的中小企業(yè)將會是沉重的打擊，據(jù)釘釘和微信兩個辦公平臺數(shù)據(jù)統(tǒng)計現(xiàn)有2億左右的人在家遠程辦公，那么對于中小企業(yè)的員工來說不懂IT技術(shù)將會讓他們面臨的最大挑戰(zhàn)和困難。
 
電腦不亮了怎么辦？系統(tǒng)藍屏如何處理？辦公室的電腦在家如何連接？網(wǎng)絡應該如何設置？VPN如何搭建？數(shù)據(jù)如何對接？服務器如何登錄？數(shù)據(jù)安全如何保證？數(shù)據(jù)如何存儲？視頻會議如何搭建？業(yè)務系統(tǒng)如何開啟等等一系列的問題，都會困擾著并非技術(shù)出身的您。
   
好消息是當您看到這篇文章的時候，就不用再為上述的問題而苦惱，您只需撥打艾銻無限的全國免費熱線電話:400 650 7820，就會有我們的遠程工程師為您解決遇到的問題，他們可以遠程幫您處理遇到的一些IT技術(shù)難題。
 
如遇到免費熱線占線，您還可以撥打我們的24小時值班經(jīng)理電話:15601064618或技術(shù)經(jīng)理的電話:13041036957，我們會在第一時間接聽您的來電，為您提供適合的解決方案，讓您無論在家還是在企業(yè)都能無憂辦公。
 
那艾銻無限具體能為您的企業(yè)提供哪些服務呢？ 艾銻無限始創(chuàng)于2005年，歷經(jīng)15年服務了5000多家中小企業(yè)并保障了幾十萬臺設備的正常運轉(zhuǎn)，積累了豐富的企業(yè)IT緊急問題和特殊故障的解決經(jīng)驗，制定了相對應的解決方案。我們?yōu)槟钠髽I(yè)提供的IT服務分為三大版塊:
 
第一版塊是保障性IT外包服務:如電腦設備運維，辦公設備運維，網(wǎng)絡設備運維，服務器運維等綜合性企業(yè)IT設備運維服務。
 
第二版塊是功能性互聯(lián)網(wǎng)外包服務:如網(wǎng)站開發(fā)外包，小程序開發(fā)外包，APP開發(fā)外包，電商平臺開發(fā)外包，業(yè)務系統(tǒng)的開發(fā)外包和后期的運維外包服務。
 
第三版塊是增值性云服務外包:如企業(yè)郵箱上云，企業(yè)網(wǎng)站上云，企業(yè)存儲上云，企業(yè)APP小程序上云，企業(yè)業(yè)務系統(tǒng)上云，阿里云產(chǎn)品等后續(xù)的云運維外包服務。
 
您要了解更多服務也可以登錄艾銻無限的官網(wǎng):www.bjitwx.com查看詳細說明，在疫情期間，您企業(yè)遇到的任何困境只要找到艾銻無限，能免費為您提供服務的我們絕不收一分錢，我們?nèi)w艾銻人承諾此活動直到中國疫情結(jié)束,我們將這次活動稱為——春雷行動。  
以下還有我們?yōu)槟峁┑囊恍┘夹g(shù)資訊，以便可以幫助您更好的了解相關(guān)的IT知識，幫您渡過疫情中辦公遇到的困難和挑戰(zhàn)，艾銻無限愿和中國中小企業(yè)一起共進退，因為我們相信萬物同體，能量合一，只要我們一起齊心協(xié)力，一定會成功。再一次祝福您和您的企業(yè)，戰(zhàn)勝疫情，您和您的企業(yè)一定行。
 
 
 
艾銻知識 | mysql,redis數(shù)據(jù)備份方案
 
 
之前在文章里面有提到過，很多事情，并沒有絕對的對錯，只是度的問題。而度的衡量又取決于時、勢二字。所以當形勢逼人的時候，基本就是這件事情非做不可的時候了。
 
   先說下背景，公司的服務器一直用的阿里云，包括mysql、redis也都是買了ECS自己搭建的。這里面有幾個原因:
 
創(chuàng)業(yè)的時候，阿里云只提供mysql的存儲，redis的存儲還沒提供。
 
沒錢，即時現(xiàn)在去看redis的存儲價格也是貴的嚇人。
 
   這樣自己來搞存儲有好處也有壞處。
好處：
 
完全可控，比如連接數(shù)限制，內(nèi)存限制，存儲限制。還有數(shù)據(jù)備份的靈活性等等。
 
強迫團隊服務器研發(fā)要有存儲運維能力。
 
省錢
 
   壞處：
 
冷備、熱備方案不完善。
 
 
存儲運維的成本較高，需要長時間積累。
 
   ok，問題就是這樣，接下來再來說一下我們之前的冷備和熱備方案。
可以說極其簡陋：
 
mysql、redis每天10點冷備，備份到本地磁盤和阿里云OSS
 
redis使用rdb落地，每60秒至少有1次寫就會觸發(fā)落地。
 
   這樣做的問題其實挺多的，主要幾個:
 
mysql dump的時候會導致游戲卡頓，即使加了 -single-transaction 參數(shù) 也僅僅是緩解
 
冷備頻率過低，真出現(xiàn)問題數(shù)據(jù)已經(jīng)太久
 
沒有熱備，風險較大
 
   針對這些問題，我們先做了mysql備份的優(yōu)化。
 
mysql主從同步，實現(xiàn)熱備。
 
主機不再執(zhí)行mysqldump，從機上每隔10分鐘執(zhí)行一次mysqldump，并備份到本地磁盤和阿里云OSS
 
   mysql的備份方案還是比較簡單的，唯一要注意的是，從機啟動的時候并不會從主機拉取所有數(shù)據(jù)，所以需要停服先把主機的數(shù)據(jù)手動同步到從機，之后再啟動同步。
 
   接下來，是redis的備份問題。
 
   為了與mysql的備份時間一致，redis這邊改成了主機每10分鐘備份rdb文件一次。
 
   但新方案運行了幾天之后，發(fā)現(xiàn)mysql經(jīng)常會突然響應變慢。
后來發(fā)現(xiàn)因為備份腳本的邏輯是會先把rdb文件copy一份出來，而copy的目標位置和mysql使用的磁盤是同一個磁盤，所以導致磁盤IO上升，從而mysql變慢。
并且redis的bgsave每隔60秒運行一次，也是會對磁盤有大量的寫操作，不過目前看來影響不是特別大，因為數(shù)據(jù)量比較小。
 
   所以我們開始考慮新的redis備份方案。
 
   與mysql不同，redis從機在第一次啟動的時候會從主機全量同步一次數(shù)據(jù)。
 
   所以我們想了幾套方案，我分別列一下。
 
   redis主從熱備，從機進行冷備
 
   這種方案其實是可以的，但是有幾個問題:
 
如果主機不關(guān)閉rdb保存就沒有問題，如果關(guān)閉了的話，那么當主機不小心宕機重啟，那么當主機redis啟動之后，會把從機redis的數(shù)據(jù)也抹掉。十分危險。
 
一旦從機服務器出問題，重新啟動后會從主機同步所有數(shù)據(jù)，導致主機bgsave運行，如果數(shù)據(jù)量很大，會導致主機內(nèi)存狂飆，如果主機又忘記配置內(nèi)存使用限制，就會是災難了。這在云風的一篇文章中有寫: 談談陌陌爭霸在數(shù)據(jù)庫方面踩過的坑( Redis 篇)
 
   所以后來，我決定選擇一個比較簡單的方案。
 
   使用ssh將rdb文件傳輸?shù)搅硪慌_機器上，再進行冷備。