RocketMQ 平滑升级到主从切换实战

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 本文主要介绍如何将 RocketMQ 集群从原先的主从同步升级到主从切换。首先介绍与 DLedger 多副本即 RocketMQ 主从切换相关的核心配置属性,然后尝试搭建一个主从同步集群,再从原先的 RocketMQ 集群平滑升级到 DLedger 集群的示例,并简单测试一下主从切换功能。

本文主要介绍如何将 RocketMQ 集群从原先的主从同步升级到主从切换。

首先介绍与 DLedger 多副本即 RocketMQ 主从切换相关的核心配置属性,然后尝试搭建一个主从同步集群,再从原先的 RocketMQ 集群平滑升级到 DLedger 集群的示例,并简单测试一下主从切换功能。

1、RocketMQ DLedger 多副本即主从切换核心配置参数详解

其主要的配置参数如下所示:

  • enableDLegerCommitLog
    是否启用 DLedger,即是否启用 RocketMQ 主从切换,默认值为 false。如果需要开启主从切换,则该值需要设置为 true 。
  • dLegerGroup
    节点所属的 raft 组,建议与 brokerName 保持一致,例如 broker-a。
  • dLegerPeers
    集群节点信息,示例配置如下:n0-127.0.0.1:40911;n1-127.0.0.1:40912;n2-127.0.0.1:40913,多个节点用英文冒号隔开,单个条目遵循 legerSlefId-ip:端口,这里的端口用作 dledger 内部通信。
  • dLegerSelfId
    当前节点id。取自 legerPeers 中条目的开头,即上述示例中的 n0,并且特别需要强调,只能第一个字符为英文,其他字符需要配置成数字。
  • storePathRootDir
    DLedger 日志文件的存储根目录,为了能够支持平滑升级,该值与 storePathCommitLog 设置为不同的目录。

2、搭建主从同步环境

首先先搭建一个传统意义上的主从同步架构,往集群中灌一定量的数据,然后升级到 DLedger 集群。

在 Linux 服务器上搭建一个 rocketmq 主从同步集群我想不是一件很难的事情,故本文就不会详细介绍按照过程,只贴出相关配置。

实验环境的部署结构采取 一主一次,其部署图如下:
在这里插入图片描述
下面我就重点贴一下 broker 的配置文件。
220 上的 broker 配置文件如下:

brokerClusterName = DefaultCluster
brokerName = broker-a
brokerId = 0
deleteWhen = 04
fileReservedTime = 48
brokerRole = ASYNC_MASTER
flushDiskType = ASYNC_FLUSH
brokerIP1=192.168.0.220
brokerIP2=192.168.0.220
namesrvAddr=192.168.0.221:9876;192.168.0.220:9876
storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store
storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false

221 上 broker 的配置文件如下:

brokerClusterName = DefaultCluster
brokerName = broker-a
brokerId = 1
deleteWhen = 04
fileReservedTime = 48
brokerRole = SLAVE
flushDiskType = ASYNC_FLUSH
brokerIP1=192.168.0.221
brokerIP2=192.168.0.221
namesrvAddr=192.168.0.221:9876;192.168.0.220:9876
storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store
storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false

相关的启动命令如下:

nohup bin/mqnamesrv  /dev/null  2>&1 &
nohup bin/mqbroker -c conf/broker.conf  /dev/null  2>&1 &

安装后的集群信息如图所示:
在这里插入图片描述

3、主从同步集群升级到DLedger

3.1 部署架构

DLedger 集群至少需要3台机器,故搭建 DLedger 还需要再引入一台机器,其部署结构图如下:
在这里插入图片描述
从主从同步集群升级到 DLedger 集群,用户最关心的还是升级后的集群是否能够兼容原先的数据,即原先存储在消息能否能被消息消费者消费端,甚至于能否查询到。
为了方便后续验证,首先我使用下述程序向 mq 集群中添加了一篇方便查询的消息(设置消息的key)。

public class Producer {
    public static void main(String[] args) throws MQClientException, InterruptedException {
        DefaultMQProducer producer = new DefaultMQProducer("producer_dw_test");
        producer.setNamesrvAddr("192.168.0.220:9876;192.168.0.221:9876");
        producer.start();
        for(int i =600000; i < 600100; i ++) {
            try {
                Message msg = new Message("topic_dw_test_by_order_01",null , "m" + i,("Hello RocketMQ" + i ).getBytes(RemotingHelper.DEFAULT_CHARSET));
                SendResult sendResult = producer.send(msg);
               //System.out.printf("%s%n", sendResult);
            } catch (Exception e) {
                e.printStackTrace();
                Thread.sleep(1000);
            }
        }
        producer.shutdown();
        System.out.println("end");
    }
}

