redis cluster 故障后，主从位于不同节点的修复【转】

今天机房有一台物理机宕机了，有一个虚拟机192.168.1.122，其上有两个redis 节点也不能用了。

    redis没有备份，丢失的192.168.1.122节点只能重建。

    我找运维的人，分配了一个全新的虚拟机，并且分配的ip的地址仍然是192.168.1.122。

    我在上面装了两个全新的redis，并且无数据：

1
2
/usr/local/redis/bin/redis-server /opt/cachecloud/conf/redis-cluster-6396.conf &
/usr/local/redis/bin/redis-server /opt/cachecloud/conf/redis-cluster-6397.conf &

    此时，这两个redis还是独立的实例，和原来的集群没有任何联系。

    在集群内任意节点，执行cluster meet命令，将192.168.1.122:6396和 192.168.1.122:6397两个实例加入到集群里面：

1
2
3
4
192.168.1.123:6387> cluster meet 192.168.1.122 6396
OK
192.168.1.123:6387> cluster meet 192.168.1.122 6397
OK

    查看集群状态：

1
2
3
4
5
6
7
8
9
192.168.1.123:6387> cluster nodes
6bf77cfcd046681eef9c3d7f94a66709a4a691e4 :0 slave,fail,noaddr 9eb3af9feb3492514834b573260ed8e56419e3c5 1669974772279 1669974767266 5 disconnected
a227a5bef13fe9a33f9e472e6421b66a0a47d60f 192.168.1.122:6396 master - 0 1670075583027 0 connected
9eb3af9feb3492514834b573260ed8e56419e3c5 192.168.1.71:6387 master - 0 1670075580019 5 connected 0-5461
89d9854ee74c8546fad5da04c5a92492c86905d0 192.168.1.123:6387 myself,master - 0 0 2 connected 5462-10923
02a9161dab2bbffbd3066f49d22344356bf9ea33 192.168.1.71:6388 master - 0 1670075579015 4 connected 10924-16383
6b85f48692c226691f3980ad2f52ef103c4ef05e :0 slave,fail,noaddr 89d9854ee74c8546fad5da04c5a92492c86905d0 1669974770273 1669974763256 4 disconnected
5d1891df2da56a5fa9ec5b91905e9b3fe1ceba04 192.168.1.122:6397 master - 0 1670075582025 7 connected
261e6aa4e54d2725445849b525d4ef2be6c85764 192.168.1.123:6388 slave 02a9161dab2bbffbd3066f49d22344356bf9ea33 0 1670075584030 4 connected

    看到192.168.1.122:6396和192.168.1.122:6397加进来了，它们的角色都是master。

      

    接下来，我们把 192.168.1.122:6396和192.168.1.122:6397分别作为192.168.1.71:6387和192.168.1.123:6387的从节点。

1
2
3
4
5
6
7
192.168.1.122:6396> CLUSTER REPLICATE 9eb3af9feb3492514834b573260ed8e56419e3c5
OK
其中 9eb3af9feb3492514834b573260ed8e56419e3c5 为需要的主节点node id 
192.168.1.122:6396 为需要全换的主机
以下同理：
192.168.1.122:6397> CLUSTER REPLICATE 89d9854ee74c8546fad5da04c5a92492c86905d0
OK

    修改从为指定的主，结果如下：

1
2
3
4
5
6
7
cluster nodes
02a9161dab2bbffbd3066f49d22344356bf9ea33 192.168.1.71:6388 master - 0 1670077220086 4 connected 10924-16383
5d1891df2da56a5fa9ec5b91905e9b3fe1ceba04 192.168.1.122:6397 myself,slave 89d9854ee74c8546fad5da04c5a92492c86905d0 0 0 7 connected
9eb3af9feb3492514834b573260ed8e56419e3c5 192.168.1.71:6387 master - 0 1670077223093 5 connected 0-5461
261e6aa4e54d2725445849b525d4ef2be6c85764 192.168.1.123:6388 slave 02a9161dab2bbffbd3066f49d22344356bf9ea33 0 1670077224097 4 connected
a227a5bef13fe9a33f9e472e6421b66a0a47d60f 192.168.1.122:6396 slave 9eb3af9feb3492514834b573260ed8e56419e3c5 0 1670077219083 5 connected
89d9854ee74c8546fad5da04c5a92492c86905d0 192.168.1.123:6387 master - 0 1670077222092 2 connected 5462-10923

    可以看到正常了。

    但是上面的拓扑中，还是存在一个隐患，就是如果192.168.1.71宕机后，其上的1和3两个主节点都会丢失，存在极大的隐患。

    下面我们停掉192.168.1.71的1实例，让192.168.1.122的上的1实例提升为主节点：

1
/usr/local/bin/redis-cli -h 192.168.1.71 -p 6387 -a '123' shutdown

    看到进行了主从切换，这样的拓扑图是安全的，不会出现一个机器宕机，而丢失数据的情况。

转自

redis cluster 故障后，主从位于不同节点的修复。_ITPUB博客
http://blog.itpub.net/28916011/viewspace-2926609/

posted @ 2023-03-30 16:29  paul_hch  阅读(288)  评论(0)    收藏  举报