标题Redis Cluster环境搭建与运维

2023-12-26 11:05:56

标题Redis Cluster环境搭建与运维

Redis Cluster环境搭建与运维

环境搭建

安装包准备

  • redis-6.2.4.zip

  • 目录结构

    • redis-6.2.4
├── bin
│   ├── redis-benchmark
│   ├── redis-check-aof
│   ├── redis-check-rdb
│   ├── redis-cli
│   ├── redis-sentinel
│   ├── redis-server
│   └── redis-trib.rb
├── conf
│   ├── redis_6380.conf
│   ├── redis_6381.conf
│   ├── redis_6382.conf
│   ├── redis_6383.conf
│   ├── redis_6384.conf
│   ├── redis_6385.conf
│   ├── redis_6386.conf
│   ├── redis_6387.conf
│   ├── redis_6388.conf
│   ├── redis_6389.conf
│   ├── redis.conf
│   └── sentinel.conf
└── data

    • 解压到/opt/xyz目录

    • 添加可执行权限：chmod +x /opt/xyz/redis-6.2.4/bin/*

  • redis实例日志路径：/var/log/redis_[port].log

  • redis实例数据路径：$redis-6.2.4/data

启动Redis实例

以创建5主5备集群为例启动10个redis实例，进入到$redis-6.2.4/bin目录执行以下命令

./redis-server /opt/xyz/redis-6.2.4/conf/redis_6380.conf
./redis-server /opt/xyz/redis-6.2.4/conf/redis_6381.conf
./redis-server /opt/xyz/redis-6.2.4/conf/redis_6382.conf
./redis-server /opt/xyz/redis-6.2.4/conf/redis_6383.conf
./redis-server /opt/xyz/redis-6.2.4/conf/redis_6384.conf
./redis-server /opt/xyz/redis-6.2.4/conf/redis_6385.conf
./redis-server /opt/xyz/redis-6.2.4/conf/redis_6386.conf
./redis-server /opt/xyz/redis-6.2.4/conf/redis_6387.conf
./redis-server /opt/xyz/redis-6.2.4/conf/redis_6388.conf
./redis-server /opt/xyz/redis-6.2.4/conf/redis_6389.conf

启动集群

redis cluster只需告诉它redis实例，它自己会分配主和备，并且会尽量让自己的备在其他机器上。

启动命令：

redis-cli --cluster create \
192.168.78.24:6380 192.168.78.24:6389 \
192.168.78.46:6381 192.168.78.46:6388 \
192.168.78.47:6382 192.168.78.47:6387 \
192.168.78.48:6383 192.168.78.48:6386 \
192.168.78.49:6384 192.168.78.49:6385 \
--cluster-replicas 1

查看集群

1. 连上任意节点：redis-cli -h ip -p port #任意一节点
2. 连上后只需：cluster nodes

例：
[root@vm-LOCALXDL02-tm-redis-7824 data]# redis-cli -h 192.168.78.24 -p 6380
192.168.78.24:6380> cluster nodes
b670f0e2df800740ef713ddaa83dbf9fed297504 192.168.78.46:6381@16381 master - 0 1634010242650 3 connected 3277-6553
0aab8e5d7c3e5771e522652d72d663ca86a2d9e4 192.168.78.49:6384@16384 master - 0 1634010244000 9 connected 13107-16383
a32d50e1d064ca235c0fc6b0bc5d6b8d4c85524f 192.168.78.48:6383@16383 master - 0 1634010244000 7 connected 9830-13106
2ac14a9e7547e6dee82dbd8b717aac4850e5d08f 192.168.78.24:6389@16389 slave 0aab8e5d7c3e5771e522652d72d663ca86a2d9e4 0 1634010241645 9 connected
125041d45e1c23d9b14f792b31b3545e47ee7ea7 192.168.78.48:6386@16386 slave f1084cd5d3cd173d04c47af47b8ab7ec4f7b2a11 0 1634010242000 5 connected
f8c0e9b1924a782fad787c8fbfe967cae08b5a00 192.168.78.47:6387@16387 slave b670f0e2df800740ef713ddaa83dbf9fed297504 0 1634010243000 3 connected
e559a191bf64dfa81e106cb842738be5d2724f69 192.168.78.24:6380@16380 myself,master - 0 1634010242000 1 connected 0-3276
d89965196f90559cbf4787de4b90c6403eba308c 192.168.78.49:6385@16385 slave a32d50e1d064ca235c0fc6b0bc5d6b8d4c85524f 0 1634010244655 7 connected
f1084cd5d3cd173d04c47af47b8ab7ec4f7b2a11 192.168.78.47:6382@16382 master - 0 1634010245659 5 connected 6554-9829
1c35fa2948b092aa578b977ce758c00935680fe5 192.168.78.46:6388@16388 slave e559a191bf64dfa81e106cb842738be5d2724f69 0 1634010240000 1 connected

到此集群环境已搭建完毕！！！

运维

添加master节点

  1. 启动一个新的redis实例

  2. 加入集群，此时它还没有分配任何slot，此时它是作为master

    redis-cli --cluster add-node 新节点的ip:port 集群中的任一节点

  3. 分配slot

    自动分配

    redis-cli --cluster reshard 127.0.0.1:7000

    手动分配

    redis-cli --cluster reshard <host>:<port> --cluster-from <node-id> --cluster-to <node-id> --cluster-slots <number of slots> --cluster-yes

添加slave节点

  1. 启动一个新的redis实例

  2. 加入集群有以下3种方式

    随机选取master节点

    redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000 --cluster-slave

    指定master节点

    redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000 --cluster-slave --cluster-master-id 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e

    通过cluster replicate

    redis 127.0.0.1:7006> cluster replicate 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e

删除slave节点

redis-cli --cluster del-node 127.0.0.1:7000（集群任一节点） `<node-id>`(被删除的节点)

删除异常节点

在redis命令行执行cluster nodes命令时，如出现如下信息：

4f61cdeb684fec56a82cc5f3cc72f0def5df05c3 :0@0 slave,fail,noaddr 297a72d200be658a37658bd0ed9bda01d96af43f 1567608093527 1567608091611 9 disconnected

需要在所有节点上执行如下命令，即可剔除异常节点

cluster forget 4f61cdeb684fec56a82cc5f3cc72f0def5df05c3  // 对应异常节点的id

手动主备切换

master升级或者是替换master的时候比较有用，有以下几种方式进行主备切换：

  1. 手动触发故障转移，比真实的故障转移影响更小，连上slave执行命令：

    cluster failover

  2. 主动触发故障转移，在slave节点执行，影响小，数据不丢失

    cluster failover force

  3. 强制触发故障转移，比cluster failover粗暴

    cluster failover takeover

关于故障转移

故障转移过程

  • 主观下线

    1. 集群中的每个节点都会向其他节点发送ping消息，接收节点回复pong消息作为响应。如果在cluster-node-timeout时间内一直通信失败，则发送节点会认为接收节点存在故障，把接收节点标记为主观下线状态(pfail)

  • 客观下线

    1. 如果集群内超过一半的主节点标记某节点为主观下线时，则重新标记该节点为客观下线

    2. 广播一条fail消息，通知集群所有节点标记故障节点为客观下线状态，并通知故障从节点触发故障转移流程

  • 故障切换

    1. 资格检查，如果从节点与主节点断线时间超过cluster-node-time*cluster-slave-validity-factor，则当前从节点不具备故障转移资格。参数cluster-slavevalidity-factor用于从节点的有效因子，默认为10

    2. 准备选举时间，当从节点符合故障切换资格后，更新触发切换选举的时间，只有到达该时间后才能执行后续流程。

      这里之所以采用延迟触发机制，主要是通过对多个从节点使用不同的延迟选举时间来支持优先级问题。复制偏移量越大说明从节点延迟越低，那么它应该具有更高的优先级来替换故障主节点

    3. 发起选举，当从节点定时任务检测到达故障选举时间（failover_auth_time）到达后，发起选举流程如下：

      1> 更新配置纪元

      2> 广播选举消息，在集群内广播选举消息（FAILOVER_AUTH_REQUEST），并记录已发送过消息的状态，保证该从节点在一个配置纪元内只能发起一次选举。

    4. 选举投票，只有持有槽的主节点才会处理故障选举消息（FAILOVER_AUTH_REQUEST），因为每个持有槽的节点在一个配置纪元内都有唯一的一张选票，当接到第一个请求投票的从节点消息时回复FAILOVER_AUTH_ACK消息作为投票，之后相同配置纪元内其他从节点的选举消息将忽略。

      Redis集群没有直接使用从节点进行领导者选举，主要因为从节点数必须大于等于3个才能保证凑够N/2+1个节点，将导致从节点资源浪费。使用集群内所有持有槽的主节点进行领导者选举，即使只有一个从节点也可以完成选举过程。

    5. 替换主节点，当从节点收集到足够的选票之后，触发替换主节点操作：

      1> 当前从节点取消复制变为主节点。

      2> 执行clusterDelSlot操作撤销故障主节点负责的槽，并执行clusterAddSlot把这些槽委派给自己。

      3> 向集群广播自己的pong消息，通知集群内所有的节点当前从节点变为主节点并接管了故障主节点的槽信息。

故障切换时间

1> 主观下线（pfail）识别时间=cluster-node-timeout。

2> 主观下线状态消息传播时间<=cluster-node-timeout/2。消息通信机制对超过cluster-node-timeout/2未通信节点会发起ping消息，消息体在选择包含哪些节点时会优先选取下线状态节点，所以通常这段时间内能够收集到半数以上主节点的pfail报告从而完成故障发现。

3> 从节点转移时间<=1000毫秒。由于存在延迟发起选举机制，偏移量最大的从节点会最多延迟1秒发起选举。通常第一次选举就会成功，所以从节点执行转移时间在1秒以内。

根据以上分析可以预估出故障转移时间，如下：

failover-time(毫秒) ≤ cluster-node-timeout + cluster-node-timeout/2 + 1000

因此，故障转移时间跟cluster-node-timeout参数息息相关，默认15秒。

集群相关的参数

cluster-enabled <yes/no>：是否开启集群模式。

cluster-config-file ：集群配置文件，由集群自动维护，不建议手动编辑。

cluster-node-timeout ：集群中每个节点都会定期向其他节点发送ping消息，接收节点回复pong消息作为响应。如果在cluster-node-timeout时间内通信一直失败，则发送节点会认为接收节点存在故障，把接收节点标记为主观下线（pfail）状态。默认15000，即15s。

cluster-slave-validity-factor ：每个从节点都要检查最后与主节点断线时间，判断其是否有资格替换故障的主节点。如果从节点与主节点断线时间超过cluster-node-time*cluster-slave-validity-factor，则当前从节点不具备故障转移资格。

cluster-migration-barrier ：主节点需要的最小从节点数，只有达到这个数，才会将多余的从节点迁移给其它孤立的主节点使用。

cluster-require-full-coverage <yes/no>：默认情况下当集群中16384个槽，有任何一个没有指派到节点时，整个集群是不可用的。对应在线上，如果某个主节点宕机，而又没有从节点的话，是不允许对外提供服务的。建议将该参数设置为no，避免某个主节点的故障导致其它主节点不可用。

文章来源:https://blog.csdn.net/wujiangming/article/details/135214414
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。