消息的查询结果示例如下:
在这里插入图片描述

3.2 升级步骤

Step1:将 192.168.0.220 的 rocketmq 拷贝到 192.168.0.222,可以使用如下命令进行操作。在 192.168.0.220 上敲如下命令:

 scp -r rocketmq-all-4.5.2-bin-release/ root@192.168.0.222:/opt/application/rocketmq-all-4.5.2-bin-release

温馨提示:示例中由于版本是一样,实际过程中,版本需要升级,故需先下载最新的版本,然后将老集群中的 store 目录完整的拷贝到新集群的 store 目录。

Step2:依次在三台服务器的 broker.conf 配置文件中添加与 dledger 相关的配置属性。

192.168.0.220 broker配置文件如下:

brokerClusterName = DefaultCluster
brokerId = 0
deleteWhen = 04
fileReservedTime = 48
brokerRole = ASYNC_MASTER
flushDiskType = ASYNC_FLUSH
brokerIP1=192.168.0.220
brokerIP2=192.168.0.220
namesrvAddr=192.168.0.221:9876;192.168.0.220:9876
storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store
storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false
# 与 dledger 相关的属性
enableDLegerCommitLog=true
storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store/dledger_store
dLegerGroup=broker-a
dLegerPeers=n0-192.168.0.220:40911;n1-192.168.0.221:40911;n2-192.168.0.222:40911
dLegerSelfId=n0

192.168.0.221 broker配置文件如下:

brokerClusterName = DefaultCluster
brokerName = broker-a
brokerId = 1
deleteWhen = 04
fileReservedTime = 48
brokerRole = SLAVE
flushDiskType = ASYNC_FLUSH
brokerIP1=192.168.0.221
brokerIP2=192.168.0.221
namesrvAddr=192.168.0.221:9876;192.168.0.220:9876
storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store
storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false
# 与dledger 相关的配置属性
enableDLegerCommitLog=true
storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store/dledger_store
dLegerGroup=broker-a
dLegerPeers=n0-192.168.0.220:40911;n1-192.168.0.221:40911;n2-192.168.0.222:40911
dLegerSelfId=n1

192.168.0.222 broker配置文件如下:

brokerClusterName = DefaultCluster
brokerName = broker-a
brokerId = 0
deleteWhen = 04
fileReservedTime = 48
brokerRole = ASYNC_MASTER
flushDiskType = ASYNC_FLUSH
brokerIP1=192.168.0.222
brokerIP2=192.168.0.222
namesrvAddr=192.168.0.221:9876;192.168.0.220:9876
storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store
storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false
# 与 dledger 相关的配置
enableDLegerCommitLog=true
storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store/dledger_store
dLegerGroup=broker-a
dLegerPeers=n0-192.168.0.220:40911;n1-192.168.0.221:40911;n2-192.168.0.222:40911
dLegerSelfId=n2

温馨提示:legerSelfId 分别为 n0、n1、n2。在真实的生产环境中,broker配置文件中的 storePathRootDir、storePathCommitLog 尽量使用单独的根目录,这样判断其磁盘使用率时才不会相互影响。

Step3:将 store/config 下的 所有文件拷贝到 dledger store 的 congfig 目录下。

