This article focuses on upgrading a RocketMQ cluster from its original master-slave synchronization to a master-slave switch.

This article first introduces the core configuration properties related to the RocketMQ multiple replica master/slave switchover, then attempts to set up a master/slave synchronization cluster, and finally a smooth upgrade of the original RocketMQ cluster to a DLedger cluster, and briefly tests the master/slave switchover function.

1. RocketMQ Master-slave switchover core configuration parameters

The main configuration parameters are as follows:

  • EnableDLegerCommitLog Whether to enable DLedger, that is, whether to enable the RocketMQ primary/secondary switchover. The default value is false. To enable the primary/secondary switchover, set this parameter to true.

  • Raft group to which the dLegerGroup node belongs, recommended to be consistent with brokerName, for example broker-A.

  • DLegerPeers Cluster node information. The following is an example: N0-127.0.0.1:40911; N1-127.0.0.1:40912; N2-127.0.0.1:40913, multiple nodes are separated by colons, and individual entries follow LegersleFD-IP: port, where the port is used for dledger internal communication.

  • DLegerSelfId Indicates the id of the current node. It is taken from the beginning of a line of legerPeers, n0 in the example above, and it is particularly important to note that only the first character should be in English and the other characters should be configured as numbers.

  • StorePathRootDirDLedger Root directory for storing log files. To support smooth upgrade, set this parameter to a different directory from storePathCommitLog.

2. Set up a master/slave synchronization environment

Firstly, a traditional master-slave synchronization architecture is built, and a certain amount of data is poured into the cluster, and then the cluster is upgraded to DLedger cluster.

Setting up a RocketMQ master-slave synchronization cluster on a Linux server is not a difficult task, so this article will not go through the process in detail, but post the configuration.

The deployment structure of the experimental environment takes one primary and one time, and its deployment diagram is as follows:

The broker configuration file on 220 is as follows:

1brokerClusterName = DefaultCluster 2brokerName = broker-a 3brokerId = 0 4deleteWhen = 04 5fileReservedTime = 48 6brokerRole = ASYNC_MASTER 7flushDiskType = ASYNC_FLUSH 8brokerIP1=192.168.0.220 9 brokerip2 = 192.168.0.22010 namesrvAddr = 192.168.0.221:9876; 192.168.0.220:987611 storepathrootdir = / opt/application/rocketmq - all - 4.5.2 - bin - release/store12storePathCommitLog = / opt/appl Ication/rocketmq - all - 4.5.2 - bin - release/store/commitlog13autoCreateTopicEnable = false14autoCreateSubscriptionGroup = falseCopy the code

221 The configuration file for the broker is as follows:

1brokerClusterName = DefaultCluster 2brokerName = broker-a 3brokerId = 1 4deleteWhen = 04 5fileReservedTime = 48 6brokerRole = SLAVE 7flushDiskType = ASYNC_FLUSH 8brokerIP1=192.168.0.221 9 brokerip2 = 192.168.0.22110 namesrvAddr = 192.168.0.221:9876; 192.168.0.220:987611 storepathrootdir = / opt/application/rocketmq - all - 4.5.2 - bin - release/store12storePathCommitLog = / opt/appl Ication/rocketmq - all - 4.5.2 - bin - release/store/commitlog13autoCreateTopicEnable = false14autoCreateSubscriptionGroup = falseCopy the code

The related startup commands are as follows:

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

The cluster information after installation is as follows:

3. Upgrade the primary/secondary synchronization cluster to DLedger

3.1 Deployment Architecture

A DLedger cluster requires at least three machines. Therefore, another machine needs to be introduced to build DLedger. The deployment diagram is as follows:

