使用info,cluster info, cluster nodes分析集群现状情况

场景一

集群状态正常情况

info

server服务器信息分析

  1. # Server
  2. redis_version:5.0.6                                #Redis 服务器版本
  3. redis_git_sha1:00000000
  4. redis_git_dirty:0
  5. redis_build_id:490893054031c673
  6. redis_mode:cluster
  7. os:Linux 3.10.0-957.10.1.el7.x86_64 x86_64         #服务器的宿主操作系统
  8. arch_bits:64
  9. multiplexing_api:epoll
  10. atomicvar_api:sync-builtin
  11. gcc_version:4.4.7                                  #编译 Redis 时所使用的 GCC 版本
  12. process_id:31                                      #服务器进程的 PID
  13. run_id:f3ce089ce47f1aa63f72ce2c30f6ba2216f5bbac
  14. tcp_port:7100                                      #监听端口
  15. uptime_in_seconds:179732                           #自 Redis 服务器启动以来，经过的秒数
  16. uptime_in_days:2                                   #自 Redis 服务器启动以来，经过的天数
  17. hz:10
  18. configured_hz:10
  19. lru_clock:10364264
  20. executable:/data/br/base/redis/redis-server
  21. config_file:/data/br/base/redis/redis7100.conf     #配置文件目录

注意：可以通过uptime_in_seconds和uptime_in_days参数来判断redis节点最近重启的时间

clients客户端信息分析

  1. # Clients
  2. connected_clients:2                  #已连接客户端的数量（不包括通过从属服务器连接的客户端）
  3. client_recent_max_input_buffer:2
  4. client_recent_max_output_buffer:0 
  5. blocked_clients:0                    #正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客户端的数量

memory内存信息分析

  1. # Memory
  2. used_memory:6373272                   #Redis分配的内存总量，即存储的所有数据占用的内存
  3. used_memory_human:6.08M               #以可读格式返回使用的内存量
  4. used_memory_rss:23040000              #从系统角度,显示Redis进程占用的物理内存总量
  5. used_memory_rss_human:21.97M          #以可读格式返回Redis进程占用的物理内存总量
  6. used_memory_peak:33476408             #内存使用的最大值，表示used_memory峰值
  7. used_memory_peak_human:31.93M         #以可读格式返回内存使用的最大值
  8. used_memory_peak_perc:19.04%          
  9. used_memory_overhead:6269550
  10. used_memory_startup:5104552
  11. used_memory_dataset:103722
  12. used_memory_dataset_perc:8.18%
  13. allocator_allocated:6654952
  14. allocator_active:7032832
  15. allocator_resident:14790656
  16. total_system_memory:8201052160       #系统总内存
  17. total_system_memory_human:7.64G      #以可读格式返回系统总内存
  18. used_memory_lua:37888                
  19. used_memory_lua_human:37.00K
  20. used_memory_scripts:0
  21. used_memory_scripts_human:0B
  22. number_of_cached_scripts:0
  23. maxmemory:4294967296
  24. maxmemory_human:4.00G                #Redis实例的最大内存配置
  25. maxmemory_policy:allkeys-lru         #内存淘汰策略
  26. allocator_frag_ratio:1.06
  27. allocator_frag_bytes:377880
  28. allocator_rss_ratio:2.10
  29. allocator_rss_bytes:7757824
  30. rss_overhead_ratio:1.56
  31. rss_overhead_bytes:8249344
  32. mem_fragmentation_ratio:3.66          #内存碎片率，等价于(used_memory_rss /used_memory)。由于Redis释放了内存块，但内存分配器并没有返回内存给操作系统
  33. mem_fragmentation_bytes:16749928
  34. mem_not_counted_for_evict:0
  35. mem_replication_backlog:1048576
  36. mem_clients_slaves:49694
  37. mem_clients_normal:66616
  38. mem_aof_buffer:0
  39. mem_allocator:jemalloc-5.1.0          #redis使用的内存分配器
  40. active_defrag_running:0
  41. lazyfree_pending_objects:0

注意：

