實例基礎(chǔ)信息：
redis版本：redis-cli 3.2.5
架構(gòu)：傳統(tǒng)主從架構(gòu)
背景
好多天沒有登陸某套redis主從進(jìn)行查看了离陶，某天redis磁盤容量報警见秤，上去排查磁盤容量報警問題時偶然發(fā)現(xiàn)一個大問題琅坡，redis主庫key數(shù)量與redis從庫key數(shù)量差別非常大(db0 差5685023個)为流，如圖：
WeChat_1522719374.jpeg
WeChat_1522719328.jpeg
問題定位
- 1）可能是過期key未及時刪除導(dǎo)致主從key數(shù)量不一致畏邢，之前遇到過redis主從key數(shù)量不一致慈缔，以為是過期key造成的（請參考http://www.reibang.com/writer#/notebooks/19390605/notes/20403782）袱衷，于是對主庫捎废、從庫分別進(jìn)行了scan 0 count 1000000掃描清除過期但未被刪除的key，清除完畢后主從對比致燥，與截圖相比差距基本類似登疗，可以判斷這次主從key數(shù)量不一致不是由于過期key造成的。
- 2）可能是主從復(fù)制通道異常導(dǎo)致主從key數(shù)量不一致嫌蚤，info查看master辐益、slave復(fù)制信息，發(fā)現(xiàn)復(fù)制通道是正常的脱吱，原因如下：
#主庫端
role:master
connected_slaves:1
slave0:ip=192.168.26.22,port=6379,state=online,offset=297300434582,lag=0
# 從庫端
role:slave
master_host:192.168.26.21
master_port:6379
master_link_status:up
- 3）可能是主從復(fù)制延遲導(dǎo)致主從key數(shù)量不一致智政，通過查看主從復(fù)制偏移量，發(fā)現(xiàn)復(fù)制偏移量基本正常箱蝠，原因如下：
#主庫端
role:master
connected_slaves:1
slave0:ip=192.168.26.22,port=6379,state=online,offset=297614050284,lag=0
master_repl_offset:297614059914
repl_backlog_active:1
repl_backlog_size:104857600
repl_backlog_first_byte_offset:297509202315
repl_backlog_histlen:104857600
#偏移量計算（復(fù)制偏移量僅僅差9630 byte,而實際的key差距是50多萬续捂，肯定不是這復(fù)制偏移量造成的）
MariaDB [(none)]> select 297614059914 -297614050284;
+----------------------------+
| 297614059914 -297614050284 |
+----------------------------+
| 9630 |
+----------------------------+
#從庫端
# Replication
role:slave
master_host:192.168.26.21
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:297610328994
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:104857600
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
- 4）這時沒有思路了，就仔細(xì)看看主從各自info信息抡锈，這時候發(fā)現(xiàn)一個大問題疾忍，主從內(nèi)存占用差距太大，信息如下：
#主庫Memory
used_memory:7783990712
used_memory_human:7.25G
used_memory_rss:8958046208
used_memory_rss_human:8.34G
used_memory_peak:7855643336
used_memory_peak_human:7.32G
total_system_memory:16827678720
total_system_memory_human:15.67G
used_memory_lua:37888
used_memory_lua_human:37.00K
maxmemory:10737418240
maxmemory_human:10.00G
maxmemory_policy:noeviction
mem_fragmentation_ratio:1.15
mem_allocator:jemalloc-4.0.3
#從庫Memory
used_memory:1073784176
used_memory_human:1.00G
used_memory_rss:1381617664
used_memory_rss_human:1.29G
used_memory_peak:1090530808
used_memory_peak_human:1.02G
total_system_memory:16827678720
total_system_memory_human:15.67G
used_memory_lua:37888
used_memory_lua_human:37.00K
maxmemory:1073741824
maxmemory_human:1.00G
maxmemory_policy:noeviction
mem_fragmentation_ratio:1.29
mem_allocator:jemalloc-4.0.3
查看主從配置文件信息如下：
#主庫
maxmemory 10gb
maxclients 40000
maxmemory-policy noeviction
#從庫
maxmemory 1gb
maxclients 40000
maxmemory-policy noeviction
#主從內(nèi)存不一樣原因：redis之前內(nèi)存硬件升級床三，沒有更改從庫的配置文件一罩，后期從庫重啟過
思考
通過排查定位到造成主從key數(shù)量不一致的原因就是從庫升級內(nèi)存當(dāng)時沒有更改配置文件，從庫數(shù)據(jù)超過了配置的內(nèi)存撇簿，但是自己服務(wù)器配置的內(nèi)存滿后的策略是noeviction聂渊，表示滿了以后不能繼續(xù)往里面寫入了差购，但是自己通過從庫info replication發(fā)現(xiàn)從庫的偏移量還是改變的，這說明從庫還是繼續(xù)寫入的汉嗽，為了證明這個想法欲逃，手動在主庫設(shè)置了key，發(fā)現(xiàn)從庫竟然同步過來了饼暑，這說明從庫這時是能正常復(fù)制主庫的更新的稳析。
redis maxmemory-policy策略介紹
A002817AC08654551D0CA4466C628B79.jpg
疑問
- 為什么從庫設(shè)置了maxmemory-policy noeviction參數(shù)后，從庫內(nèi)存滿了仍能正常復(fù)制寫入數(shù)據(jù)弓叛，按照maxmemory-policy介紹彰居，此時從庫的redis是不能寫入數(shù)據(jù)了啊（這塊自己還沒有想明白）
總結(jié)（maxmemory-policy noeviction策略下）
- redis 從庫內(nèi)存滿了主從復(fù)制不會斷開
- redis 從庫內(nèi)存滿了撰筷，數(shù)據(jù)會繼續(xù)同步陈惰，偏移量會繼續(xù)增長
- maxmemory-policy noeviction策略對于主庫生效，對于從庫即使數(shù)據(jù)大于配置的內(nèi)存毕籽，復(fù)制也能正常進(jìn)行抬闯，數(shù)據(jù)能夠正常同步（從庫的key會根據(jù)某種策略自動刪除）
- redis主從監(jiān)控目前只能做到復(fù)制通道是否正常，但是不能監(jiān)控主從數(shù)據(jù)是否一致关筒，即使偏移量相同也不能證明主從數(shù)據(jù)一致（從庫的key有可能會自動刪除了）
