TencentDB for MySQL
- Release Notes and Announcements
- Announcements
- Product Introduction
- Database Architecture
- Database Instance
- Kernel Features
- Kernel Version Release Notes
- Functionality Features
- Performance Features
- Parallel Query
- Security Features
- Stability Features
- Purchase Guide
- Getting Started
- Connecting to MySQL Instance
- Database Audit
- Audit Rule Template
- MySQL Cluster Edition
- Maintenance Management Instance
- Operation Guide
- Instance Management and Maintenance
- Instance Upgrade
- CPU Elastic Expansion
- Read-Only/Disaster Recovery Instances
- Database Proxy
- Database Proxy Kernel Features
- Database Proxy Management
- Automatic Read/Write Separation Feature
- Connection Pool Feature
- Other Features
- Account Management
- Database Management Center (DMC)
- Parameter Configuration
- Network and Security
- Backup and Rollback
- Restoring Database from Backup File
- Monitoring and Alarms
- Operation Logs
- Practical Tutorial
- Calling MySQL APIs in Python
- White Paper
- Performance White Paper
- Performance Test Report
- Troubleshooting
- Connections
- API Documentation
- Data Import APIs
- Rollback APIs
- Parameter APIs
- Making API Requests
- Instance APIs
- Database Proxy APIs
- Database Audit APIs
- Security APIs
- Account APIs
- Backup APIs
- Database APIs
- Monitoring APIs
- Log-related API
- FAQs
- Backup
- Connection and Login
- Instance Upgrade
- Performance and Memory
- Service Agreement
- Reference
Test Exception Event
Last updated: 2024-06-18 14:44:39
This document introduces the events related to test exceptions and corresponding handling suggestions when using TencentDB for MySQL.
Note:
Test Exception Events and Handling Suggestions
Chinese Name of Event | English Name of Event | Event Type | Dimension | Recovery Concept Availability | Event Description | Solutions and Suggestions |
Exception in Primary Node Service Test | MasterHealthCheckError | Exception Event | TencentDB for MySQL instance dimension | No | The primary instance may be unable to determine the current primary instance node service status as active due to high load, maximum number of connections reached, runtime exceptions, network fluctuations, etc. | The node configurations can be appropriately added to reduce the probability of risk occurrence. 1. If you receive a MasterHealthCheckRecovery event, it means that the primary node has been recovered, HA has been switched to rollback, and no actual HA has occurred. 2. If you receive both Switch and SlaveHealthCheckRecovery events, it indicates that HA switch has occurred and recovery succeeded. 3. If you receive a Switch event but do not receive a SlaveHealthCheckRecovery event, it means that HA has occurred and the original primary instance has been reconstructed. |
Primary Node Service Test Exception Recovery | MasterHealthCheckRecovery | Recovery event | TencentDB for MySQL instance dimension | No | Recovery after the database primary node encounters a service exception. | The service exception (MasterHealthCheckError) on the database primary node has been recovered and is now operating normally. |
Replica Node Service Test Exception | SlaveHealthCheckError | Exception Event | TencentDB for MySQL instance dimension | No | The replica instance might be unable to determine the current replica instance node service status as active due to high load, the maximum number of connections reached, runtime exceptions, and network fluctuations, etc. | Node configurations or the number of read-only nodes can be appropriately increased to reduce the probability of risk occurrence. 1. If you receive SlaveHealthCheckRecovery, it indicates that the replica node has been recovered. 2. If you have not received SlaveHealthCheckRecovery, it indicates that the replica node test has timed out and is being reconstructed. |
Replica Node Service Test Exception Recovery | SlaveHealthCheckRecovery | Recovery event | TencentDB for MySQL instance dimension | No | 1. Recovery after the database replica node encounters a service exception. 2. The original primary node is abnormal. After the primary-replica switchover, the originally abnormal primary node is recovered as the replica node. | 1. The service exception (SlaveHealthCheckError) on the database replica node has been recovered and is now operating normally. 2. The service exception (MasterHealthCheckError) on the database original primary node has been recovered and is now operating normally. |
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No