cd /opt/application/rocketmq-all-4.5.2-bin-release/store/
cp config/* dledger_store/config/

温馨提示:该步骤按照各自按照时配置的目录进行复制即可。

Step4:依次启动三台 broker。

nohup bin/mqbroker -c conf/broker.conf  /dev/null  2>&1 &

如果启动成功,则在 rocketmq-console 中看到的集群信息如下:
在这里插入图片描述

3.3 验证消息发送与消息查找

首先我们先验证升级之前的消息是否能查询到,那我们还是查找key 为 m600000 的消息,查找结果如图所示:
在这里插入图片描述

然后我们来测试一下消息发送。测试代码如下:

public class Producer {
    public static void main(String[] args) throws MQClientException, InterruptedException {
        DefaultMQProducer producer = new DefaultMQProducer("producer_dw_test");
        producer.setNamesrvAddr("192.168.0.220:9876;192.168.0.221:9876");
        producer.start();
        for(int i =600200; i < 600300; i ++) {
            try {
                Message msg = new Message("topic_dw_test_by_order_01",null , "m" + i,("Hello RocketMQ" + i ).getBytes(RemotingHelper.DEFAULT_CHARSET));
                SendResult sendResult = producer.send(msg);
                System.out.printf("%s%n", sendResult);
            } catch (Exception e) {
                e.printStackTrace();
                Thread.sleep(1000);
            }
        }
        producer.shutdown();
        System.out.println("end");
    }
}

执行结果如下:
在这里插入图片描述
再去控制台查询一下消息,其结果也表明新的消息也能查询到。
在这里插入图片描述
最后我们再来验证一下主节点宕机,消息发送是否会受影响。

在消息发送的过程中,去关闭主节点,其截图如下:
在这里插入图片描述在这里插入图片描述在这里插入图片描述再来看一下集群的状态:
在这里插入图片描述

等待该复制组重新完成主服务器选举后,即可继续处理消息发送。

温馨提示:由于本示例是一主一从,故在选举期间,消息不可用,但在真实的生产环境上,其部署架构是多主主从,即一个复制组在 leader 选举期间,其他复制组可以接替该复制组完成消息的发送,实现消息服务的高可用。

与 DLedger 相关的日志,默认存储在 broker_default.log 文件中。

4、源码分析 RocketMQ 系列文章

1、RocketMQ 多副本前置篇:初探raft协议
2、源码分析 RocketMQ DLedger 多副本之 Leader 选主
3、源码分析 RocketMQ DLedger 多副本存储实现
4、源码分析 RocketMQ DLedger(多副本) 之日志追加流程
5、源码分析 RocketMQ DLedger(多副本) 之日志复制(传播)
6、基于 raft 协议的 RocketMQ DLedger 多副本日志复制设计原理
7、RocketMQ 整合 DLedger(多副本)即主从切换实现平滑升级的设计技巧
8、源码分析 RocketMQ DLedger 多副本即主从切换实现原理


原文发布时间为:2019-10-13
本文作者:丁威,《RocketMQ技术内幕》作者。
本文来自中间件兴趣圈,了解相关信息可以关注中间件兴趣圈

相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
目录
相关文章
|
5月前
|
消息中间件 人工智能 Apache
Apache RocketMQ 中文社区全新升级!
RocketMQ 中文社区升级发布只是起点,我们将持续优化体验细节,推出更多功能和服务,更重要的是提供更多全面、深度、高质量的内容。
587 14
|
6月前
|
消息中间件 安全 API
《阿里云产品四月刊》—Apache RocketMQ ACL 2.0 全新升级(1)
阿里云瑶池数据库云原生化和一体化产品能力升级,多款产品更新迭代
302 1
《阿里云产品四月刊》—Apache RocketMQ ACL 2.0 全新升级(1)
|
6月前
|
消息中间件 安全 Apache
《阿里云产品四月刊》—Apache RocketMQ ACL 2.0 全新升级(4)
阿里云瑶池数据库云原生化和一体化产品能力升级,多款产品更新迭代
186 1
《阿里云产品四月刊》—Apache RocketMQ ACL 2.0 全新升级(4)
|
6月前
|
消息中间件 安全 Apache
《阿里云产品四月刊》—Apache RocketMQ ACL 2.0 全新升级(2)
阿里云瑶池数据库云原生化和一体化产品能力升级,多款产品更新迭代
248 0
《阿里云产品四月刊》—Apache RocketMQ ACL 2.0 全新升级(2)
|
2月前
|
消息中间件 数据采集 中间件
RabbitMQ的使用—实战
RabbitMQ的使用—实战
|
3月前
|
消息中间件 缓存 Java
RocketMQ的JAVA落地实战
RocketMQ作为一款高性能、高可靠、高实时、分布式特点的消息中间件,其核心作用主要体现在异步处理、削峰填谷以及系统解耦三个方面。
178 0
|
4月前
|
消息中间件 存储 Cloud Native
RocketMQ从4.9.7 升级到5.3.0有什么变化?
【8月更文挑战第25天】RocketMQ从4.9.7 升级到5.3.0有什么变化?
242 4
|
5月前
|
消息中间件 新零售 弹性计算
云消息队列 RabbitMQ 版入门训练营,解锁对比开源优势与零基础实战
欢迎加入「云消息队列 RabbitMQ 版入门训练营」。
171 15
|
4月前
|
消息中间件 人工智能 监控
|
5月前
|
消息中间件 安全 API
Apache RocketMQ ACL 2.0 全新升级
RocketMQ 作为一款流行的分布式消息中间件,被广泛应用于各种大型分布式系统和微服务中,承担着异步通信、系统解耦、削峰填谷和消息通知等重要的角色。随着技术的演进和业务规模的扩大,安全相关的挑战日益突出,消息系统的访问控制也变得尤为重要。然而,RocketMQ 现有的 ACL 1.0 版本已经无法满足未来的发展。因此,我们推出了 RocketMQ ACL 2.0 升级版,进一步提升 RocketMQ 数据的安全性。本文将介绍 RocketMQ ACL 2.0 的新特性、工作原理,以及相关的配置和实践。
13649 8