redis主從切換導致的數(shù)據(jù)丟失與陷入只讀狀態(tài)故障解決方案

更新時間：2023年05月22日 08:16:24 作者：及時

這篇文章主要介紹了redis主從切換導致的數(shù)據(jù)丟失與陷入只讀狀態(tài)故障解決方案的相關資料,需要的朋友可以參考下

背景

最近一組業(yè)務redis數(shù)據(jù)不斷增長需要擴容內存，而擴容內存則需要重啟云主機，在按計劃擴容升級執(zhí)行主從切換時意外發(fā)生了數(shù)據(jù)丟失與master進入只讀狀態(tài)的故障，這里記錄分享一下。

業(yè)務redis高可用架構

該組業(yè)務redis使用的是一主一從，通過sentinel集群實現(xiàn)故障時的自動主從切換，這套架構已經平穩(wěn)運行數(shù)年，經歷住了多次實戰(zhàn)的考驗。

高可用架構大體如下圖所示:

簡單說一下sentinel實現(xiàn)高可用的原理：
集群的多個(2n+1,N>1)哨兵會定期輪詢redis的所有master/slave節(jié)點，如果sentinel集群中超過一半的哨兵判定redis某個節(jié)點已經主觀下線，就會將其判定為客觀下線進行相應處理：

如果下線節(jié)點是master，選定一個正常work的slave將其選定為新的master節(jié)點。
如果下線節(jié)點是slave，將其從slave節(jié)點中移除。

如果已經被客觀下線的節(jié)點恢復了正常，sentinel中超過一半哨兵確認后則將其加回可用的slave節(jié)點。
所有需要讀寫redis的server并不需要直接寫死redis 主從配置，而是通過訪問sentinel獲取當前redis的主從可用狀態(tài)，具體實現(xiàn)方式可以定時查詢sentinel詢問更新，也可以通過訂閱機制讓sentinel在主從變動時主動通知訂閱方更新。
sentinel實現(xiàn)高可用的詳細原理這里不做過多贅述，有興趣的小伙伴可以移步參考文獻中的相關資料。

具體內存擴容流程

sentinel可以在檢測到故障時自動切換redis主從，也可以主動執(zhí)行sentinel failover mastername 命令實現(xiàn)手動切換主從，所以這次的內存擴容重啟流程設計如下(A代表初始master所在云主機，B代表初始slave所在云主機)：

升級主機B內存配置，重啟主機B
檢查B重啟后其上的redis slave是否重新同步master數(shù)據(jù)完成，包括:
2.1 查看slave redis log是否異常，無異常pass
2.2 使用info keyspace命令check master、slave 各db key數(shù)量是否一致，無異常pass
2.3 在master寫入一個測試key，在slave上check是否同步成功
2.4 觀察依賴server log是否有異常
使用sentinel failover mastername命令手動主從切換，主機A變成新slave，主機B變成新master，根據(jù)以前手動切換的經驗走到這一步基本上就穩(wěn)了--因為這里本質上和一次普通主從切換已經沒有區(qū)別了。
升級主機A內存配置，重啟主機A，執(zhí)行以下check:
4.1 查看新slave redis log是否異常
4.2 使用info keyspace命令check 新master、新slave 各db key數(shù)量是否一致，無異常pass
4.3 在新master寫入測試key，在新slave上check是否同步成功
4.4 觀察依賴server log是否有異常

至此，若以上步驟都正常通過，一個完美的redis內存升級工作就完成了。

主從切換后數(shù)據(jù)丟失

結果正是沒有想過可能會出問題的步驟3反而出現(xiàn)了問題，直接導致了主從切換后丟掉了部分數(shù)據(jù)，并且新master進入只讀狀態(tài)將近十分鐘。

當時的情況是這樣的：

在執(zhí)行完步驟3后，check 新slave redis log無異常，正在考慮觀察一會兒后執(zhí)行主機A的升級重啟操作，api的分鐘級別異常監(jiān)控觸發(fā)了一小波redis相關報警。第一反應在新master與新slave上執(zhí)行了info keyspace查看key數(shù)量是否已經不一致，結果發(fā)現(xiàn)master/slave的key數(shù)量是一致的--但是再仔細一看：和切換前的key總數(shù)百萬級相比切換后key總數(shù)降到了十萬級--大部分key數(shù)據(jù)被丟失了。

