爆款云主机2核4G限时秒杀,88元/年起!
查看详情

活动

天翼云最新优惠活动,涵盖免费试用,产品折扣等,助您降本增效!
热门活动
  • 618智算钜惠季 爆款云主机2核4G限时秒杀,88元/年起!
  • 免费体验DeepSeek,上天翼云息壤 NEW 新老用户均可免费体验2500万Tokens,限时两周
  • 云上钜惠 HOT 爆款云主机全场特惠,更有万元锦鲤券等你来领!
  • 算力套餐 HOT 让算力触手可及
  • 天翼云脑AOne NEW 连接、保护、办公,All-in-One!
  • 中小企业应用上云专场 产品组合下单即享折上9折起,助力企业快速上云
  • 息壤高校钜惠活动 NEW 天翼云息壤杯高校AI大赛,数款产品享受线上订购超值特惠
  • 天翼云电脑专场 HOT 移动办公新选择,爆款4核8G畅享1年3.5折起,快来抢购!
  • 天翼云奖励推广计划 加入成为云推官,推荐新用户注册下单得现金奖励
免费活动
  • 免费试用中心 HOT 多款云产品免费试用,快来开启云上之旅
  • 天翼云用户体验官 NEW 您的洞察,重塑科技边界

智算服务

打造统一的产品能力,实现算网调度、训练推理、技术架构、资源管理一体化智算服务
智算云(DeepSeek专区)
科研助手
  • 算力商城
  • 应用商城
  • 开发机
  • 并行计算
算力互联调度平台
  • 应用市场
  • 算力市场
  • 算力调度推荐
一站式智算服务平台
  • 模型广场
  • 体验中心
  • 服务接入
智算一体机
  • 智算一体机
大模型
  • DeepSeek-R1-昇腾版(671B)
  • DeepSeek-R1-英伟达版(671B)
  • DeepSeek-V3-昇腾版(671B)
  • DeepSeek-R1-Distill-Llama-70B
  • DeepSeek-R1-Distill-Qwen-32B
  • Qwen2-72B-Instruct
  • StableDiffusion-V2.1
  • TeleChat-12B

应用商城

天翼云精选行业优秀合作伙伴及千余款商品,提供一站式云上应用服务
进入甄选商城进入云市场创新解决方案
办公协同
  • WPS云文档
  • 安全邮箱
  • EMM手机管家
  • 智能商业平台
财务管理
  • 工资条
  • 税务风控云
企业应用
  • 翼信息化运维服务
  • 翼视频云归档解决方案
工业能源
  • 智慧工厂_生产流程管理解决方案
  • 智慧工地
建站工具
  • SSL证书
  • 新域名服务
网络工具
  • 翼云加速
灾备迁移
  • 云管家2.0
  • 翼备份
资源管理
  • 全栈混合云敏捷版(软件)
  • 全栈混合云敏捷版(一体机)
行业应用
  • 翼电子教室
  • 翼智慧显示一体化解决方案

合作伙伴

天翼云携手合作伙伴,共创云上生态,合作共赢
天翼云生态合作中心
  • 天翼云生态合作中心
天翼云渠道合作伙伴
  • 天翼云代理渠道合作伙伴
天翼云服务合作伙伴
  • 天翼云集成商交付能力认证
天翼云应用合作伙伴
  • 天翼云云市场合作伙伴
  • 天翼云甄选商城合作伙伴
天翼云技术合作伙伴
  • 天翼云OpenAPI中心
  • 天翼云EasyCoding平台
天翼云培训认证
  • 天翼云学堂
  • 天翼云市场商学院
天翼云合作计划
  • 云汇计划
天翼云东升计划
  • 适配中心
  • 东升计划
  • 适配互认证

开发者

开发者相关功能入口汇聚
技术社区
  • 专栏文章
  • 互动问答
  • 技术视频
资源与工具
  • OpenAPI中心
开放能力
  • EasyCoding敏捷开发平台
培训与认证
  • 天翼云学堂
  • 天翼云认证
魔乐社区
  • 魔乐社区

支持与服务

为您提供全方位支持与服务,全流程技术保障,助您轻松上云,安全无忧
文档与工具
  • 文档中心
  • 新手上云
  • 自助服务
  • OpenAPI中心
定价
  • 价格计算器
  • 定价策略
基础服务
  • 售前咨询
  • 在线支持
  • 在线支持
  • 工单服务
  • 建议与反馈
  • 用户体验官
  • 服务保障
  • 客户公告
  • 会员中心
增值服务
  • 红心服务
  • 首保服务
  • 客户支持计划
  • 专家技术服务
  • 备案管家

