tencent cloud

Tencent Cloud Distributed Cache (Redis OSS-Compatible)

Release Notes and Announcements
Release Notes
Announcements
User Tutorial
Product Introduction
Overview
Product Strengths
Use Cases
Storage Engine
Product Series
Product Versions
Specifications and Performance
Read/Write Separation
Multi-AZ Deployment
Regions and AZs
Terms
Service Regions and Service Providers
Purchase Guide
Billing Overview
Pricing Center
Instance Purchasing
Renewal (Yearly/Monthly Subscription)
Refund (Yearly/Monthly Subscription)
Overdue Payments
Switching from Pay-as-You-Go to Yearly/Monthly Subscription
Getting Started
Quickly Creating an Instance
Connecting to Redis Instance
Operation Guide
Operation Overview
Connecting to a Database Instance
Managing Instances
Upgrade Instance
Management Node (Redis/ValKey Edition)
Multi-AZ Deployment Management
Backup and Restoration
Managing Accounts
Parameter Configuration
Slow Query
Access Management
Network and Security
Monitoring and Alarms
Event Management (Redis/ValKey Edition)
Data Migration
Global Replication for Redis Edition
Database Audit
Performance Optimization
Sentinel Mode
Development Guidelines
Naming Rules
Basic Usage Guidelines
Design Principles of Key and Value
Command Usage Guidelines
Design Principles of Client Programs
Connection Pool Configuration
Command Reference
Command Reference Overview
Redis Edition and Valkey Edition Command Compatibility
Version Command Usage Differences
Differences Between the Proxy Architecture and Direct Connection Mode
More Command Operations (Redis/Valkey Edition)
Memcached Edition Command Compatibility
Practical Tutorial
Building TencentDB for Redis® Client Monitoring Based on Spring Boot
Redis Client Connection Configuration Policy and Practice
Global SCAN Guide for Cluster Architecture
Eliminating Instances Securely
Hot Key and Big Key
AZ Migration Scheme
Troubleshooting
Connection Exception
Exception Analysis and Solution of Redisson Client Timeout Reconnection
Performance Troubleshooting and Fine-Tuning
API Documentation
History
Introduction
API Category
Making API Requests
Instance APIs
Parameter Management APIs
Other APIs
Backup and Restoration APIs
Region APIs
Monitoring and Management APIs
Log APIs
Data Types
Error Codes
FAQs
General
Connection and Login
Purchase
Service Agreement
Service Level Agreement
Terms of Service
Glossary
Contact Us

Use Limits

PDF
포커스 모드
폰트 크기
마지막 업데이트 시간: 2026-03-17 18:10:56

Limits on Region and AZ

The global replication feature can replicate data in the same AZ or across AZs between any Tencent Cloud regions no matter where instances in the replication group are deployed. Currently, only the following regions and AZs support global replication, and AZs of instances in a global replication group cannot be adjusted.
Region
AZ
Hong Kong (China)
Hong Kong Zones 2 and 3
Chengdu
Chengdu Zone 1
Silicon Valley
Silicon Valley Zone 2
Virginia
Virginia Zone 2
Shanghai
Shanghai Zones 4, 5, 6, and 7
Beijing
Beijing Zones 5 and 7
Guangzhou
Guangzhou Zones 4, 5, 6, and 7
Tianjin
Tianjin Zone 2
Nanjing
Nanjing Zones 2 and 3
Singapore
Singapore Zones 2 and 4
Shenzhen
Shenzhen Zone 4
Frankfurt
Frankfurt Zone 2
Bangkok
Bangkok Zone 2
São Paulo
São Paulo Zone 1

Limits on the version and architecture of global replication group instances

Global replication supports instances running on 4.0 Standard Architecture, 4.0 Cluster Architecture, 5.0 Standard Architecture, and 5.0 Cluster Architecture.
The architectures of instances in a replication group cannot be changed; for example, you cannot change an instance from Cluster Architecture to Standard Architecture.
The version and architecture of instances to be added to a replication group must be the same as those of the master instance specified during group creation.

Limits on the specifications of global replication group instances

It is recommended to set the number of shards for replication group instances to a power of 2, with a maximum value of 64, such as 8, 16, 32, or 64. Otherwise, uneven shard distribution may occur.
When creating a replication group, you must specify a master instance with at least two replicas for the group.
Currently, you can add up to four instances in a global replication group in the following deployment schemes: one master and three read-only instances, four master instances, or two master and two read-only instances.
The specifications of instances to be added to a replication group must be the same as those of existing instances in the group, and their memory capacity must be greater than or equal to the used capacity of the master instance specified during group creation.
When you change the specifications, all instances in a replication group must have the same specifications; otherwise, performance or capacity problems may occur.

Limits on the parameter settings

The maxmemory-policy parameter of instances in a global replication group must be set to noeviction.

Limits on Command Sync

The FLUSHDB or FLUSHALL command will be synced to all instances in the replication group. Therefore, run them with caution.
The Pub and Sub command groups will not be synced. We recommend that you use the Stream data structure to replicate notification messages across regions.
When the RESTORE command is synced, if the target instance has the same key, it will not be executed.

Other Limits

Currently, syncing is performed at the instance granularity, that is, all instance data will be synced. You cannot choose to sync partial instance data.
Instances with (Bloom Filter) or other (module) enabled cannot be added to a global replication group.

도움말 및 지원

문제 해결에 도움이 되었나요?

피드백