在理想情况下， used_memory_rss 的值应该只比 used_memory 稍微高一点儿。当 rss > used ，且两者的值相差较大时，表示存在（内部或外部的）内存碎片。内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。当 used > rss 时，表示 Redis 的部分内存被操作系统换出到交换空间了，在这种情况下，操作可能会产生明显的延迟。当 Redis 释放内存时，分配器可能会，也可能不会，将内存返还给操作系统。

  1. # 开启自动清除垃圾碎片功能
  2. activedefrag yes

persistence持久化信息分析

  1. # Persistence
  2. loading:0                          #服务器是否正在载入持久化文件
  3. rdb_changes_since_last_save:0      #离最近一次成功生成rdb文件，写入命令的个数，即有多少个写入命令没有持久化
  4. rdb_bgsave_in_progress:0           #服务器是否正在创建rdb文件
  5. rdb_last_save_time:1637639613      #离最近一次成功创建rdb文件的时间戳。当前时间戳 - rdb_last_save_time=多少秒未成功生成rdb文件
  6. rdb_last_bgsave_status:ok          #最近一次rdb持久化是否成功
  7. rdb_last_bgsave_time_sec:0         #最近一次成功生成rdb文件耗时秒数
  8. rdb_current_bgsave_time_sec:-1
  9. rdb_last_cow_size:8839168
  10. aof_enabled:1                      #是否开启了aof
  11. aof_rewrite_in_progress:0
  12. aof_rewrite_scheduled:0
  13. aof_last_rewrite_time_sec:1        #最近一次aof rewrite耗费的时长
  14. aof_current_rewrite_time_sec:-1
  15. aof_last_bgrewrite_status:ok
  16. aof_last_write_status:ok
  17. aof_last_cow_size:46456832
  18. aof_current_size:16662731
  19. aof_base_size:16662731
  20. aof_pending_rewrite:0
  21. aof_buffer_length:0
  22. aof_rewrite_buffer_length:0
  23. aof_pending_bio_fsync:0
  24. aof_delayed_fsync:0

stats状态信息分析

  1. # Stats
  2. total_connections_received:1863           #连接过的客户端总数
  3. total_commands_processed:1625256          #处理过的命令总数
  4. instantaneous_ops_per_sec:0               #每秒处理的命令数     
  5. total_net_input_bytes:5994973921
  6. total_net_output_bytes:5994921934
  7. instantaneous_input_kbps:0.03
  8. instantaneous_output_kbps:0.01
  9. rejected_connections:0                    #由于 maxclients 限制而拒绝的连接数量
  10. sync_full:1
  11. sync_partial_ok:0
  12. sync_partial_err:1
  13. expired_keys:0                            #key 过期事件的总数
  14. expired_stale_perc:0.00
  15. expired_time_cap_reached_count:0
  16. evicted_keys:0                            #由于 maxmemory 限制，而被回收内存的 key 的总数
  17. keyspace_hits:1
  18. keyspace_misses:0
  19. pubsub_channels:0
  20. pubsub_patterns:0
  21. latest_fork_usec:4114
  22. migrate_cached_sockets:0
  23. slave_expires_tracked_keys:0
  24. active_defrag_hits:0
  25. active_defrag_misses:0
  26. active_defrag_key_hits:0
  27. active_defrag_key_misses:0

注意：

total_connections_received 和 total_commands_processed 反映了 Redis 服务器自从启动以来，所有处理过的连接数和命令数。instantaneous_ops_per_sec 反应了 Redis 服务器的忙碌状态。当 rejected_connections 的值不为 0 时，说明应用的连接数过多， 或者 maxclients 配置的太小。

Redis 中的存放和访问情况了。如果 key 在明确的时间周期内被使用，或者旧的 key 将来可能不会被使用，就可以用 Redis 过期时间命令(expire,expireat, pexpire, pexpireat 等)去设置过期时间，这样 Redis 就会在 key 过期时自动删除 key，这个信息可以通过expired_keys 去查看。当内存使用达到设置的最大阀值 maxmemory 时，Redis 则会根据设置的 key 逐出策略，淘汰 Redis 中存储的数据，这个信息可以根据 evicted_keys 查看。