查看新master、新slave log都沒有發(fā)現(xiàn)明顯log可以解釋為什么主從切換后會丟失一大半數(shù)據(jù)這一現(xiàn)象，這時小伙伴第一次提到了是不是內存不夠了，當時自己略一思考馬上回復到：新master剛升級了內存，不可能內容擴大后反而內存不足的，所以應該不是這個問題。

n分鐘后...

小伙伴再一次提出了是不是maxmemory問題，這一下子點中了關鍵點，馬上想到主機B升級了內存是不會有系統(tǒng)層面內存不足的問題，但是redis的內存使用實際上還會受到maxmemory參數(shù)限制，馬上在新master上執(zhí)行config get maxmemory, 只有3GB，而升級前數(shù)據(jù)實際使用內存超過了6GB！

立刻調大了新master的maxmemory參數(shù)，redis很快恢復了可讀寫正常狀態(tài)，一大波redis只讀引發(fā)的告警通知開始快速下降。

原因定位

緊張又刺激的故障處理就這么過去了，在優(yōu)先處理完丟失key數(shù)據(jù)恢復工作之后，開始回顧整理故障的詳細原因，總共有如下幾個疑問：

明確記得上個月給主機A、B上的redis都通過config set maxmemory設置為了7GB，為什么出現(xiàn)問題時查詢B上redis 的maxmemory配置卻變成了3GB？
如果主機B的maxmemory是3GB，其作為slave時為什么從master同步超過6GB的數(shù)據(jù)時不會有問題？--在主從切換前無論是查看info keyspace還是在master上寫入測試key同步check都是OK的。
為什么主從切換后主機B上的key數(shù)據(jù)會丟失？這個是因為maxmemory設置過小，是故障的直接原因。
為什么新master由于maxmemory參數(shù)超限進入只讀狀態(tài)且刪除部分數(shù)據(jù)后，新master中實際數(shù)據(jù)占用的大小依然超過>3GB?

如上四個疑問除了問題3已經明確了，剩下三個問題都讓人疑惑--事出詭異必有妖，經過一番探尋得出其答案：

上個月修改redis maxmemory時，只通過config set命令修改了其運行時配置，而沒有修改對應配置redis.conf上maxmemory的值，主機B上redis在重啟后就會從redis.conf上載入該maxmemory，該配置正是3GB，同時maxmemory參數(shù)是redis節(jié)點獨立的配置，slave并不會從master同步該值。
在redis5.0版本之后，redis引入了一個新的參數(shù)replica-ignore-maxmemory，其官方文檔定義如下：

Maxmemory on replicas
By default, a replica will ignore maxmemory (unless it is promoted to master after a failover or manually). It means that the eviction of keys will be handled by the master, sending the DEL commands to the replica as keys evict in the master side.
This behavior ensures that masters and replicas stay consistent, which is usually what you want. However, if your replica is writable, or you want the replica to have a different memory setting, and you are sure all the writes performed to the replica are idempotent, then you may change this default (but be sure to understand what you are doing).
Note that since the replica by default does not evict, it may end up using more memory than what is set via maxmemory (since there are certain buffers that may be larger on the replica, or data structures may sometimes take more memory and so forth). Make sure you monitor your replicas, and make sure they have enough memory to never hit a real out-of-memory condition before the master hits the configured maxmemory setting.
To change this behavior, you can allow a replica to not ignore the maxmemory. The configuration directives to use is:
replica-ignore-maxmemory no

大意是redis作為slave時默認會無視maxmemory參數(shù)，這樣可以保證主從的數(shù)據(jù)始終保持一致。當master/slave實際數(shù)據(jù)大小均小于其maxmemory設置時，這個參數(shù)沒有任何影響，而這次丟失數(shù)據(jù)的原因正是因為主機B重啟后作為slave時maxmemory(3GB)小于實際數(shù)據(jù)大小(6GB+)，此時replica-ignore-maxmemory 默認開啟保證作為slave時直接無視maxmemory的限制，而當執(zhí)行sentinel failover mastername將主機B切換為新master后，新master不會受replica-ignore-maxmemory影響，發(fā)現(xiàn)自身maxmemory<實際數(shù)據(jù)大小后直接開始主動淘汰key，從而導致了數(shù)據(jù)丟失。

4. 至于主機B作為master執(zhí)行淘汰key策略并最終進入只讀狀態(tài)后，其實際數(shù)據(jù)大小依然>3GB的原因，則是由于線上redis配置的策略是volatile-lru策略，該策略只會淘汰有過期時間的key，對于不過期的key是不淘汰的。