1public class Producer { 2 public static void main(String[] args) throws MQClientException, InterruptedException { 3 DefaultMQProducer producer = new DefaultMQProducer("producer_dw_test"); 4 producer. SetNamesrvAddr (" 192.168.0.220:9876; 192.168.0.221:9876 "); 5 producer.start(); 6 for(int i =600000; i < 600100; i ++) { 7 try { 8 Message msg = new Message("topic_dw_test_by_order_01",null , "m" + i,("Hello RocketMQ" + i ).getBytes(RemotingHelper.DEFAULT_CHARSET)); 9 SendResult sendResult = producer.send(msg); 10 //System.out.printf("%s%n", sendResult); 11 } catch (Exception e) {12 e.printStackTrace(); 13 Thread.sleep(1000); 14 }15 }16 producer.shutdown(); 17 System.out.println("end"); 18}} 19Copy the code

The following is an example of the query result:

3.2 Upgrade Procedure

Step1: copy rocketmq 192.168.0.220 to 192.168.0.222. Type the following command on 192.168.0.220:

1 SCP -r rocketmq - all - 4.5.2 - bin - release/[email protected]: / opt/application/rocketmq - all - 4.5.2 - bin - releaseCopy the code

Note: The version in the example is the same, but the version needs to be upgraded. Therefore, download the latest version and copy the store directory in the old cluster to the store directory in the new cluster.

Step2: Add dledger-related configuration properties to the broker.conf configuration file of the three servers in sequence.

The broker configuration file is as follows:

1brokerClusterName = DefaultCluster 2brokerId = 0 3deleteWhen = 04 4fileReservedTime = 48 5brokerRole = ASYNC_MASTER 6flushDiskType = ASYNC_FLUSH 7brokerIP1=192.168.0.220 8brokerIP2=192.168.0.220 9namesrvAddr=192.168.0.221:9876; 192.168.0.220:987610 storepathrootdir = / opt/application/rocketmq - all - 4.5.2 - bin - release/store11storePathCommitLog = / opt/appl Ication/rocketmq - all - 4.5.2 - bin - release/store/commitlog12autoCreateTopicEnable = false13autoCreateSubscriptionGroup = false14 # and dledger Related to the properties of the 15 enabledlegercommitlog = true16storePathRootDir = / opt/application/rocketmq - all - 4.5.2 - bin - release/store/dledger_store1 7 dlegergroup = broker - a18dLegerPeers = n0-192.168.0.220:40911; N1-192.168.0.221:40911; N2-192.168.0.222:4091119 dlegerselfid = n0Copy the code

The 192.168.0.221 Broker configuration file is as follows:

1brokerClusterName = DefaultCluster 2brokerName = broker-a 3brokerId = 1 4deleteWhen = 04 5fileReservedTime = 48 6brokerRole = SLAVE 7flushDiskType = ASYNC_FLUSH 8brokerIP1=192.168.0.221 9 brokerip2 = 192.168.0.22110 namesrvAddr = 192.168.0.221:9876; 192.168.0.220:987611 storepathrootdir = / opt/application/rocketmq - all - 4.5.2 - bin - release/store12storePathCommitLog = / opt/appl Ication/rocketmq - all - 4.5.2 - bin - release/store/commitlog13autoCreateTopicEnable = false14autoCreateSubscriptionGroup = false15 # and dledger Related configuration properties of 16 enabledlegercommitlog = true17storePathRootDir = / opt/application/rocketmq - all - 4.5.2 - bin - release/store/dledger_stor E18dLegerGroup = broker - a19dLegerPeers = n0-192.168.0.220:40911; N1-192.168.0.221:40911; N2-192.168.0.222:4091120 dlegerselfid = n1Copy the code

192.168.0.222 Broker configuration files are as follows:

1brokerClusterName = DefaultCluster 2brokerName = broker-a 3brokerId = 0 4deleteWhen = 04 5fileReservedTime = 48 6brokerRole = ASYNC_MASTER 7flushDiskType = ASYNC_FLUSH 8brokerIP1=192.168.0.222 9 brokerip2 = 192.168.0.22210 namesrvAddr = 192.168.0.221:9876; 192.168.0.220:987611 storepathrootdir = / opt/application/rocketmq - all - 4.5.2 - bin - release/store12storePathCommitLog = / opt/appl Ication/rocketmq - all - 4.5.2 - bin - release/store/commitlog13autoCreateTopicEnable = false14autoCreateSubscriptionGroup = false15 # and dledger Related to the configuration of the 16 enabledlegercommitlog = true17storePathRootDir = / opt/application/rocketmq - all - 4.5.2 - bin - release/store/dledger_store1 8 dlegergroup = broker - a19dLegerPeers = n0-192.168.0.220:40911; N1-192.168.0.221:40911; N2-192.168.0.222:4091120 dlegerselfid = n2Copy the code

Tips: legerSelfId is N0, N1, and N2 respectively. In a real production environment, use separate root directories for storePathRootDir and storePathCommitLog in broker configuration files so that disk usage does not affect each other.

Step3: Copy all files under Store /config to the Congfig directory of Dledger Store.

1 CD/opt/application/rocketmq - all - 4.5.2 - bin - release/store / 2 cp config / * dledger_store/config / 3Copy the code

Tips: Copy this step according to the directory configured.

Step4: start three brokers in turn.

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

If the startup is successful, you can see the following cluster information in RocketMQ-Console:

3.3 Verifying message sending and message searching

First, we verify whether the message before the upgrade can be queried. Then, we still search for the message with key M600000, and the search result is shown in the figure:

Then let’s test message sending. The test code is as follows:

1public class Producer { 2 public static void main(String[] args) throws MQClientException, InterruptedException { 3 DefaultMQProducer producer = new DefaultMQProducer("producer_dw_test"); 4 producer. SetNamesrvAddr (" 192.168.0.220:9876; 192.168.0.221:9876 "); 5 producer.start(); 6 for(int i =600200; i < 600300; i ++) { 7 try { 8 Message msg = new Message("topic_dw_test_by_order_01",null , "m" + i,("Hello RocketMQ" + i ).getBytes(RemotingHelper.DEFAULT_CHARSET)); 9 SendResult sendResult = producer.send(msg); 10 System.out.printf("%s%n", sendResult); 11 } catch (Exception e) {12 e.printStackTrace(); 13 Thread.sleep(1000); 14 }15 }16 producer.shutdown(); 17 System.out.println("end"); 18}} 19Copy the code

The result is as follows:


During message sending, the master node is shut down, as shown in the following screenshot:

Wait for the replication group to re-elect the primary server and then continue processing messages.

Warm tip: In this example, messages are unavailable during the election period because the leader election period is one master and one slave. However, in a real production environment, the deployment architecture is multi-master and slave. That is, when a replication group elects a leader, other replication groups can replace the replication group to send messages and realize the high availability of message services.

DLedger related logs are stored in broker_default.log by default.

This article is introduced here, if you feel that the article is helpful, but also hope to help point [see], thank you.

RocketMQ DLedger multi-copy (primary/secondary switchover)

1. RocketMQ Multiple copy Preamps: Exploring raft protocol

2, source analysis RocketMQ multiple copy Leader selected master

3, source analysis RocketMQ DLedger multi-copy storage implementation

Source code analysis RocketMQ DLedger(multiple copies) log add-on process

Source code analysis RocketMQ DLedger(multi copy) log replication – part 1

Source code analysis RocketMQ DLedger(multi copy) log replication – part 2

Design principle of RocketMQ DLedger multi-copy log replication based on RAFT protocol

8. RocketMQ integration DLedger(Multiple copies) is a design technique for smooth upgrade through master/slave switching

9, source code analysis RocketMQ DLedger multiple copy that is the principle of master/slave switchover

More articles please pay attention to wechat public number: middleware interest circle.