replication复制信息分析

  1. # Replication
  2. role:master                                  #实例的角色，是master or slave
  3. connected_slaves:1                           #连接的slave实例个数
  4. slave0:ip=10.241.90.22,port=7200,state=online,offset=5987607162,lag=0
  5. master_replid:94ff75556908ad4786afaddeced3d328f3100911
  6. master_replid2:0000000000000000000000000000000000000000
  7. master_repl_offset:5987607162        #主从同步偏移量,此值如果和上面的offset相同说明主从一致没延迟，与master_replid可被用来标识主实例复制流中的位置。        
  8. second_repl_offset:-1
  9. repl_backlog_active:1
  10. repl_backlog_size:1048576
  11. repl_backlog_first_byte_offset:5986558587
  12. repl_backlog_histlen:1048576

其他模块分析

  1. # CPU
  2. used_cpu_sys:436.733866
  3. used_cpu_user:323.262940
  4. used_cpu_sys_children:13.425409
  5. used_cpu_user_children:2.855241
  7. # Cluster
  8. cluster_enabled:1                         #集群功能是否已经开启
  10. # Keyspace
  11. db0:keys=2,expires=0,avg_ttl=0             #数据库相关的统计信息

cluster nodes

  1. 127.0.0.1:7100> cluster nodes
  2. cc5f16e884261f91d198bc7d88fb5a6065248d8a 10.241.90.22:7200@17200 slave c470ec92c72267b60a3b362845b6f6f54c7b190b 0 1642416719551 4 connected
  3. 260205918b2c1cbb26e3dbf68c9ae6062a89f999 10.241.90.2:7200@17200 slave 3b6d2678635dae7c186e8a1f2870510ff8ec936a 0 1642416718545 5 connected
  4. 3b6d2678635dae7c186e8a1f2870510ff8ec936a 10.241.40.2:7100@17100 master - 0 1642416718000 5 connected 10923-16383
  5. 1dd4d6d5bedb748093c0af5d44dc9da276a3965e 10.241.40.2:7200@17200 slave 90841afd83baeac3447265ed591ff3f14a90fbeb 0 1642416717542 6 connected
  6. 90841afd83baeac3447265ed591ff3f14a90fbeb 10.241.90.22:7100@17100 master - 0 1642416716538 3 connected 5461-10922
  7. c470ec92c72267b60a3b362845b6f6f54c7b190b 10.241.90.2:7100@17100 myself,master - 0 1642416713000 1 connected 0-5460

分析：

从命令结果可以看出集群的节点信息，connected表示集群是连接的状态，master是主节点，slave是从节点，myself是当前连接的节点，可以通过slave后面的id来对应master最前面的id来确定哪个节点是哪个主节点的从。

cluster info

  1. 127.0.0.1:7100> cluster info
  2. cluster_state:ok                       #ok状态表示集群可以正常接受查询请求。fail 状态表示，至少有一个哈希槽没有被绑定
  3. cluster_slots_assigned:16384           #已分配到集群节点的哈希槽数量，16384个哈希槽全部被分配到集群节点是集群正常运行的必要条件.
  4. cluster_slots_ok:16384                 #哈希槽状态不是FAIL 和 PFAIL 的数量 
  5. cluster_slots_pfail:0                  #哈希槽状态是 PFAIL的数量。只要哈希槽状态没有被升级到FAIL状态，这些哈希槽仍然可以被正常处理。PFAIL状态表示我们当前不能和节点进行交互，但这种状态只是临时的错误状态
  6. cluster_slots_fail:0                   #哈希槽状态是FAIL的数量。如果值不是0，那么集群节点将无法提供查询服务，除非cluster-require-full-coverage被设置为no
  7. cluster_known_nodes:6                  #集群中节点数量，包括处于握手状态还没有成为集群正式成员的节点 
  8. cluster_size:3                         #至少包含一个哈希槽且能够提供服务的master节点数量
  9. cluster_current_epoch:6                #集群本地Current Epoch变量的值 
  10. cluster_my_epoch:1                     #当前正在使用的节点的Config Epoch值 
  11. cluster_stats_messages_ping_sent:340   
  12. cluster_stats_messages_pong_sent:359
  13. cluster_stats_messages_sent:699        #通过node-to-node二进制总线发送的消息数量.
  14. cluster_stats_messages_ping_received:354
  15. cluster_stats_messages_pong_received:340
  16. cluster_stats_messages_meet_received:5
  17. cluster_stats_messages_received:699    #通过node-to-node二进制总线接收的消息数量.

