详细分析复述,集群故障

  

<>强故障表象:
  

  

业务层面显示提示查询复述,失败
  

  

<强>集群组成:
  

  

3主3从,每个节点的数据有8 gb
  

  

<>强机器分布:
  

  

在同一个机架中,
  

  

xx.x.xxx。199年
  xx.x.xxx。200年
  xx.x.xxx。201年
  

  

<强> redis-server进程状态:
  

  

通过命令ps eo pid, lstart | grep $ pid,
  

  

发现进程已经持续运行了3个月
  

  

<>强发生故障前集群的节点状态:
  

  

xx.x.xxx.200:8371 (bedab2c537fe94f8c0363ac4ae97d56832316e65)主
  xx.x.xxx.199:8373 (792020 fe66c00ae56e27cd7a048ba6bb2b67adb6)奴隶
  xx.x.xxx.201:8375 (5 ab4f85306da6d633e4834b4d3327f45af02171b)主
  xx.x.xxx.201:8372 (826607654 f5ec81c3756a4a21f357e644efe605a)奴隶
  xx.x.xxx.199:8370 (462 cadcb41e635d460425430d318f2fe464665c5)主
  xx.x.xxx.200:8374 (1238085 b578390f3c8efa30824fd9a4baba10ddf)奴隶
  

  

<强> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -下面是日志分析- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  

  

<强>第1步:
  强主节点8371失去和从节点8373的连接:
  46590:09年9月与奴隶xx.x.xxx 18:57:51.379 #联系。199:8373丢失。
  

  

<强>第2步:
  主节点8370/8375判定8371失联:
  42645:09年9月18:57:50.117 *将节点bedab2c537fe94f8c0363ac4ae97d56832316e65标记为失败(法定人数达到)。
  

  

<强>第三步:
  强从节点8372/8373/8374收到主节点8375说8371失联:
  46986:09年9月18:57:50.120 *失败消息收到5 ab4f85306da6d633e4834b4d3327f45af02171b关于bedab2c537fe94f8c0363ac4ae97d56832316e65
  

  

<强>第四步:
  主节点8370/8375授权8373升级为主节点转移:
  42645:09年9月18:57:51.055 #故障转移auth授予792020 fe66c00ae56e27cd7a048ba6bb2b67adb6时代16
  

  

<强>第五步:
  8371年原主节点修改自己的配置,成为8373的从节点:
  46590:09年9月18:57:51.488 #配置更改。重新配置自己的复制品792020 fe66c00ae56e27cd7a048ba6bb2b67adb6
  

  

<强>第六步:
  8371年主节点8370/8375/8373明确失败状态:
  42645:09年9月18:57:51.522 *清楚失败状态节点bedab2c537fe94f8c0363ac4ae97d56832316e65:主无槽可再次连接。
  

  

<强>第七步:
  新从节点8371年开始从新主节点8373年第一次全量同步数据:
  8373日志::
  4255:09年9月18:57:51.906 xx.x.xxx *完整的同步要求的奴隶。200:8371
  4255:09年9月18:57:51.906 *起始BGSAVE与目标:同步磁盘
  4255:09年9月18:57:51.941 *背景储蓄由pid 5230
  8371日志::
  46590:09年9月18:57:51.948 *全部重新同步主:d7751c4ebf1e63d3baebea1ed409e0e7243a4423:440721826993
  

  

<强>第八步:
  主节点8370/8375判定8373(新主)失联:
  42645:09年9月18:58:00.320 *将节点792020 fe66c00ae56e27cd7a048ba6bb2b67adb6标记为失败(法定人数达到)。
  

  

<强>步9:
  主节点8370/8375判定8373(新主)恢复:
  60295:09年9月18:58:18.181 *清楚失败状态节点792020 fe66c00ae56e27cd7a048ba6bb2b67adb6:又是可访问的,一段时间后没有人服务于槽。
  

  

<强>步10:
  强主节点8373完成全量同步所需要的BGSAVE操作:
  5230:C 09年9月18:59:01.474 * DB保存>   #每个client-output-buffer-limit指令的语法如下:   #   # client-output-buffer-limit & lt; class>& lt;硬limit>& lt;软limit>& lt;软seconds>   #   #客户立即断开一次硬限制,或者   #达到软限制,达到指定的数量   #秒(不断)。   #例如如果硬限制是32字节和软限制   # 16 mb/10秒,客户会马上断开连接   #如果输出缓冲区的大小达到32字节,但也会得到   #如果客户机断开达到16字节,不断克服   # 10秒的限制。   #   #默认正常客户并不局限,因为他们不接收数据   #没有要求(推的方式),但只是一个请求后,所以只有   #异步客户可能会创建一个场景,数据请求更快   #比它可以阅读。   #   #而不是有一个默认限制pubsub和奴隶的客户,   #订阅者和奴隶推的方式接收数据。   #   #硬或软限制都可以禁用通过设置为零。   client-output-buffer-limit正常0 0 0   client-output-buffer-limit奴隶256 mb 60 64 mb   client-output-buffer-limit pubsub 32 mb 8 mb 60

详细分析复述,集群故障