Migrating RocketMQ Instance Metadata from Others
Scenario
Migrate metadata from a third-party or self-hosted RocketMQ instance to DMS for RocketMQ.
You can use one of the following migration methods as required:
- Method 1: Run the mqadmin command to export the source instance metadata and then create a migration task in DMS for RocketMQ.
- Method 2: Export the source topics and consumer groups and then import them to DMS for RocketMQ using scripts. (Use this method when metadata cannot be exported using the mqadmin command.)
Prerequisites
- A RocketMQ instance has been purchased.
- A Linux host is available, JDK v1.8.111 or later has been installed on the host, and related environment variables have been configured.
Method 1: Run the mqadmin Command to Export the Source Instance Metadata and Then Create a Migration Task in DMS for RocketMQ
Obtain the RocketMQ metadata from another cloud or self-hosted RocketMQ.
- Log in to the host and download the RocketMQ software package.
wget https://archive.apache.org/dist/rocketmq/4.9.8/rocketmq-all-4.9.8-bin-release.zip
- Decompress the software package.
unzip rocketmq-all-4.9.8-bin-release.zip
- (Optional) If ACL is enabled for the RocketMQ instance, authentication is required when you run the mqadmin command.
Switch to the directory where the decompressed software package is stored and add the following content to the conf/tools.yml file:
accessKey:******* secretKey:*******
accessKey and secretKey are the username and secret key set on the Users page of the console.
- Go to the directory where the decompressed software package is stored and run the following command to query the cluster name:
sh ./bin/mqadmin clusterList -n {nameserver address and port number}
For example, if the nameserver address and port number are 192.168.0.65:8100, run the following command:
sh ./bin/mqadmin clusterList -n 192.168.0.65:8100
- Run the following command to export metadata:
- If SSL is disabled, run the following command:
sh ./bin/mqadmin exportMetadata -n {nameserver address and port number} -c {RocketMQ cluster name} -f {Path for storing the exported metadata file}
For example, if the nameserver address and port number are 192.168.0.65:8100, the RocketMQ cluster name is DmsCluster, and the path for storing exported metadata files is /tmp/rocketmq/export, run the following command:
sh ./bin/mqadmin exportMetadata -n 192.168.0.65:8100 -c DmsCluster -f /tmp/rocketmq/export
- If SSL is enabled, run the following command:
JAVA_OPT=-Dtls.enable=true sh ./bin/mqadmin exportMetadata -n {nameserver address and port number} -c {RocketMQ cluster name} -f {path for storing the exported metadata file}
For example, if the nameserver address and port number are 192.168.0.65:8100, the RocketMQ cluster name is DmsCluster, and the path for storing exported metadata files is /tmp/rocketmq/export, run the following command:
JAVA_OPT=-Dtls.enable=true sh ./bin/mqadmin exportMetadata -n 192.168.0.65:8100 -c DmsCluster -f /tmp/rocketmq/export
- If SSL is disabled, run the following command:
Migrate metadata on the console.
- Log in to the console.
- Click
in the upper left corner to select a region.
Select the region where your RocketMQ instance is located.
- Click
and choose Middleware > Distributed Message Service for RocketMQ to open the console of DMS for RocketMQ.
- Click a RocketMQ instance to go to the instance details page.
- In the navigation pane, choose Metadata Migration.
- Click Create Migration Task.
- Configure the migration task by referring to Table 1.
Table 1 Migration task parameters Parameter
Description
Task Type
Select From self-built RocketMQ to cloud.
Task Name
Unique name of the migration task.
Overwrite
- If this option is enabled, configurations in the metadata file with the same name as the uploaded file will be modified.
Assume that Topic01 on the source instance has three read queues, and Topic01 on the DMS instance has two read queues. If Overwrite is enabled, Topic01 on the DMS instance will have three read queues after migration.
- If this option is disabled, migration of the metadata file with the same name as the uploaded file will fail.
Assume that the source instance has Topic01 and Topic02, and the DMS instance has Topic01 and Topic03. If Overwrite is disabled, migration of the source Topic01 will fail.
Metadata
Upload the RocketMQ metadata obtained from another cloud or self-hosted RocketMQ.
- If this option is enabled, configurations in the metadata file with the same name as the uploaded file will be modified.
- Click OK.
After the migration is complete, view Task Status in the migration task list.
- If Task Status is Complete, all metadata has been successfully migrated.
- If Task Status is Failed, some or all metadata fails to be migrated. Click the migration task name to go to the migration task details page. In the Migration Result area, view the name of the topic or consumer group that fails to be migrated and the failure cause.
- Migrate the production service to the RocketMQ instance.
Change the metadata connection address on the production client to the metadata connection address of the RocketMQ instance and then restart the production service. New messages will be sent to the RocketMQ instance.
- Migrate the consumption service to the RocketMQ instance.
After all messages in the consumer group are consumed, change the metadata connection address of the consumer client to the metadata connection address of the RocketMQ instance. New messages will be consumed from the RocketMQ instance.
- If there are multiple source RocketMQ instances, migrate services from them one by one.
Method 2: Export the Source Topics and Consumer Groups and Import Them to DMS for RocketMQ Using Scripts
- Log in to the console of another vendor and export the lists of source topics and consumer groups.
- Create the topics.txt and groups.txt files and add the source topic list and consumer group list to the files respectively. Each line contains a topic or consumer group name. For example:
topic-01 topic-02 ... topic-n
Note: The groups.txt file cannot contain blank lines (for example, a newline character at the end of a consumer group name). Otherwise, consumer groups with empty names will be created when the lists are imported to the RocketMQ instance.
- Log in to the host and download the RocketMQ software package.
wget https://archive.apache.org/dist/rocketmq/4.9.8/rocketmq-all-4.9.8-bin-release.zip
- Decompress the software package.
unzip rocketmq-all-4.9.8-bin-release.zip
- (Optional) If ACL is enabled for the RocketMQ instance, authentication is required when you run the mqadmin command.
Switch to the directory where the decompressed software package is stored and add the following content to the conf/tools.yml file:
accessKey:******* secretKey:*******
accessKey and secretKey are the username and secret key set on the Users page of the console.
- Go to the bin directory of the decompressed software package and upload topics.txt and groups.txt to this directory.
- Run the following script to import the source topics and consumer groups to DMS for RocketMQ:
#!/bin/bash # Read groups from groups.txt file groups=() while read -r group; do groups+=("$group") done < "groups.txt" # Read topics from topic.txt file topics=() while read -r topic; do topics+=("$topic") done < "topics.txt" # Add topics for topic in "${topics[@]}"; do echo "Adding topic: $topic" sh mqadmin updateTopic -n <namesrvIp:8100> -c DmsCluster -t "$topic" done # Add consumer groups for group in "${groups[@]}"; do echo "Adding consumer group: $group" sh mqadmin updateSubGroup -n <namesrvIp:8100> -c DmsCluster -g "$group" done
namesrvIp:8100 indicates the address of the RocketMQ instance.
- Log in to DMS for RocketMQ console. Go to the Topics and Consumer Groups pages and check whether the topics and consumer groups are successfully imported.
- Migrate the production service to the RocketMQ instance.
Change the metadata connection address on the production client to the metadata connection address of the RocketMQ instance and then restart the production service. New messages will be sent to the RocketMQ instance.
- Migrate the consumption service to the RocketMQ instance.
After all messages in the consumer group are consumed, change the metadata connection address of the consumer client to the metadata connection address of the RocketMQ instance. New messages will be consumed from the RocketMQ instance.
- If there are multiple source RocketMQ instances, migrate services from them one by one.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot