redis主从key数量不一致解惑2

实例基础信息:

redis版本:redis-cli 3.2.5
架构:传统主从架构

背景

好多天没有登陆某套redis主从进行查看了,某天redis磁盘容量报警,上去排查磁盘容量报警问题时偶然发现一个大问题,redis主库key数量与redis从库key数量差别非常大(db0 差5685023个),如图:


redis主从key数量不一致解惑2_第1张图片
WeChat_1522719374.jpeg

redis主从key数量不一致解惑2_第2张图片
WeChat_1522719328.jpeg

问题定位

  • 1)可能是过期key未及时删除导致主从key数量不一致,之前遇到过redis主从key数量不一致,以为是过期key造成的(请参考https://www.jianshu.com/writer#/notebooks/19390605/notes/20403782),于是对主库、从库分别进行了scan 0 count 1000000扫描清除过期但未被删除的key,清除完毕后主从对比,与截图相比差距基本类似,可以判断这次主从key数量不一致不是由于过期key造成的。
  • 2)可能是主从复制通道异常导致主从key数量不一致,info查看master、slave复制信息,发现复制通道是正常的,原因如下:
#主库端
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)可能是主从复制延迟导致主从key数量不一致,通过查看主从复制偏移量,发现复制偏移量基本正常,原因如下:
#主库端
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

#偏移量计算(复制偏移量仅仅差9630 byte,而实际的key差距是50多万,肯定不是这复制偏移量造成的)
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)这时没有思路了,就仔细看看主从各自info信息,这时候发现一个大问题,主从内存占用差距太大,信息如下:
#主库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

#主从内存不一样原因:redis之前内存硬件升级,没有更改从库的配置文件,后期从库重启过

思考

通过排查定位到造成主从key数量不一致的原因就是从库升级内存当时没有更改配置文件,从库数据超过了配置的内存,但是自己服务器配置的内存满后的策略是noeviction,表示满了以后不能继续往里面写入了,但是自己通过从库info replication发现从库的偏移量还是改变的,这说明从库还是继续写入的,为了证明这个想法,手动在主库设置了key,发现从库竟然同步过来了,这说明从库这时是能正常复制主库的更新的。

redis maxmemory-policy策略介绍

redis主从key数量不一致解惑2_第3张图片
A002817AC08654551D0CA4466C628B79.jpg

疑问

  • 为什么从库设置了maxmemory-policy noeviction参数后,从库内存满了仍能正常复制写入数据,按照maxmemory-policy介绍,此时从库的redis是不能写入数据了啊(这块自己还没有想明白)

总结(maxmemory-policy noeviction策略下)

  • redis 从库内存满了主从复制不会断开
  • redis 从库内存满了,数据会继续同步,偏移量会继续增长
  • maxmemory-policy noeviction策略对于主库生效,对于从库即使数据大于配置的内存,复制也能正常进行,数据能够正常同步(从库的key会根据某种策略自动删除)
  • redis主从监控目前只能做到复制通道是否正常,但是不能监控主从数据是否一致,即使偏移量相同也不能证明主从数据一致(从库的key有可能会自动删除了)

你可能感兴趣的:(redis主从key数量不一致解惑2)