Release Notes
Announcements
Overview
Tencent Cloud Distributed Cache supports global replication for consistent data sync across regions.
Note：
Global replication is currently undergoing architectural upgrades to continuously enhance system high availability and disaster recovery capabilities.
Why Global Replication
When the native code of Redis performs cross-region replication, if the local instance is written excessively or is disconnected from replication for a long time, the
backlog of the master node may not be able to resume the replication, resulting in mandatory full replication by the remote instance. This will block access to and seriously affect the normal business of the remote instance. For more information, see Replication.In addition, Redis' native replication scheme does not mark written nodes in the
backlog, which tends to cause replication loops and data inconsistency when two-way replication is required between the local and remote instances.Implementation Mechanism
Global replication is a new feature added to the open-source version of the kernel by Tencent Cloud. It is fully compatible with Redis 4.0 and Redis 5.0 commands. Based on the original leader-follower replication scheme, a new log file is added for remote replication to ensure the eventual data consistency for instances in any region in the replication group.
Before the log file is replicated by the remote node, the local node will keep it to ensure the continuity of remote replication.
The log file contains the
ServerID to identify the ID of the node to which the log file is written and supports two-way replication to avoid replication loops.The log file contains the command execution timestamp and the version number of the operation
KEY to resolve command conflicts.
Use Cases
Read-only instance and disaster recovery
In the global replication scheme of Tencent Cloud Distributed Cache, a master instance is configured in a replication group, while read-only instances are deployed in multiple regions and replicate data from the master instance. The data version is based on the master instance, and the data consistency level is eventual consistency. This allows you to access data locally with a quicker response, better experience, higher data availability, and greater data security.
Note：
Shard Quantity: For disaster recovery scenarios, it is recommended that the number of shards in the primary instance and the disaster recovery instance of the global replication group be set to a power of 2, with a maximum value of 64, such as 8, 16, 32, 64. Otherwise, it may lead to uneven shard storage capacity.
Transaction Commands: The transaction operations of global replication, compared to ordinary Redis transactions, will result in a certain degree of database performance degradation.
Multi-Key Commands: In global replication instances, multi-key commands are split by Slot. Compared to non-global replication group database instances, performance decreases, and the decrease ratio is related to the number of splits. The more splits, the greater the performance degradation.
Data Consistency: The version of the data is based on the primary instance, and the level of data consistency is the final data consistency. When the master-slave node link of the primary instance fails, the remote replication of the disaster recovery instance will also be affected by delay. For business scenarios with high database consistency requirements, it is strongly recommended not to perform read operations on the disaster recovery instance.
Eviction Policy: Global replication does not support setting the eviction policy `maxmemory-policy`. If eviction is required, please use the `del` delete command to clear the Key.
Latency Description: In global replication, the synchronization delay between the master node and the replica node of the primary instance will affect the remote synchronization delay between the primary instance and the disaster recovery instance. The delay duration theoretically does not exceed 500ms.
Monitoring Metrics: Supports monitoring of command quantity deviation during the remote synchronization process between the primary instance and the disaster recovery instance, as well as synchronization delay monitoring. For specific information, please refer to Monitoring Metrics.
Multi-master architecture
If you need to roam and merge data across regions, you need to distribute the same copy of data in multiple regions, read and update data in any region, or merge data from multiple regions. In this case, the database should have the ability to write data in multiple regiRons. In a global replication group, you can configure a multi-master architecture, so data written to one master instance will be synced to other master instances in other regions.
Note:
In a multi-master (global replication) architecture, when processing write commands from local applications or synchronized from other master instances, the Redis master instance does not perform data version detection or timestamp verification. All commands are executed sequentially solely based on the order in which they are received by the local instance.
If the business system updates the same data (Key) across different master instances simultaneously, data inconsistency or unexpected overwrites may occur after global synchronization, and absolute data consistency cannot be guaranteed.
Business Recommendations: Before this feature is enabled, carefully evaluate the business scenarios. During application layer design, it is essential to avoid concurrent updates to the same data across instances (it is recommended to achieve this through data Sharding by region or user routing binding).
피드백