TDMQ for Apache Pulsar
- Release Notes and Announcements
- Product Introduction
- Purchase Guide
- Pricing Overview
- Pro Cluster
- Getting Started
- Using SDK to Send and Receive Normal Messages
- Developer Guide
- How It Works
- Operation Guide
- Cluster Management
- Monitoring and Alarms
- Permission Management
- Pulsar Instance Permission Management
- Cross-Region Replication
- Practical Tutorial
- API Documentation
- Making API Requests
- Cluster APIs
- Namespace APIs
- CMQ Management APIs
- Environment Role APIs
- TDMQ for RabbitMQ APIs
- RocketMQ APIs
- TDMQ for RocketMQ APIs
- Production and Consumption APIs
- SDK Documentation
- Apache Pulsar TCP Protocol
- General References
DocumentationTDMQ for Apache PulsarOperation GuideCluster MigrationSingle Write and Multiple Read Migration Solution
Single Write and Multiple Read Migration Solution
Last updated: 2025-04-01 14:18:35
This document provides an overview of feasible solutions for migrating between different clusters. You can choose the migration solution that suits your business scenario.
Application Scenarios
1. Unable to migrate at the virtual cluster level.
2. Hope to migrate resources under a virtual cluster to different Professional Edition Clusters.
3. Self-built Pulsar to Tencent Cloud Pulsar.
Single-Write Multiple-Read Solution
The overall solution is simple and clear, easy to implement, with no data backlog and a smooth transition. Under this solution, users can have more flexible control over the resource granularity and grayscale method of migration.
Migration Process
1. Start up business consumers that connect to the new cluster access point (dual-read, with consumers consuming data from both the old and new clusters simultaneously).
2. Modify the access point address of the original producer to the new cluster and restart it, making new messages produced to the new cluster, until all producers of the original cluster are modified/closed (switch writing, switching production flow from the old cluster to the new cluster).
3. Pay attention to the message backlog situation of the original cluster.
4. After there are no backlog messages in the original cluster, the consumers of the old cluster can be closed. At this point, the business has been migrated to the new cluster (single-read, with consumers only consuming from the new cluster).
5. Upon migration completion, delete the existing cluster.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No