文章目录redis 集群3 主 3 从核心概念基本定义关键角色核心特性工作原理数据分片哈希槽机制节点通信Gossip 协议请求路由流程故障转移高可用数据一致性使用场景海量数据存储100GB高并发读写QPS ≥ 5 万强事务、多键跨槽操作如 MSET 多键不同槽。- 数据量小、低并发哨兵/主从更简单。操作步骤3 主 3 从实战架构cluster 集群是 Redis 从 3.0 版本开始支持自带的一种集群方式。它的原理使用了分布的思想其数据会均分到所有的主节点上。此部署方式当数据量过大时会让服务器均摊压力。在各个主节点上分配的数据都不是全量的。是分片存储的。目前此种部署方式在生产环境的较多。至少六台三台主三台从。配置查看集群状态创建数据模拟故障查看节点信息完整过程恢复集群监控redis 集群3 主 3 从Redis 集群Cluster是 Redis 3.0 官方推出的分布式解决方案核心是数据分片Sharding 主从复制 去中心化故障转移解决单机 Redis 的容量、性能、单点故障瓶颈实现水平扩展、高可用、高并发。核心概念基本定义Redis 集群是无中心架构的分布式系统数据自动分散到多个节点每个节点只存部分数据节点间通过 Gossip 协议通信自带故障转移无需 Sentinel。关键角色主节点Master处理读写、管理哈希槽、参与故障投票是核心节点。从节点Replica/Slave异步复制主节点数据默认只读主节点宕机时自动选举晋升为主。哈希槽Hash Slot集群固定16384个槽0~16383是数据分片的最小单位。节点 ID每个节点唯一标识用于集群内识别与通信。核心特性数据分片突破单机内存限制总容量 所有主节点内存之和。高可用部分节点故障不影响整体自动故障转移。线性扩展加节点即可提升容量与并发。去中心化无中心节点避免单点瓶颈。自动路由客户端连接任意节点自动重定向到目标节点。工作原理数据分片哈希槽机制槽位总数163842¹⁴。键 → 槽映射# 集群分片公式HASH_SLOT CRC16(key) mod 16384即对key做CRC16哈希后再对16384取模得到该键归属的哈希槽(0~16383)HASH_SLOTCRC16(key)mod16384槽位分配每个主节点负责一段连续槽位如 3 主集群0-5460、5461-10922、10923-16383。节点通信Gossip 协议节点间通过集群总线独立端口默认 10000通信。消息类型PING/PONG心跳检测、状态同步。FAIL广播节点失效。UPDATE槽位映射、集群拓扑更新。系统IP 地址主机名Centos7.9192.168.108.21redis1Centos7.9192.168.108.22redis2Centos7.9192.168.108.23redis3请求路由流程客户端连接任意节点发送命令。节点计算 key 所属槽位。槽位归属本节点 → 直接处理否则 → 返回MOVED重定向。智能客户端缓存槽位映射减少重定向。故障转移高可用故障检测某主节点超时无响应多数主节点标记为FAIL。从节点选举该主节点的从节点发起FAILOVER请求。投票晋升主节点投票通过从节点升级为主接管槽位。拓扑更新Gossip 同步新状态集群恢复。数据一致性异步复制主从复制异步存在短暂数据不一致。最终一致性故障转移后数据最终一致不保证强一致。写安全多数主节点可达时写操作尽量保留。使用场景海量数据存储100GB电商商品库、用户画像、社交内容、IoT 设备数据。突破单机内存上限分布式存储海量热数据。高并发读写QPS ≥ 5 万秒杀、抢购、热点评论、实时排行榜。多主节点并行处理并发能力线性提升。强事务、多键跨槽操作如 MSET 多键不同槽。- 数据量小、低并发哨兵/主从更简单。需强一致性可搭配分布式事务。操作步骤3 主 3 从实战系统IP 地址主机名Centos7.9192.168.108.24redis4Centos7.9192.168.108.25redis5Centos7.9192.168.108.26redis6架构cluster 集群是 Redis 从 3.0 版本开始支持自带的一种集群方式。它的原理使用了分布的思想其数据会均分到所有的主节点上。此部署方式当数据量过大时会让服务器均摊压力。在各个主节点上分配的数据都不是全量的。是分片存储的。目前此种部署方式在生产环境的较多。至少六台三台主三台从。目的同时解决高可用、海量数据存储和高并发读写的问题即分布式扩展。原理Redis Cluster 是 Redis 官方提供的分布式数据库解决方案。它通过数据分片(Sharding)进行数据存储并通过多主多从架构来实现高可用。准备 6 台安装了 redis 的虚拟机同时操作关闭防火墙修改配置文件。配置所有主机操作# 修改配置文件systemctl stop firewalld 关闭防火墙避免其拦截集群节点端口[rootlocalhost ~]# systemctl stop firewalld# cd 进入Redis安装目录[rootlocalhost ~]# cd /usr/local/redis-6.2.14/# vim redis.conf 编辑该集群节点的配置文件[rootlocalhost redis-6.2.14]# vim redis.conf # 第75行监听地址bind 0.0.0.0 -::1 监听所有IPv4与IPv6地址允许集群节点间互通bind0.0.0.0 -::1# 第1387行启动cluster集群cluster-enabled yes 开启集群模式使本节点成为集群节点cluster-enabledyes# 启动Redisredis-server redis.conf 以后台方式按配置启动本节点 放到后台运行[rootlocalhost redis-6.2.14]# redis-server redis.conf # 查看启动端口6379为客户端端口16379为集群总线端口netstat -anpt | grep redis 查看redis监听端口netstat显示网络连接grep过滤redis相关行[rootredis1 redis-6.2.14]# netstat -anpt | grep redistcp000.0.0.0:63790.0.0.0:* LISTEN55036/redis-server# 客户端端口6379处于监听状态tcp000.0.0.0:163790.0.0.0:* LISTEN55036/redis-server# 集群总线端口16379处于监听状态用于节点间通信为客户端端口10000tcp600::1:6379 :::* LISTEN55036/redis-server tcp600::1:16379 :::* LISTEN55036/redis-server任意一台即可创建集群# 创建集群6个节点每个主节点带1个从节点redis-cli --cluster create 创建集群后接6个节点的IP:端口--cluster-replicas 1 指定每个主节点配备1个从节点[rootredis1 redis-6.2.14]# redis-cli --cluster create 192.168.108.21:6379 192.168.108.22:6379 192.168.108.23:6379 192.168.108.24:6379 192.168.108.25:6379 192.168.108.26:6379 --cluster-replicas 1Performinghashslots allocation on6nodes...# 工具开始在6个节点间分配16384个哈希槽Master[0]-Slots0-5460 Master[1]-Slots5461-10922 Master[2]-Slots10923-16383 Adding replica192.168.108.25:6379 to192.168.108.21:6379 Adding replica192.168.108.26:6379 to192.168.108.22:6379 Adding replica192.168.108.24:6379 to192.168.108.23:6379 M: fcbf04a3649f4e9e6b381861a94393c31eb67e67192.168.108.21:6379 slots:[0-5460](5461slots)master# [0-5460]是负责槽位0-5064(5461 slots)是共5461个槽位M: f3cb00b07a7836666bd3fd391040ff308ad35685192.168.108.22:6379 slots:[5461-10922](5462slots)master M: 90507dea1ca425cfe6ca993f8c453b2377ded5f0192.168.108.23:6379 slots:[10923-16383](5461slots)master S: 95fd02ecaf3fb34822fd56ed7ae61b05d782d892192.168.108.24:6379 replicates 90507dea1ca425cfe6ca993f8c453b2377ded5f0 S: 18b45e542ebbf318fd9a92cfe2adcde4c255c72b192.168.108.25:6379 replicates fcbf04a3649f4e9e6b381861a94393c31eb67e67 S: 8f5e04a03ae0984d843dab8fb9cd0cc4c4537624192.168.108.26:6379 replicates f3cb00b07a7836666bd3fd391040ff308ad35685 Can Isetthe above configuration?(typeyesto accept):yes# 回答yesNodes configuration updatedAssign a different config epoch to eachnode55036:M 03 Feb202611:35:48.414# configEpoch set to 1 via CLUSTER SET-CONFIG-EPOCHSending CLUSTER MEET messages tojointhe cluster55036:M 03 Feb202611:35:48.445# IP address for this node updated to 192.168.108.21Waitingforthe cluster tojoin55036:M 03 Feb202611:35:49.510 * Replica192.168.108.25:6379 asksforsynchronization55036:M 03 Feb202611:35:49.510 * Partial resynchronization not accepted: Replication ID mismatch(Replica askedfor5ada9eaab85561721d9411eee29d9e15bf2b87b1, my replication IDs are868d3acb992f408196b2367647b0cf6c3e02912aand0000000000000000000000000000000000000000)55036:M 03 Feb202611:35:49.510 * Replication backlog created, my new replication IDs arecef440df5f9f0706ac9ab7e60a450839e702f045and000000000000000000000000000000000000000055036:M 03 Feb202611:35:49.510 * Starting BGSAVEforSYNC with target: disk55036:M 03 Feb202611:35:49.606 * Background saving started by pid55327Performing Cluster Check(usingnode192.168.108.21:6379)M: fcbf04a3649f4e9e6b381861a94393c31eb67e67192.168.108.21:6379 slots:[0-5460](5461slots)master1additional replica(s)S: 8f5e04a03ae0984d843dab8fb9cd0cc4c4537624192.168.108.26:6379 slots:(0slots)slave replicates f3cb00b07a7836666bd3fd391040ff308ad35685 S: 95fd02ecaf3fb34822fd56ed7ae61b05d782d892192.168.108.24:6379 slots:(0slots)slave replicates 90507dea1ca425cfe6ca993f8c453b2377ded5f0 M: 90507dea1ca425cfe6ca993f8c453b2377ded5f0192.168.108.23:6379 slots:[10923-16383](5461slots)master1additional replica(s)S: 18b45e542ebbf318fd9a92cfe2adcde4c255c72b192.168.108.25:6379 slots:(0slots)slave replicates fcbf04a3649f4e9e6b381861a94393c31eb67e67 M: f3cb00b07a7836666bd3fd391040ff308ad35685192.168.108.22:6379 slots:[5461-10922](5462slots)master1additional replica(s)55327:C 03 Feb202611:35:49.733 * DB saved on disk55327:C 03 Feb202611:35:49.733 * RDB:4MB of memory used by copy-on-write55036:M 03 Feb202611:35:49.736 * Background saving terminated with success55036:M 03 Feb202611:35:49.737 * Synchronization with replica192.168.108.25:6379 succeeded[OK]All nodes agree about slots configuration.Checkforopenslots...Check slots coverage...[OK]All16384slots covered.# 全部16384个槽位均已分配覆盖集群创建成功[rootredis1 redis-6.2.14]# 55036:M 03 Feb 2026 11:35:53.476 # Cluster state changed: ok查看集群状态# 查看集群节点信息redis-cli 连接本机集群节点[rootredis1 redis-6.2.14]# redis-cli# cluster nodes 列出集群中所有节点的角色与槽位分配127.0.0.1:6379cluster nodes 8f5e04a03ae0984d843dab8fb9cd0cc4c4537624192.168.108.26:637916379 slave f3cb00b07a7836666bd3fd391040ff308ad35685017700898970002connected 95fd02ecaf3fb34822fd56ed7ae61b05d782d892192.168.108.24:637916379 slave 90507dea1ca425cfe6ca993f8c453b2377ded5f0017700899003143connected 90507dea1ca425cfe6ca993f8c453b2377ded5f0192.168.108.23:637916379 master -017700898980003connected10923-16383# 主库.23负责槽10923-1638318b45e542ebbf318fd9a92cfe2adcde4c255c72b192.168.108.25:637916379 slave fcbf04a3649f4e9e6b381861a94393c31eb67e67017700898990001connected f3cb00b07a7836666bd3fd391040ff308ad35685192.168.108.22:637916379 master -017700898992672connected5461-10922# 主库.22负责槽5461-10922fcbf04a3649f4e9e6b381861a94393c31eb67e67192.168.108.21:637916379 myself,master -017700898990001connected0-5460# 当前节点(myself)为主库.21负责槽0-5460# 查看集群信息cluster info 查看集群整体运行状态127.0.0.1:6379cluster info cluster_state:ok# 集群状态正常(ok)cluster_slots_assigned:16384# 已分配的槽位总数cluster_slots_ok:16384# 正常可用的槽位数cluster_slots_pfail:0 cluster_slots_fail:0# 故障槽位数量为0cluster_known_nodes:6# 集群已知节点总数为6cluster_size:3# 负责槽位的主库数量为3cluster_current_epoch:6 cluster_my_epoch:1 cluster_stats_messages_ping_sent:1134 cluster_stats_messages_pong_sent:1172 cluster_stats_messages_sent:2306 cluster_stats_messages_ping_received:1167 cluster_stats_messages_pong_received:1134 cluster_stats_messages_meet_received:5 cluster_stats_messages_received:2306创建数据创建数据需要到提示的地方创建或者在redis-cli -c的命令创建数据。# redis1节点上创建数据会提示跳转到对应槽位所在节点set name gqd 在.21节点上写入键name127.0.0.1:6379setname gqd(error)MOVED5798192.168.108.22:6379# 键name归属槽5798由.22负责需跳转过去执行# 提示在redis2操作# redis2节点上创建数据set name gqd 在负责该槽的.22节点上写入键name127.0.0.1:6379setnamegqdOK# 写入成功# get name 在.22节点上读取键name127.0.0.1:6379get namegqd# 读取到的值为gqd# redis1节点上查询也会提示跳转get name 在.21节点上查询name观察重定向提示127.0.0.1:6379get name# 创建查看都只能在redis2(error)MOVED5798192.168.108.22:6379# 槽5798归.22负责需跳转# 使用-c参数自动重定向在任意节点即可操作redis-cli -c 以集群模式启动客户端-c 表示遇到MOVED时自动重定向到正确节点[rootredis1 redis-6.2.14]# redis-cli -c# set age 18 写入键age客户端会自动重定向到负责该槽的节点127.0.0.1:6379setage18OK# 写入成功# get age 读取键age127.0.0.1:6379get age18# 读取到的值为18# 在redis3节点上查询自动重定向到对应节点redis-cli -c 在.23节点上以集群模式连接[rootredis3 redis-6.2.14]# redis-cli -c# get age 在.23节点上读取age观察自动重定向过程127.0.0.1:6379get age -Redirected to slot[741]located at192.168.108.21:6379# 客户端自动跳转到负责槽741的.21节点18# 读取到的值为18模拟故障关掉 redis1 节点再次查看集群信息。# 关闭redis1节点init 0 关闭操作系统即停掉redis1这台机器[rootredis1 redis-6.2.14]# init 0# 在redis2节点上查看集群信息cluster info 在存活的.22节点上查看集群状态验证故障转移127.0.0.1:6379cluster info cluster_state:ok# 集群仍为ok.21的槽位已由其从库接管cluster_slots_assigned:16384 cluster_slots_ok:16384 cluster_slots_pfail:0 cluster_slots_fail:0# 故障槽位为0槽已由新主接管cluster_known_nodes:6 cluster_size:3 cluster_current_epoch:7# 故障转移后集群纪元号已递增cluster_my_epoch:2 cluster_stats_messages_ping_sent:1486 cluster_stats_messages_pong_sent:1419 cluster_stats_messages_meet_sent:1 cluster_stats_messages_fail_sent:5 cluster_stats_messages_auth-ack_sent:1 cluster_stats_messages_sent:2912 cluster_stats_messages_ping_received:1419 cluster_stats_messages_pong_received:1487 cluster_stats_messages_fail_received:1 cluster_stats_messages_auth-req_received:1 cluster_stats_messages_received:2908节点IP角色负责槽副本192.168.108.21Master0 – 5460← 由 .25 复制192.168.108.25Slave无槽复制 .21查看节点信息结果可知仍保持 3 台 master原来的 redis5 节点被选举为新 master 节点。再把 redis 业务修复看集群状态。# 在redis2节点上查看集群节点cluster nodes 查看各节点角色确认故障转移结果127.0.0.1:6379cluster nodes 90507dea1ca425cfe6ca993f8c453b2377ded5f0192.168.108.23:637916379 master -017700911760003connected10923-16383 18b45e542ebbf318fd9a92cfe2adcde4c255c72b192.168.108.25:637916379 master -017700911774327connected0-5460# 原.25从库已晋升为主库接管槽0-5460f3cb00b07a7836666bd3fd391040ff308ad35685192.168.108.22:637916379 myself,master -017700911750002connected5461-10922# 当前节点.22为主库负责槽5461-109228f5e04a03ae0984d843dab8fb9cd0cc4c4537624192.168.108.26:637916379 slave f3cb00b07a7836666bd3fd391040ff308ad35685017700911740002connected 95fd02ecaf3fb34822fd56ed7ae61b05d782d892192.168.108.24:637916379 slave 90507dea1ca425cfe6ca993f8c453b2377ded5f0017700911764223connected fcbf04a3649f4e9e6b381861a94393c31eb67e67192.168.108.21:637916379 master,fail -177009114369517700911400001connected# 原主库.21已故障下线(fail)完整过程如果你的 Redis Cluster 中192.168.108.21:6379Master 1挂掉而它的从节点192.168.108.25:6379仍然存活那么整个集群会自动完成故障转移failover服务不会中断数据也不会丢失。下面详细说明会发生什么 当前角色回顾基于你之前的cluster nodes输出其他节点.22/.26, .23/.24正常运行。 如果192.168.108.21挂掉会发生什么项目故障前故障后.21 挂Master 节点.21, .22, .23.25, .22, .23Slave 节点.25, .26, .24.25 已晋升剩下 .26, .24槽覆盖0–163830–16383完整✅第 1 步故障检测约 15 秒内其他 master 节点.22 和 .23通过Gossip 协议发现 .21 无响应。经过cluster-node-timeout默认 15 秒后多数 master≥ 2/3将其标记为FAIL客观下线。⏱️ 在这 15 秒内访问槽 [0–5460] 的请求会失败或超时。✅第 2 步Slave .25 自动发起选举.25原 .21 的 slave检测到 master 已 FAIL。等待一个短暂随机延迟通常 1 秒然后向其他 **master 节点.22 和 .23**请求投票。✅第 3 步获得多数票晋升为新 Master.22 和 .23 收到请求后验证 .25 是合法副本。因为有2 个 master 投票超过半数.25 成功当选。.25 执行SLAVEOF NO ONE并接管槽 0–5460。✅第 4 步集群拓扑更新恢复服务所有节点收到通知更新集群视图.25 变为 master槽 0–5460 的 owner 变为 .25。集群状态重新变为cluster_state: okcluster_slots_fail: 0。客户端再次写入 key如SET user:1001 Alice假设其槽在 0–5460自动重定向到192.168.108.25:6379操作成功 故障前后对比项目故障前故障后.21 挂集群状态ok短暂 fail →恢复为 ok数据完整性完整完整无丢失客户端影响写入槽 0–5460 暂时失败 30 秒自动恢复场景集群是否可用数据是否安全是否自动恢复仅 .21master挂✅ 是✅ 是✅ 是由 .25 接管.21 .25 同时挂❌ 否⚠️ 槽 0–5460 不可用❌ 否✅整个过程全自动无需人工干预❗ 极端情况如果 .21 和 .25 同时挂掉槽0–5460 将无人负责集群状态变为cluster_state: failcluster_slots_fail: 5461。所有涉及这些槽的读写都会失败返回(error) CLUSTERDOWN The cluster is down。必须手动恢复 .21 或 .25 才能恢复服务。 这就是为什么主从节点必须部署在不同物理机/可用区 如何验证动手测试# 1. 在redis1 (.21) 上停止Redissystemctl stop redis 用systemd停止.21上的Redis服务systemctl stop redis# 2. 在redis2 (.22) 上观察集群状态redis-cli -c -h 192.168.108.22 -p 6379 cluster nodes-c集群自动重定向-h指定连接.22-p指定端口6379cluster nodes列出节点redis-cli-c-h192.168.108.22-p6379cluster nodes你会看到.21 状态变为 fail→ fail#faile? 状态停留很短暂.25 角色从 slave 变为 master并拥有 0-5460 槽几十秒后cluster info 显示 cluster_state:ok✅总结你当前的3 主 3 从架构完全能容忍任意一个 master 宕机这是 Redis Cluster 高可用的核心价值挂掉 radis5 测试# 关闭redis5节点init 0 关闭redis5(.25)这台机器[rootredis5 redis-6.2.14]# init 0# 在redis2节点上查看集群节点此时.25也挂了槽0-5460无人负责redis-cli -c -h 192.168.108.22 -p 6379 cluster nodes-c自动重定向-h指定.22-p指定6379查看节点状态[rootredis2 redis-6.2.14]# redis-cli -c -h 192.168.108.22 -p 6379 cluster nodes90507dea1ca425cfe6ca993f8c453b2377ded5f0192.168.108.23:637916379 master -017700923432253connected10923-16383 18b45e542ebbf318fd9a92cfe2adcde4c255c72b192.168.108.25:637916379 master,fail -177009224633817700922432117connected0-5460# .25主库故障其负责的槽0-5460已无人接管f3cb00b07a7836666bd3fd391040ff308ad35685192.168.108.22:637916379 myself,master -017700923410002connected5461-10922 8f5e04a03ae0984d843dab8fb9cd0cc4c4537624192.168.108.26:637916379 slave f3cb00b07a7836666bd3fd391040ff308ad35685017700923420002connected 95fd02ecaf3fb34822fd56ed7ae61b05d782d892192.168.108.24:637916379 slave 90507dea1ca425cfe6ca993f8c453b2377ded5f0017700923452593connected fcbf04a3649f4e9e6b381861a94393c31eb67e67192.168.108.21:637916379 master,fail -177009114369517700911400001connected# .21原主库仍处于故障状态# 查看集群信息状态为fail5461个槽不可用redis-cli -c -h 192.168.108.22 -p 6379 cluster info 查看集群状态[rootredis2 redis-6.2.14]# redis-cli -c -h 192.168.108.22 -p 6379 cluster infocluster_state:fail# 集群状态变为fail# 集群状态failcluster_slots_assigned:16384 cluster_slots_ok:10923# 仅剩10923个槽可用cluster_slots_pfail:0 cluster_slots_fail:5461# 有5461个槽(0-5460)无主负责不可用cluster_known_nodes:6 cluster_size:3 cluster_current_epoch:7 cluster_my_epoch:2 cluster_stats_messages_ping_sent:2545 cluster_stats_messages_pong_sent:2417 cluster_stats_messages_meet_sent:1 cluster_stats_messages_fail_sent:5 cluster_stats_messages_auth-ack_sent:1 cluster_stats_messages_sent:4969 cluster_stats_messages_ping_received:2417 cluster_stats_messages_pong_received:2545 cluster_stats_messages_fail_received:2 cluster_stats_messages_auth-req_received:1 cluster_stats_messages_received:4965恢复集群监控将关掉的两台服务器开机开启 redis 服务即可。# 恢复后查看集群信息状态恢复为okredis-cli -c -h 192.168.108.22 -p 6379 cluster info 查看恢复后的集群状态[rootredis2 redis-6.2.14]# redis-cli -c -h 192.168.108.22 -p 6379 cluster infocluster_state:ok# 集群状态恢复为okcluster_slots_assigned:16384 cluster_slots_ok:16384# 全部16384个槽恢复可用cluster_slots_pfail:0 cluster_slots_fail:0# 故障槽位清零cluster_known_nodes:6 cluster_size:3 cluster_current_epoch:7 cluster_my_epoch:2 cluster_stats_messages_ping_sent:3130 cluster_stats_messages_pong_sent:2952 cluster_stats_messages_meet_sent:1 cluster_stats_messages_fail_sent:5 cluster_stats_messages_auth-ack_sent:1 cluster_stats_messages_sent:6089 cluster_stats_messages_ping_received:2952 cluster_stats_messages_pong_received:3130 cluster_stats_messages_fail_received:3 cluster_stats_messages_auth-req_received:1 cluster_stats_messages_received:6086# 恢复后查看集群节点.21变为.25的从节点cluster nodes 查看重启后各节点角色[rootredis2 redis-6.2.14]# redis-cli -c -h 192.168.108.22 -p 6379 cluster nodes90507dea1ca425cfe6ca993f8c453b2377ded5f0192.168.108.23:637916379 master -017700929777823connected10923-16383 18b45e542ebbf318fd9a92cfe2adcde4c255c72b192.168.108.25:637916379 master -017700929788167connected0-5460 f3cb00b07a7836666bd3fd391040ff308ad35685192.168.108.22:637916379 myself,master -017700929770002connected5461-10922 8f5e04a03ae0984d843dab8fb9cd0cc4c4537624192.168.108.26:637916379 slave f3cb00b07a7836666bd3fd391040ff308ad35685017700929770002connected 95fd02ecaf3fb34822fd56ed7ae61b05d782d892192.168.108.24:637916379 slave 90507dea1ca425cfe6ca993f8c453b2377ded5f0017700929767653connected fcbf04a3649f4e9e6b381861a94393c31eb67e67192.168.108.21:637916379 slave 18b45e542ebbf318fd9a92cfe2adcde4c255c72b017700929770007connected# .21重启后以从库身份复制新主库.25