Redis 主从复制该如何配置?从机配置与主从复制使用 redis 复制流程
参与复制的Redis实例划分为主节点(master) 和从节点(slave) 。 默认情况下, Redis都是主节点。 每个从节点只能有一个主节点, 而主节点可以同时具有多个从节点。 复制的数据流是单向的, 只能由主节点复制到从节点。
从节点配置
-
在配置文件中加入
slaveof{masterHost}{masterPort}
随Redis启动生效。 -
在redis-server启动命令后加入
--slaveof{masterHost}{masterPort}
生效。 -
直接使用命令:
slaveof{masterHost}{masterPort}
生效
查看主从信息
127.0.0.1:6379> info replication # Replication role:slave #角色 master_host:172.18.0.2 master_port:6379 master_link_status:down master_last_io_seconds_ago:-1 master_sync_in_progress:0 slave_read_repl_offset:0 slave_repl_offset:0 master_link_down_since_seconds:-1 slave_priority:100 slave_read_only:1 replica_announced:1 connected_slaves:0 #从机个数 master_failover_state:no-failover master_replid:cfb75de90c1e774b9eda4fc0bb793d20dfc443b6 master_replid2:f637f1d252689c394c69e9003fcb1ac243100360 master_repl_offset:0 second_repl_offset:1 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0
断开主节点
slaveof no one
断开复制主要流程: 1) 断开与主节点复制关系。 2) 从节点晋升为主节点。 从节点断开复制后并不会抛弃原有数据, 只是无法再获取主节点上的数据变化。
切换主节点
slaveof {newMasterIp}{newMasterPort}
切主操作流程如下: 1) 断开与旧主节点复制关系。 2) 与新主节点建立复制关系。 3) 删除从节点当前所有数据。 4) 对新主节点进行复制操作。
切主后从节点会清空之前所有的数据
密码验证
对于数据比较重要的节点, 主节点会通过设置requirepass参数进行密码验证, 这时所有的客户端访问必须使用auth命令实行校验。 从节点与主节点的复制连接是通过一个特殊标识的客户端来完成, 因此需要配置从节点的masterauth参数与主节点密码保持一致, 这样从节点才可以正确地连接到主节点并发起复制流程。
只读
从节点使用slave-read-only=yes配置为只读模式 ,默认开启
拓扑
Redis的复制拓扑结构可以支持单层或多层复制关系, 根据拓扑复杂性可以分为以下三种: 一主一从、 一主多从、 树状主从结构
redis 集群的作用
-
提高系统的可用性和可靠性: 通过将数据复制到一个或多个从节点,即使主节点发生故障,也可以继续提供服务。当主节点不可用时,可以将一个从节点提升为新的主节点,从而避免服务中断,并快速恢复数据的可用性。
-
数据备份和灾难恢复: 从节点保存了主节点的完整数据集的副本,因此可以用作数据备份。在发生数据丢失或灾难情况时,可以使用从节点来恢复数据,减少数据丢失和业务中断的风险。
-
读写分离和负载均衡: 主节点负责处理写入操作,而从节点负责处理读取操作。通过将读取操作分发到多个从节点,可以分担主节点的读取负载,提高系统的整体性能和吞吐量。
-
提高数据可靠性和一致性: 通过复制数据到多个节点,可以提高数据的可靠性和一致性。即使在主节点发生故障或数据损坏时,仍然可以通过从节点提供可靠的数据访问。
-
扩展读取操作的性能: 通过添加多个从节点,可以实现读取操作的水平扩展,从而提高系统的读取性能和并发能力。从节点可以分担主节点的读取压力,并提供更快的响应时间。
一主一从
一主一从结构是最简单的复制拓扑结构, 用于主节点出现宕机时从节点提供故障转移支持
当应用写命令并发量较高且需要持久化时, 可以只在从节点上开启AOF, 这样既保证数据安全性同时也避免了持久化对主节点的性能干扰。
一主多从
一主多从结构(又称为星形拓扑结构) 使得应用端可以利用多个从节点实现读写分离
对于读占比较大的场景, 可以把读命令发送到从节点来分担主节点压力。
对于写并发量较高的场景, 多个从节点会导致主节点写命令的多次发送从而过度消耗网络带宽, 同时也加重了主节点的负载影响服务稳定性
树状主从
树状主从结构(又称为树状拓扑结构) 使得从节点不但可以复制主节点数据, 同时可以作为其他从节点的主节点继续向下层复制。
配置单机多集群案例
复制配置文件
root@da9676fe8449:/tool/redis# cp redis.conf redis80.conf root@da9676fe8449:/tool/redis# cp redis.conf redis81.conf
修改配置文件
修改 port
pidfile
logfile
dumpfile
启动从机
redis-cli redis80.conf
redis-cli redis81.conf
redis-cli -p 6380
redis-cli -p 6381
复制流程
部分复制
部分复制主要是Redis针对全量复制的过高开销做出的一种优化措施,使用psync{runId}{offset}
命令实现。
当从节点(slave) 正在复制主节点(master) 时, 如果出现网络闪断或者命令丢失等异常情况时, 从节点会向主节点要求补发丢失的命令数据
流程
-
当主从节点之间网络出现中断时, 如果超过repl-timeout时间, 主节点会认为从节点故障并中断复制连接
-
主从连接中断期间主节点依然响应命令, 但因复制连接中断命令无法发送给从节点, 不过主节点内部存在的复制积压缓冲区, 依然可以保存最近一段时间的写命令数据, 默认最大缓存1MB
-
当主从节点网络恢复后, 从节点会再次连上主节点,由于从节点之前保存了自身已复制的偏移量和主节点的运行ID。 因此会把它们当作psync参数发送给主节点, 要求进行部分复制操作。
-
主节点接到psync命令后首先核对参数runId是否与自身一致, 如果一致, 说明之前复制的是当前主节点; 之后根据参数offset在自身复制积压缓冲区查找, 如果偏移量之后的数据存在缓冲区中, 则对从节点发送+CONTINUE响应, 表示可以进行部分复制。
-
主节点根据偏移量把复制积压缓冲区里的数据发送给从节点, 保证主从复制进入正常状态。 发送的数据量可以在主节点的日志获取
主从心跳判断机制
-
主从节点彼此都有心跳检测机制, 各自模拟成对方的客户端进行通信, 通过client list命令查看复制相关客户端信息, 主节点的连接状态为flags=M, 从节点连接状态为flags=S。
-
主节点默认每隔10秒对从节点发送ping命令, 判断从节点的存活性和连接状态。 可通过参数
repl-ping-slave-period
控制发送频率。 -
从节点在主线程中每隔1秒发送replconf ack{offset}命令, 给主节点上报自身当前的复制偏移量。
replconf
命令主要作用如下:-
实时监测主从节点网络状态。
-
上报自身复制偏移量, 检查复制数据是否丢失, 如果从节点数据丢失, 再从主节点的复制缓冲区中拉取丢失数据。
-
实现保证从节点的数量和延迟性功能, 通过
min-slaves-to-write
、minslaves-max-lag
参数配置定义。
-
异步复制
主节点不但负责数据读写, 还负责把写命令同步给从节点。 写命令的发送过程是异步完成, 也就是说主节点自身处理完写命令后直接返回给客户端, 并不等待从节点复制完成 。
由于主从复制过程是异步的, 就会造成从节点的数据相对主节点存在延迟。 具体延迟多少字节, 我们可以在主节点执行info replication
命令查看
-
应该把主节点尽量分散在多台机器上, 避免在单台机器上部署过多的主节点。
-
当主节点所在机器故障后提供故障转移机制, 避免机器恢复后进行密集的全量复制
参考资料:《Redis 开发与运维》
原文地址:https://blog.csdn.net/weixin_42576071/article/details/136802434
免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!