场景二

停掉一个从节点情况下，集群状态分析

cluster nodes

  1. 127.0.0.1:7100> cluster nodes
  2. cc5f16e884261f91d198bc7d88fb5a6065248d8a 10.241.90.22:7200@17200 slave c470ec92c72267b60a3b362845b6f6f54c7b190b 1642417697044 1642417695000 4 disconnected
  3. 260205918b2c1cbb26e3dbf68c9ae6062a89f999 10.241.90.2:7200@17200 slave 3b6d2678635dae7c186e8a1f2870510ff8ec936a 0 1642417723537 5 connected
  4. 3b6d2678635dae7c186e8a1f2870510ff8ec936a 10.241.40.2:7100@17100 master - 0 1642417722530 5 connected 10923-16383
  5. 1dd4d6d5bedb748093c0af5d44dc9da276a3965e 10.241.40.2:7200@17200 slave 90841afd83baeac3447265ed591ff3f14a90fbeb 0 1642417719510 6 connected
  6. 90841afd83baeac3447265ed591ff3f14a90fbeb 10.241.90.22:7100@17100 master - 0 1642417721522 3 connected 5461-10922
  7. c470ec92c72267b60a3b362845b6f6f54c7b190b 10.241.90.2:7100@17100 myself,master - 0 1642417717000 1 connected 0-5460

分析：通过cluster nodes命令可以看到从节点10.241.90.22:7200变成了disconnected

cluster info

  1. 127.0.0.1:7100> cluster info
  2. cluster_state:ok
  3. cluster_slots_assigned:16384
  4. cluster_slots_ok:16384
  5. cluster_slots_pfail:0
  6. cluster_slots_fail:0
  7. cluster_known_nodes:6
  8. cluster_size:3
  9. cluster_current_epoch:6
  10. cluster_my_epoch:1
  11. cluster_stats_messages_ping_sent:2409
  12. cluster_stats_messages_pong_sent:1179
  13. cluster_stats_messages_sent:3588
  14. cluster_stats_messages_ping_received:1174
  15. cluster_stats_messages_pong_received:1138
  16. cluster_stats_messages_meet_received:5
  17. cluster_stats_messages_received:2317

分析：通过cluster info可以看到集群状态还是OK的状态，表示集群依然可用

场景三

停掉一个从节点情况下，集群状态分析

在停止一个主几点之前，查询key zhuting可以正常查询到它的值，zhuting这个key所在的节点是10.241.90.22:7100。

  1. 10.241.40.2:7100> get zhuting
  2. -> Redirected to slot [8894] located at 10.241.90.22:7100
  3. "123"

现在将这个key所在的主节点10.241.90.22:7100停止

cluster nodes

  1. 90841afd83baeac3447265ed591ff3f14a90fbeb 10.241.90.22:7100@17100 master - 1642418404759 1642418402652 3 disconnected
  2. 3b6d2678635dae7c186e8a1f2870510ff8ec936a 10.241.40.2:7100@17100 master - 0 1642418738735 5 connected 10923-16383
  3. 260205918b2c1cbb26e3dbf68c9ae6062a89f999 10.241.90.2:7200@17200 slave 3b6d2678635dae7c186e8a1f2870510ff8ec936a 0 1642418738000 5 connected
  4. 1dd4d6d5bedb748093c0af5d44dc9da276a3965e 10.241.40.2:7200@17200 myself,master - 0 1642418735000 7 connected 5461-10922
  5. cc5f16e884261f91d198bc7d88fb5a6065248d8a 10.241.90.22:7200@17200 slave c470ec92c72267b60a3b362845b6f6f54c7b190b 0 1642418737000 4 connected
  6. c470ec92c72267b60a3b362845b6f6f54c7b190b 10.241.90.2:7100@17100 master - 0 1642418736723 1 connected 0-5460

分析：通过cluster nodes命令可以看到主节点10.241.90.22:7100变成了disconnected，但是由于故障转移，它的从节点10.241.40.2:7200变成了master状态

