Overview
Last updated: 2025-10-11 14:26:39
In the high availability architecture of TencentDB for Redis®, the backend ensures service continuity (such as automatic recovery after physical server downtime or network jitter) through a second-level failover mechanism. The robustness of the client connection pool becomes a key bottleneck affecting business availability.
Fault Type | Business Scenario | TencentDB for Redis® Processing Mechanism | Challenge for Client | Impact on Business |
Active switchover | Compatible version upgrade, proxy version upgrade, and data migration. | It actively sends RST to reset the connection. | Detect interruption and reconnect it quickly. | Temporary jitter exists and can be quickly restored. |
Passive switchover | The physical server crashes unexpectedly. | It does not actively send RST to reset the connection. | Existing connections become "dead connections", which can be removed relying on the client's keepalive mechanism. | Recovery delay depends on the keepalive efficiency of the connection pool. |
To resolve the above issues, this solution provides a configuration policy for the client connection pool. Through client-side optimization, it reduces business unavailability time caused by passive switchovers from minutes to seconds, aligning with Tencent Cloud's service recovery capability.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No
Feedback