了解天翼云

天翼云秉承央企使命,致力于成为数字经济主力军,投身科技强国伟大事业,为用户提供安全、普惠云服务
品牌介绍
  • 关于天翼云
  • 智算云
  • 天翼云4.0
  • 新闻资讯
  • 天翼云APP
基础设施
  • 全球基础设施
  • 信任中心
最佳实践
  • 精选案例
  • 超级探访
  • 云杂志
  • 分析师和白皮书
  • 天翼云·创新直播间
市场活动
  • 2025智能云生态大会
  • 2024智算云生态大会
  • 2023云生态大会
  • 2022云生态大会
  • 天翼云中国行
天翼云
  • 活动
  • 智算服务
  • 产品
  • 解决方案
  • 应用商城
  • 合作伙伴
  • 开发者
  • 支持与服务
  • 了解天翼云
      • 文档
      • 控制中心
      • 备案
      • 管理中心

      记录一次redis-cluster测试的反馈

      首页 知识中心 软件开发 文章详情页

      记录一次redis-cluster测试的反馈

      2024-06-12 09:24:21 阅读次数:54

      master,redis

      摘要:

       测试组上报没有按测试预期完成failover, 本文记录问题分析及解决过程。

      问题描述:

      集群描述:

      cluster集群: 4主4从

      测试组执行操作:

      1. 集群正确创建
      2. 172.16.0.12为master,  以下简称0.12
      3. 172.16.0.7是0.12节点的slave, 以下简称0.4
      4. 测试人员杀掉0.12的pod, 使0.12成为判定下线状态
      5. 测试人员启动0.12的pod,预期
      1. 0.7节点完成failover,成为master
      2. 0.12节点成为0.7节点的slave

      实际情况:

      1. 0.12节点依然为master
      2. 0.7节点依然为0.12节点的slave

      测试组认为该情况不符合预期,需要做出详细分析

      分析:

      分析思路:

      1. 要解释为什么和预期不符前, 需要对redis的cluster集群的failover过程有了解
      1. 哪些参数会导致哪些影响
      2. 在failover过程中, 集群的状态机是如何切换的
      3. failover的发生, 是否是不能回退的?
      1. 其次, 要认真分析日志,还原现场,了解cluster集群整体对failover的处理
      2. 从cluster集群对failover的处理入手,解释现象,透过现象看到本质

      nodes与ip映射表:

      a27e9975e23182d986d0e607124608e60cf7e34c 172.16.0.9:6379@16379 master - 0 1625036845000 3 connected 8192-1228711e6c61fb9c8f21a6173ff7b28db33fbf4076935 172.16.0.14:6379@16379 slave a27e9975e23182d986d0e607124608e60cf7e34c 0 1625036845000 8 connected2b61ab2d905bdf849053800ef1221c0d6908d421 172.16.0.8:6379@16379 master - 0 1625036847996 2 connected 4096-819111fd46e959051892a1c850ffa5e5360eec89b8ac 172.16.0.13:6379@16379 slave 2b61ab2d905bdf849053800ef1221c0d6908d421 0 1625036846993 7 connected2a97e5e42e5fe226b535d309630fd9b8dde86fb3 172.16.0.10:6379@16379 master - 0 1625036845000 4 connected 12288-163838d8e158ce96fe0527edff9681c52ca5859becfe9 172.16.0.7:6379@16379 myself,slave d6f53105af7ef908f67357b33b6fc16fdda3ff5d 0 1625036842000 1 connectedd6321b72076237d0d8f26f42e9e05692f0f8bbd2 172.16.0.11:6379@16379 slave 2a97e5e42e5fe226b535d309630fd9b8dde86fb3 0 1625036846000 5 connectedd6f53105af7ef908f67357b33b6fc16fdda3ff5d 172.16.0.12:6379@16379 master - 0 1625036847000 9 connected 0-4095

      分析:

      1. 8d8e158ce96fe0527edff9681c52ca5859becfe9 172.16.0.7:6379@16379 myself,slave d6f53105af7ef908f67357b33b6fc16fdda3ff5d 0 1625036842000 1 connected
      2. d6f53105af7ef908f67357b33b6fc16fdda3ff5d 172.16.0.12:6379@16379 master - 0 1625036847000 9 connected 0-4095

      172.16.0.12的日志, master

      29:C 29 Jun 2021 11:31:59.536 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo29:C 29 Jun 2021 11:31:59.536 # Redis version=5.0.12, bits=64, commit=00000000, modified=0, pid=29, just started29:C 29 Jun 2021 11:31:59.536 # Configuration loaded29:M 29 Jun 2021 11:31:59.536 * No cluster configuration found, I'm d6f53105af7ef908f67357b33b6fc16fdda3ff5d29:M 29 Jun 2021 11:31:59.537 * Running mode=cluster, port=6379.29:M 29 Jun 2021 11:31:59.537 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.29:M 29 Jun 2021 11:31:59.537 # Server initialized29:M 29 Jun 2021 11:31:59.537 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.29:M 29 Jun 2021 11:31:59.538 * Ready to accept connections29:M 29 Jun 2021 11:31:59.538 * The server is now ready to accept connections at redis.sock29:M 29 Jun 2021 11:33:57.217 # configEpoch set to 6 via CLUSTER SET-CONFIG-EPOCH29:M 29 Jun 2021 11:33:57.316 # IP address for this node updated to 172.16.0.1229:S 29 Jun 2021 11:33:59.224 * Before turning into a replica, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer.29:S 29 Jun 2021 11:33:59.224 # Cluster state changed: ok29:S 29 Jun 2021 11:33:59.826 * Connecting to MASTER 172.16.0.7:637929:S 29 Jun 2021 11:33:59.826 * MASTER <-> REPLICA sync started29:S 29 Jun 2021 11:33:59.826 * Non blocking connect for SYNC fired the event.29:S 29 Jun 2021 11:33:59.826 * Master replied to PING, replication can continue...29:S 29 Jun 2021 11:33:59.826 * Trying a partial resynchronization (request 4f8a9aac12f7c6543a1be464fe5f8064460fdbfc:1).29:S 29 Jun 2021 11:34:05.737 * Full resync from master: d32c2238eecf5bed700410eb6ffa292046ea786b:029:S 29 Jun 2021 11:34:05.737 * Discarding previously cached master state.29:S 29 Jun 2021 11:34:05.738 * MASTER <-> REPLICA sync: receiving streamed RDB from master29:S 29 Jun 2021 11:34:05.738 * MASTER <-> REPLICA sync: Flushing old data29:S 29 Jun 2021 11:34:05.738 * MASTER <-> REPLICA sync: Loading DB in memory29:S 29 Jun 2021 11:34:05.738 * MASTER <-> REPLICA sync: Finished with success29:S 29 Jun 2021 11:34:05.739 * Background append only file rewriting started by pid 5729:S 29 Jun 2021 11:34:05.761 * AOF rewrite child asks to stop sending diffs.57:C 29 Jun 2021 11:34:05.762 * Parent agreed to stop sending diffs. Finalizing AOF...57:C 29 Jun 2021 11:34:05.762 * Concatenating 0.00 MB of AOF diff received from parent.57:C 29 Jun 2021 11:34:05.762 * SYNC append only file rewrite performed57:C 29 Jun 2021 11:34:05.762 * AOF rewrite: 10 MB of memory used by copy-on-write29:S 29 Jun 2021 11:34:05.842 * Background AOF rewrite terminated with success29:S 29 Jun 2021 11:34:05.842 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)29:S 29 Jun 2021 11:34:05.842 * Background AOF rewrite finished successfully29:S 30 Jun 2021 03:42:44.846 # Connection with master lost.29:S 30 Jun 2021 03:42:44.846 * Caching the disconnected master state.29:S 30 Jun 2021 03:42:45.836 * Connecting to MASTER 172.16.0.7:637929:S 30 Jun 2021 03:42:45.837 * MASTER <-> REPLICA sync started29:S 30 Jun 2021 03:43:01.911 * FAIL message received from a27e9975e23182d986d0e607124608e60cf7e34c about 8d8e158ce96fe0527edff9681c52ca5859becfe929:S 30 Jun 2021 03:43:01.971 # Start of election delayed for 699 milliseconds (rank #0, offset 81172).29:S 30 Jun 2021 03:43:02.673 # Starting a failover election for epoch 9.29:S 30 Jun 2021 03:43:02.675 # Failover election won: I'm the new master.29:S 30 Jun 2021 03:43:02.675 # configEpoch set to 9 after successful failover29:M 30 Jun 2021 03:43:02.675 # Setting secondary replication ID to d32c2238eecf5bed700410eb6ffa292046ea786b, valid up to offset: 81173. New replication ID is fdfbea1397b6d1ca8585367ff20f5376fa65a6ca29:M 30 Jun 2021 03:43:02.675 * Discarding previously cached master state.29:M 30 Jun 2021 04:43:03.768 * Replication backlog freed after 3600 seconds without connected replicas.29:M 30 Jun 2021 05:54:27.941 * Clear FAIL state for node 8d8e158ce96fe0527edff9681c52ca5859becfe9: master without slots is reachable again.29:M 30 Jun 2021 05:54:28.879 * Replica 172.16.0.7:6379 asks for synchronization29:M 30 Jun 2021 05:54:28.879 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for '627e69dd4ff1a96ad775511f8befe17a3cf67918', my replication IDs are '7dda72b4574fb135e9921ad4c1dda9855e2fd4ee' and '0000000000000000000000000000000000000000')29:M 30 Jun 2021 05:54:28.879 * Delay next BGSAVE for diskless SYNC29:M 30 Jun 2021 05:54:34.361 * Starting BGSAVE for SYNC with target: replicas sockets29:M 30 Jun 2021 05:54:34.363 * Background RDB transfer started by pid 6969:C 30 Jun 2021 05:54:34.364 * RDB: 12 MB of memory used by copy-on-write29:M 30 Jun 2021 05:54:34.463 * Background RDB transfer terminated with success29:M 30 Jun 2021 05:54:34.463 # Slave 172.16.0.7:6379 correctly received the streamed RDB file.29:M 30 Jun 2021 05:54:34.463 * Streamed RDB transfer with replica 172.16.0.7:6379 succeeded (socket). Waiting for REPLCONF ACK from slave to enable streaming29:M 30 Jun 2021 05:54:34.890 * Synchronization with replica 172.16.0.7:6379 succeeded34:C 30 Jun 2021 06:38:11.580 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo34:C 30 Jun 2021 06:38:11.580 # Redis version=5.0.12, bits=64, commit=00000000, modified=0, pid=34, just started34:C 30 Jun 2021 06:38:11.580 # Configuration loaded34:M 30 Jun 2021 06:38:11.581 * Node configuration loaded, I'm d6f53105af7ef908f67357b33b6fc16fdda3ff5d34:M 30 Jun 2021 06:38:11.581 * Running mode=cluster, port=6379.34:M 30 Jun 2021 06:38:11.581 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.34:M 30 Jun 2021 06:38:11.581 # Server initialized34:M 30 Jun 2021 06:38:11.581 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.34:M 30 Jun 2021 06:38:11.582 * Reading RDB preamble from AOF file...34:M 30 Jun 2021 06:38:11.582 * Reading the remaining AOF tail...34:M 30 Jun 2021 06:38:11.582 * DB loaded from append only file: 0.000 seconds34:M 30 Jun 2021 06:38:11.582 * Ready to accept connections34:M 30 Jun 2021 06:38:11.582 * The server is now ready to accept connections at redis.sock34:M 30 Jun 2021 06:38:13.588 # Cluster state changed: ok34:M 30 Jun 2021 06:38:14.300 # Failover auth denied to 8d8e158ce96fe0527edff9681c52ca5859becfe9: its master is up34:M 30 Jun 2021 06:38:24.348 * Replica 172.16.0.7:6379 asks for synchronization34:M 30 Jun 2021 06:38:24.349 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for 'f692b1befe939778f81fc31ae6fe9dac461e91b7', my replication IDs are '4aaf5ab94b22f1cdb5678467c15f56f9c188cdcb' and '0000000000000000000000000000000000000000')34:M 30 Jun 2021 06:38:24.349 * Delay next BGSAVE for diskless SYNC34:M 30 Jun 2021 06:38:30.632 * Starting BGSAVE for SYNC with target: replicas sockets34:M 30 Jun 2021 06:38:30.633 * Background RDB transfer started by pid 5252:C 30 Jun 2021 06:38:30.635 * RDB: 10 MB of memory used by copy-on-write34:M 30 Jun 2021 06:38:30.733 * Background RDB transfer terminated with success34:M 30 Jun 2021 06:38:30.733 # Slave 172.16.0.7:6379 correctly received the streamed RDB file.34:M 30 Jun 2021 06:38:30.733 * Streamed RDB transfer with replica 172.16.0.7:6379 succeeded (socket). Waiting for REPLCONF ACK from slave to enable streaming34:M 30 Jun 2021 06:38:31.629 * Synchronization with replica 172.16.0.7:6379 succeeded

      分析:

      1. 0.12节点被启动了两次,  中间间隔了42分钟
      2. 0.12节点接受了0.7节点为其从节点
      1. 第一次启动后,执行全量复制
      2. 第二次启动后,执行pysnc的增量复制
      1. 0.12节点, 拒绝了id为 8d8e158ce96fe0527edff9681c52ca5859becfe9 的从节点的failover请求,原因是认为该从节点的主节点已经启动了
      1. 0.12作为master节点, 参与投票,详细结合下文分析

      172.16.0.7日志, slave

      29:C 30 Jun 2021 05:54:27.872 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo29:C 30 Jun 2021 05:54:27.872 # Redis version=5.0.12, bits=64, commit=00000000, modified=0, pid=29, just started29:C 30 Jun 2021 05:54:27.872 # Configuration loaded29:M 30 Jun 2021 05:54:27.873 * Node configuration loaded, I'm 8d8e158ce96fe0527edff9681c52ca5859becfe929:M 30 Jun 2021 05:54:27.873 * Running mode=cluster, port=6379.29:M 30 Jun 2021 05:54:27.873 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.29:M 30 Jun 2021 05:54:27.873 # Server initialized29:M 30 Jun 2021 05:54:27.873 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.29:M 30 Jun 2021 05:54:27.873 * Ready to accept connections29:M 30 Jun 2021 05:54:27.873 * The server is now ready to accept connections at redis.sock29:M 30 Jun 2021 05:54:27.876 # Configuration change detected. Reconfiguring myself as a replica of d6f53105af7ef908f67357b33b6fc16fdda3ff5d29:S 30 Jun 2021 05:54:27.876 * Before turning into a replica, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer.29:S 30 Jun 2021 05:54:27.876 # Cluster state changed: ok29:S 30 Jun 2021 05:54:28.878 * Connecting to MASTER 172.16.0.12:637929:S 30 Jun 2021 05:54:28.878 * MASTER <-> REPLICA sync started29:S 30 Jun 2021 05:54:28.878 * Non blocking connect for SYNC fired the event.29:S 30 Jun 2021 05:54:28.878 * Master replied to PING, replication can continue...29:S 30 Jun 2021 05:54:28.879 * Trying a partial resynchronization (request 627e69dd4ff1a96ad775511f8befe17a3cf67918:1).29:S 30 Jun 2021 05:54:34.362 * Full resync from master: f692b1befe939778f81fc31ae6fe9dac461e91b7:8117229:S 30 Jun 2021 05:54:34.362 * Discarding previously cached master state.29:S 30 Jun 2021 05:54:34.364 * MASTER <-> REPLICA sync: receiving streamed RDB from master29:S 30 Jun 2021 05:54:34.364 * MASTER <-> REPLICA sync: Flushing old data29:S 30 Jun 2021 05:54:34.364 * MASTER <-> REPLICA sync: Loading DB in memory29:S 30 Jun 2021 05:54:34.364 * MASTER <-> REPLICA sync: Finished with success29:S 30 Jun 2021 05:54:34.365 * Background append only file rewriting started by pid 5229:S 30 Jun 2021 05:54:34.387 * AOF rewrite child asks to stop sending diffs.52:C 30 Jun 2021 05:54:34.387 * Parent agreed to stop sending diffs. Finalizing AOF...52:C 30 Jun 2021 05:54:34.387 * Concatenating 0.00 MB of AOF diff received from parent.52:C 30 Jun 2021 05:54:34.387 * SYNC append only file rewrite performed52:C 30 Jun 2021 05:54:34.387 * AOF rewrite: 4 MB of memory used by copy-on-write29:S 30 Jun 2021 05:54:34.389 * Background AOF rewrite terminated with success29:S 30 Jun 2021 05:54:34.389 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)29:S 30 Jun 2021 05:54:34.389 * Background AOF rewrite finished successfully29:S 30 Jun 2021 06:37:51.817 # Connection with master lost.29:S 30 Jun 2021 06:37:51.818 * Caching the disconnected master state.29:S 30 Jun 2021 06:37:52.531 * Connecting to MASTER 172.16.0.12:637929:S 30 Jun 2021 06:37:52.531 * MASTER <-> REPLICA sync started29:S 30 Jun 2021 06:38:09.074 * Marking node d6f53105af7ef908f67357b33b6fc16fdda3ff5d as failing (quorum reached).29:S 30 Jun 2021 06:38:09.169 # Start of election delayed for 574 milliseconds (rank #0, offset 84798).29:S 30 Jun 2021 06:38:09.769 # Starting a failover election for epoch 10.29:S 30 Jun 2021 06:38:24.348 * Non blocking connect for SYNC fired the event.29:S 30 Jun 2021 06:38:24.348 * Master replied to PING, replication can continue...29:S 30 Jun 2021 06:38:24.348 * Trying a partial resynchronization (request f692b1befe939778f81fc31ae6fe9dac461e91b7:84799).29:S 30 Jun 2021 06:38:29.121 # Currently unable to failover: Waiting for votes, but majority still not reached.29:S 30 Jun 2021 06:38:30.632 * Full resync from master: 9e530414a7ef697d78daec46d5586640ef8e39c1:029:S 30 Jun 2021 06:38:30.632 * Discarding previously cached master state.29:S 30 Jun 2021 06:38:30.634 * MASTER <-> REPLICA sync: receiving streamed RDB from master29:S 30 Jun 2021 06:38:30.635 * MASTER <-> REPLICA sync: Flushing old data29:S 30 Jun 2021 06:38:30.635 * MASTER <-> REPLICA sync: Loading DB in memory29:S 30 Jun 2021 06:38:30.635 * MASTER <-> REPLICA sync: Finished with success29:S 30 Jun 2021 06:38:30.636 * Background append only file rewriting started by pid 164429:S 30 Jun 2021 06:38:30.658 * AOF rewrite child asks to stop sending diffs.1644:C 30 Jun 2021 06:38:30.658 * Parent agreed to stop sending diffs. Finalizing AOF...1644:C 30 Jun 2021 06:38:30.658 * Concatenating 0.00 MB of AOF diff received from parent.1644:C 30 Jun 2021 06:38:30.658 * SYNC append only file rewrite performed1644:C 30 Jun 2021 06:38:30.659 * AOF rewrite: 6 MB of memory used by copy-on-write29:S 30 Jun 2021 06:38:30.726 * Background AOF rewrite terminated with success29:S 30 Jun 2021 06:38:30.726 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)29:S 30 Jun 2021 06:38:30.727 * Background AOF rewrite finished successfully29:S 30 Jun 2021 06:38:39.746 # Currently unable to failover: Failover attempt expired.29:S 30 Jun 2021 06:38:42.053 * Clear FAIL state for node d6f53105af7ef908f67357b33b6fc16fdda3ff5d: is reachable again and nobody is serving its slots after some time.

      分析:

      1. 0.7节点为slave, 主从请求连接master0.12
      2. 0.7节点的日志中, 没有主节点0.12的错误日志
      3. 0.7节点主动两次连接master0.12
      1. 说明从节点0.7与主节点0.12的socket通信中间被中断过一次

      其他master节点作为Acceptor角色进行投票, 投票日志

      28:M 30 Jun 2021 05:54:31.796 * Clear FAIL state for node 8d8e158ce96fe0527edff9681c52ca5859becfe9: replica is reachable again.28:M 30 Jun 2021 06:38:09.770 # Failover auth denied to 8d8e158ce96fe0527edff9681c52ca5859becfe9: its master is up28:M 30 Jun 2021 06:38:11.080 * FAIL message received from 2b61ab2d905bdf849053800ef1221c0d6908d421 about d6f53105af7ef908f67357b33b6fc16fdda3ff5d28:M 30 Jun 2021 06:38:43.938 * Clear FAIL state for node d6f53105af7ef908f67357b33b6fc16fdda3ff5d: is reachable again and nobody is serving its slots after some time.

      分析:

      1. 节点  8d8e158ce96fe0527edff9681c52ca5859becfe9 的failover请求被拒绝,理由是该从节点的主节点又可用

      日志总结:

      1. 0.12节点被停止过一次,但是其从节点0.7的投票被Acceptor给拒绝了
      2. 原因在于0.12随后又上线

      代码分析:

      为了彻底搞明白这个原因,需要分析代码是如何处理的。

      cluster.c

      /* Vote for the node asking for our vote if there are the conditions. */void clusterSendFailoverAuthIfNeeded(clusterNode *node, clusterMsg *request) { clusterNode *master = node->slaveof; uint64_t requestCurrentEpoch = ntohu64(request->currentEpoch); uint64_t requestConfigEpoch = ntohu64(request->configEpoch); unsigned char *claimed_slots = request->myslots; int force_ack = request->mflags[0] & CLUSTERMSG_FLAG0_FORCEACK; int j; /* IF we are not a master serving at least 1 slot, we don't have the * right to vote, as the cluster size in Redis Cluster is the number * of masters serving at least one slot, and quorum is the cluster * size + 1 */ if (nodeIsSlave(myself) || myself->numslots == 0) return; /* Request epoch must be >= our currentEpoch. * Note that it is impossible for it to actually be greater since * our currentEpoch was updated as a side effect of receiving this * request, if the request epoch was greater. */ if (requestCurrentEpoch < server.cluster->currentEpoch) { serverLog(LL_WARNING, "Failover auth denied to %.40s: reqEpoch (%llu) < curEpoch(%llu)", node->name, (unsigned long long) requestCurrentEpoch, (unsigned long long) server.cluster->currentEpoch); return; } /* I already voted for this epoch? Return ASAP. */ if (server.cluster->lastVoteEpoch == server.cluster->currentEpoch) { serverLog(LL_WARNING, "Failover auth denied to %.40s: already voted for epoch %llu", node->name, (unsigned long long) server.cluster->currentEpoch); return; } /* Node must be a slave and its master down. * The master can be non failing if the request is flagged * with CLUSTERMSG_FLAG0_FORCEACK (manual failover). */ if (nodeIsMaster(node) || master == NULL || (!nodeFailed(master) && !force_ack)) { if (nodeIsMaster(node)) { serverLog(LL_WARNING, "Failover auth denied to %.40s: it is a master node", node->name); } else if (master == NULL) { serverLog(LL_WARNING, "Failover auth denied to %.40s: I don't know its master", node->name); } else if (!nodeFailed(master)) { serverLog(LL_WARNING, "Failover auth denied to %.40s: its master is up", node->name); } return; }

      分析:

      1. 可以看出, acceptor在做投票时候,都会根据现在与申请failover的从节点的主节点的存活关系,来作为判断
      2. 那么acceptor如何判定某个主节点已经fail呢?有以下流程:
      1. 与该节点通信超过  cluster-node-timeout 配置的时间,认为主动下线
      2. 经过过半数的master节点都认为主动下线后, 接受gossip协议的节点认定该节点为fail
      3. fail状态随gossip协议广播

      总结:

      1. 由以上问题可以看出, cluster集群做了措施来避免频繁的failover
      2. 需要谨慎的处理  cluster-node-timeout 的配置
      3. cluster集群的状态同步, 经过gossip协议需要一定的通信时间
      版权声明:本文内容来自第三方投稿或授权转载,原文地址:https://blog.51cto.com/adofsauron/5684167,作者:帝尊悟世,版权归原作者所有。本网站转在其作品的目的在于传递更多信息,不拥有版权,亦不承担相应法律责任。如因作品内容、版权等问题需要同本网站联系,请发邮件至ctyunbbs@chinatelecom.cn沟通。

      上一篇: Studio项目开发中的常见问题及解决方法

      下一篇:angular32-其他指令ng-checked

      相关文章

      2025-05-06 09:19:12

      redis高可用集群搭建

      redis高可用集群搭建

      2025-05-06 09:19:12
      master , redis , 服务器 , 节点 , 集群
      2025-04-22 09:27:37

      【Redis】浅析 Redis 事务

      【Redis】浅析 Redis 事务

      2025-04-22 09:27:37
      redis , Redis , 事务 , 命令 , 执行
      2025-04-09 09:13:17

      解决tomcat部署项目中碰到的几个问题

      在tomcat上部署项目并进行测试,经常会碰到各种问题。在不同的操作系统上部署,对问题的解决也会有一些差异。

      2025-04-09 09:13:17
      data , redis , tomcat , 信息
      2025-04-09 09:11:38

      redis配置参数详细说明

      redis配置参数详细说明

      2025-04-09 09:11:38
      conf , redis , server , 默认
      2025-03-26 09:31:37

      Redis的发布订阅(消息队列,比如ActiveMQ,一方得到数据后,多方得到信息)

      发布和订阅是进程间的一种消息通信模式:发送者(publisher)将消息发送给一个第三方,订阅者(subscriber)从第三方那里接收消息。

      2025-03-26 09:31:37
      redis
      2025-03-24 08:46:07

      idea2023的git从dev分支合并到主分支master

      idea2023的git从dev分支合并到主分支master

      2025-03-24 08:46:07
      dev , git , master , 分支 , 远程
      2025-03-18 08:27:10

      lepus监控redis执行python check_redis.py报错

      lepus监控redis执行python check_redis.py报错

      2025-03-18 08:27:10
      redis
      2025-03-17 07:49:59

      非openresty方式安装Nginx + Lua + Redis 环境

      非openresty方式安装Nginx + Lua + Redis 环境

      2025-03-17 07:49:59
      lua , nginx , Nginx , redis , 模块
      2025-03-17 07:49:59

      redis-cluster分布式集群安装部署

      redis-cluster分布式集群安装部署

      2025-03-17 07:49:59
      redis , Ruby , 安装 , 实例 , 集群
      2025-02-26 07:21:36

      简述Redis事务实现--------->负载均衡算法、类型

      MULTI命令的执行,标识着一个事务的开始。MULTI命令会将客户端状态的flag属性中打开REDIS_MULTI标识来完成的。

      2025-02-26 07:21:36
      redis , Redis , 事务 , 命令 , 客户端 , 服务器 , 节点
      查看更多
      推荐标签

      作者介绍

      天翼云小翼
      天翼云用户

      文章

      33561

      阅读量

      5250221

      查看更多

      最新文章

      【Redis】Redis 集群缓存测试要点--关于 线上 token 失效 BUG 的总结 --研读

      2025-02-11 09:36:37

      redis-benchchmark性能测试

      2024-11-26 09:46:16

      如何写一个属于自己的composer包

      2024-11-20 09:47:05

      【django项目开发】用户登录后缓存权限到redis中(十)

      2024-11-18 09:09:37

      快速入门 - Spring Boot 集成 Redis 配置及使用

      2024-09-25 10:15:32

      Python爬虫:网络信息爬取与处理知识梳理

      2024-06-24 08:38:15

      查看更多

      热门文章

      (五)高并发redis学习笔记:RDB和AOF两种持久性机制的介绍以及优缺点对比

      2023-06-07 07:30:42

      (七)高并发redis学习笔记:redis的AOF持久化机制深入理解以及数据恢复实验

      2023-06-07 07:30:42

      (八)高并发redis学习笔记:redis企业级数据备份方案是怎么样的?

      2023-06-07 07:30:42

      Python:使用 mysqlsmom 模块实时同步MySQL数据到ElasticSearch

      2023-03-16 07:45:26

      Python编程:Celery执行异步任务和定时任务

      2023-02-22 08:37:42

      Redisson中的“琐事”

      2023-06-12 09:25:54

      查看更多

      热门标签

      java Java python 编程开发 代码 开发语言 算法 线程 Python html 数组 C++ 元素 javascript c++
      查看更多

      相关产品

      弹性云主机

      随时自助获取、弹性伸缩的云服务器资源

      天翼云电脑(公众版)

      便捷、安全、高效的云电脑服务

      对象存储

      高品质、低成本的云上存储服务

      云硬盘

      为云上计算资源提供持久性块存储

      查看更多

      随机文章

      Python:Redis发布订阅模式

      SpringBoot-RabbitMQ消息的消费与签收机制

      高并发redis学习笔记:浅谈主从加哨兵模式下的数据丢失和脑裂问题

      Redis中集合set数据类型(增加(添加元素)、获取(获取所有元素)、删除(删除指定元素))

      用master-worker模型比对团队管理

      (十)高并发redis学习笔记:redis主从复制原理、断点续传、无磁盘化复制、过期key处理

      • 7*24小时售后
      • 无忧退款
      • 免费备案
      • 专家服务
      售前咨询热线
      400-810-9889转1
      关注天翼云
      • 旗舰店
      • 天翼云APP
      • 天翼云微信公众号
      服务与支持
      • 备案中心
      • 售前咨询
      • 智能客服
      • 自助服务
      • 工单管理
      • 客户公告
      • 涉诈举报
      账户管理
      • 管理中心
      • 订单管理
      • 余额管理
      • 发票管理
      • 充值汇款
      • 续费管理
      快速入口
      • 天翼云旗舰店
      • 文档中心
      • 最新活动
      • 免费试用
      • 信任中心
      • 天翼云学堂
      云网生态
      • 甄选商城
      • 渠道合作
      • 云市场合作
      了解天翼云
      • 关于天翼云
      • 天翼云APP
      • 服务案例
      • 新闻资讯
      • 联系我们
      热门产品
      • 云电脑
      • 弹性云主机
      • 云电脑政企版
      • 天翼云手机
      • 云数据库
      • 对象存储
      • 云硬盘
      • Web应用防火墙
      • 服务器安全卫士
      • CDN加速
      热门推荐
      • 云服务备份
      • 边缘安全加速平台
      • 全站加速
      • 安全加速
      • 云服务器
      • 云主机
      • 智能边缘云
      • 应用编排服务
      • 微服务引擎
      • 共享流量包
      更多推荐
      • web应用防火墙
      • 密钥管理
      • 等保咨询
      • 安全专区
      • 应用运维管理
      • 云日志服务
      • 文档数据库服务
      • 云搜索服务
      • 数据湖探索
      • 数据仓库服务
      友情链接
      • 中国电信集团
      • 189邮箱
      • 天翼企业云盘
      • 天翼云盘
      ©2025 天翼云科技有限公司版权所有 增值电信业务经营许可证A2.B1.B2-20090001
      公司地址:北京市东城区青龙胡同甲1号、3号2幢2层205-32室
      • 用户协议
      • 隐私政策
      • 个人信息保护
      • 法律声明
      备案 京公网安备11010802043424号 京ICP备 2021034386号