cluster info

  1. 127.0.0.1:7100> cluster info
  2. cluster_state:ok
  3. cluster_slots_assigned:16384
  4. cluster_slots_ok:16384
  5. cluster_slots_pfail:0
  6. cluster_slots_fail:0
  7. cluster_known_nodes:6
  8. cluster_size:3
  9. cluster_current_epoch:6
  10. cluster_my_epoch:1
  11. cluster_stats_messages_ping_sent:7894
  12. cluster_stats_messages_pong_sent:1841
  13. cluster_stats_messages_sent:9735
  14. cluster_stats_messages_ping_received:1836
  15. cluster_stats_messages_pong_received:1817
  16. cluster_stats_messages_meet_received:5
  17. cluster_stats_messages_received:3658

分析：通过cluster info可以看到集群状态还是OK的状态，表示集群依然可用

  1. 127.0.0.1:7100> get zhuting
  2. -> Redirected to slot [8894] located at 10.241.40.2:7200
  3. "123"
  4. 10.241.40.2:7200>

再次获取键zhuting的值，能够正常获取到

场景四

停掉一对主从节点情况下，集群状态分析

将一对主从节点10.241.90.22:7100和10.241.40.2:7200都停止

cluster nodes

  1. 127.0.0.1:7100> cluster nodes
  2. cc5f16e884261f91d198bc7d88fb5a6065248d8a 10.241.90.22:7200@17200 slave c470ec92c72267b60a3b362845b6f6f54c7b190b 0 1642420651000 4 connected
  3. 260205918b2c1cbb26e3dbf68c9ae6062a89f999 10.241.90.2:7200@17200 slave 3b6d2678635dae7c186e8a1f2870510ff8ec936a 0 1642420652984 5 connected
  4. 3b6d2678635dae7c186e8a1f2870510ff8ec936a 10.241.40.2:7100@17100 master - 0 1642420653994 5 connected 10923-16383
  5. 1dd4d6d5bedb748093c0af5d44dc9da276a3965e 10.241.40.2:7200@17200 master - 1642420560981 1642420556970 7 disconnected 5461-10922
  6. 90841afd83baeac3447265ed591ff3f14a90fbeb 10.241.90.22:7100@17100 master,fail - 1642418431382 1642418429076 3 disconnected
  7. c470ec92c72267b60a3b362845b6f6f54c7b190b 10.241.90.2:7100@17100 myself,master - 0 1642420650000 1 connected 0-5460

分析：通过cluster nodes命令可以看到一对主从节点10.241.90.22:7100和10.241.40.2:7200都变成了disconnected

cluster info

  1. 127.0.0.1:7100> cluster info
  2. cluster_state:ok
  3. cluster_slots_assigned:16384
  4. cluster_slots_ok:16384
  5. cluster_slots_pfail:0
  6. cluster_slots_fail:0
  7. cluster_known_nodes:6
  8. cluster_size:3
  9. cluster_current_epoch:7
  10. cluster_my_epoch:1
  11. cluster_stats_messages_ping_sent:34572
  12. cluster_stats_messages_pong_sent:4023
  13. cluster_stats_messages_fail_sent:4
  14. cluster_stats_messages_auth-ack_sent:1
  15. cluster_stats_messages_sent:38600
  16. cluster_stats_messages_ping_received:4018
  17. cluster_stats_messages_pong_received:4027
  18. cluster_stats_messages_meet_received:5
  19. cluster_stats_messages_fail_received:1
  20. cluster_stats_messages_auth-req_received:1
  21. cluster_stats_messages_received:8052

分析：通过cluster info可以看到集群状态还是OK的状态，表示集群依然可用

  1. 127.0.0.1:7100> get zhuting
  2. -> Redirected to slot [8894] located at 10.241.40.2:7200
  3. Could not connect to Redis at 10.241.40.2:7200: Connection refused
  4. Could not connect to Redis at 10.241.40.2:7200: Connection refused

再次获取键zhuting的值，已经不能正常获取到值了

  1. [BONREE bonree@stresskafka01:/data/br/base/redis]$ redis-cli -p 7100 -a Bonree@365 -c
  2. Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
  3. 127.0.0.1:7100> set zhuting1 123
  4. OK
  5. 127.0.0.1:7100> get zhuting1
  6. "123"

可以正常创建新的key和读取不在挂掉那对主从所在槽位的key