先說下背景，公司的服務器一直用的阿里雲，包括mysql、redis也都是買了ECS自己搭建的。這裡面有幾個原因:
- 創業的時候，阿里雲只提供mysql的存儲，redis的存儲還沒提供。
- 沒錢，即時現在去看redis的存儲價格也是貴的嚇人。
這樣自己來搞存儲有好處也有壞處。
好處：
- 完全可控，比如連接數限制，內存限制，存儲限制。還有數據備份的靈活性等等。
- 強迫團隊服務器研發要有存儲運維能力。
- 省錢
壞處：
- 冷備、熱備方案不完善。
- 存儲運維的成本較高，需要長時間積累。
ok，問題就是這樣，接下來再來說一下我們之前的冷備和熱備方案。
可以說極其簡陋：
- mysql、redis每天10點冷備，備份到本地磁盤和阿里雲OSS
- redis使用rdb落地，每60秒至少有1次寫就會觸發落地。
這樣做的問題其實挺多的，主要幾個:
- mysql dump的時候會導致遊戲卡頓，即使加了 -single-transaction 參數 也僅僅是緩解
- 冷備頻率過低，真出現問題數據已經太久
- 沒有熱備，風險較大
針對這些問題，我們先做了mysql備份的優化。
- mysql主從同步，實現熱備。
- 主機不再執行mysqldump，從機上每隔10分鐘執行一次mysqldump，並備份到本地磁盤和阿里雲OSS
mysql的備份方案還是比較簡單的，唯一要注意的是，從機啟動的時候並不會從主機拉取所有數據，所以需要停服先把主機的數據手動同步到從機，之後再啟動同步。
接下來，是redis的備份問題。
為了與mysql的備份時間一致，redis這邊改成了主機每10分鐘備份rdb文件一次。
但新方案運行了幾天之後，發現mysql經常會突然響應變慢。
後來發現因為備份腳本的邏輯是會先把rdb文件copy一份出來，而copy的目標位置和mysql使用的磁盤是同一個磁盤，所以導致磁盤IO上升，從而mysql變慢。
並且redis的bgsave每隔60秒運行一次，也是會對磁盤有大量的寫操作，不過目前看來影響不是特別大，因為數據量比較小。
所以我們開始考慮新的redis備份方案。
與mysql不同，redis從機在第一次啟動的時候會從主機全量同步一次數據。
所以我們想了幾套方案，我分別列一下。
redis主從熱備，從機進行冷備
這種方案其實是可以的，但是有幾個問題:
- 如果主機不關閉rdb保存就沒有問題，如果關閉了的話，那麼當主機不小心宕機重啟，那麼當主機redis啟動之後，會把從機redis的數據也抹掉。十分危險。
- 一旦從機服務器出問題，重新啟動後會從主機同步所有數據，導致主機bgsave運行，如果數據量很大，會導致主機內存狂飆，如果主機又忘記配置內存使用限制，就會是災難了。這在雲風的一篇文章中有寫: 談談陌陌爭霸在數據庫方面踩過的坑( Redis 篇)
所以後來，我決定選擇一個比較簡單的方案。
使用ssh將rdb文件傳輸到另一臺機器上，再進行冷備。
既然是因為磁盤寫IO增加導致問題，那麼我們就先規避掉這個問題好了。
至於，redis是否要做主從熱備的問題，暫時我們是還沒做的，等以後再說吧。
其實要不是之前有一次阿里雲服務器出現故障導致我們mysql全都用不了，我也不會狠下心半夜停服一個小時去調整備份方案。
正如前段時間被DDOS了，相關的抵禦優化才被提上日程一樣，無非時、勢二字。
閱讀更多 IT生涯 的文章
