Cluster Version Updates
Last updated: 2025-04-01 11:10:06
This document describes the updates to TDMQ for Apache Pulsar clusters as well as relevant notes.
2.9.2 Version
Release Date: January 2023
Full switch: Pending
Update description:
Update type | update point | Detailed Description |
Optimization | Engine version upgrade | Upgrade the stable version of the community engine version, follow the community to fix key issues, such as graceful restart of Broker, upgrade of Bookie version, optimization of key_shared subscription mode, and inability to scale in unack map. |
Add | Topic TTL | Introduce Topic Policy, support finer-grained Message TTL, and users can configure flexibly. The feature is in productization. |
Add | Consumption Monitoring Alarm | Add new consumption monitoring metrics on the backend and enhance cluster monitoring capability |
Optimization | Performance Optimization | Optimize the sequentiality guarantee in key_shared subscription mode Enhance server-side processing performance under large-scale message backlog Enhance multi-AZ disaster recovery speed Optimize caching strategy, enhance consumption performance |
Version 2.7.1
Release date: May 17, 2021
Full switch: June 2021
Release notes:
Update Type | Update | Description | Documentation |
Optimization | Unified domain name access | A unique domain name is automatically generated for each network environment of each cluster as the access address, so you don't need to manually create and manage access points. The dependency that declares listenerName is removed, so the SDK is more compatible with TCP clients in the community that are not adapted to multiple advertised listeners in Pulsar (including C++, Python, and Node.js). | |
Addition | Support for public network access | Public network access is supported, so you can access a TDMQ for Apache Pulsar cluster in Tencent Cloud from a TCP client in your local system or self-built IDC. | |
Optimization | Update to the naming conventions for the retry letter and dead letter topics | The naming conventions for the retry letter and dead letter topics are updated to the same as used by the Pulsar community, so that they are more compatible with open-source SDKs (the new naming conventions are not applicable to the original Tencent Cloud SDK) | |
Optimization | Performance optimization | Clusters on v2.7.1 are optimized at the system kernel level to achieve a 20% higher peak production/consumption performance than clusters on v2.6.x. In addition, they can be scaled imperceptibly according to the actual usage. | - |
Addition | Support for protocol-compatible plugins (in closed beta test) | You can install plugins compatible with AMQP, RocketMQ, and CMQ in clusters on v2.7.1. Currently, this feature is in beta test. After it is officially launched, you will be able to access TDMQ for Apache Pulsar from popular message queue clients with no modifications required, which will make it easier for you to migrate existing businesses. | - |
Version 2.6.1
Release date: October 12, 2020
Full switch: October 2020
Release notes:
Update Type | Update | Description | Documentation |
Optimization | Stability enhancement | Issues discovered during the beta test are fixed, significantly improving the cluster stability. | - |
Optimization | Hot/Cold data isolation in ZooKeeper | The ZooKeeper component of the Pulsar kernel adopts the deployment architecture of hot/cold data isolation, where metadata and cluster broker configuration data are deployed separately in two ZooKeeper instances to increase the cluster stability. | - |
Addition | Support for creation of virtual clusters | You can create virtual clusters in the console for resource isolation. | - |
Upgrade notes:
All newly created clusters will be automatically on the latest version in the current region.
To switch to the new cluster version on your own, follow the steps below:
1. Create a cluster (all newly created clusters are on the latest version) and a copy of completely identical metadata (namespaces, role permissions, topics, and subscriptions).
2. Replace the original production/consumption access point in the client code with the access address of the new cluster.
3. Replace the authentication information (token) in the client code with the token of the new cluster.
4. Switch the producer client first (recreate a producer application and deploy it in the production environment).
5. Wait for all retained messages in the original cluster to be consumed and then switch the consumer client (recreate a consumer application and deploy it in the production environment).
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No