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
DocumentationTencentDB for MySQLRelease Notes and AnnouncementsAnnouncementsNotice on Elimination of Some Indicators in Event Alarms
Notice on Elimination of Some Indicators in Event Alarms
Last updated: 2024-06-18 14:03:34
Notice on Elimination of Some Indicators in Event Alarms
Last updated: 2024-06-18 14:03:34
Dear Tencent Cloud users, to provide you with more accurate and comprehensive event alarm descriptions, TencentDB for MySQL plans to eliminate the following four event indicators on July 1, 2024: "MasterNotAvailable", "MasterNotAvailableRecovery", "SlaveNotAvailable", and "SlaveNotAvailableRecovery", and will optimize them to "MasterHealthCheckError", "MasterHealthCheckRecovery", "SlaveHealthCheckError", and "SlaveHealthCheckRecovery" respectively. The alarm principles of the involved event indicators will remain unchanged; this optimization is only for event names, descriptions, handling methods, and recommendations to better assist you in understanding.
Note:
After the elimination of the involved event indicators, you will need to reset the event alarms for the four new indicators: "MasterHealthCheckError," "MasterHealthCheckRecovery," "SlaveHealthCheckError," and "SlaveHealthCheckRecovery." For the operation guide, please refer to Setting Event Alarms.
Elimination Time
Beijing Time, Monday, July 01, 2024.
Information of Optimized Related Events Indicators
Event English Name | Event Type | Subordinate Dimension | Recovery Concept Availability | Event Description | Solution and Suggestion |
MasterHealthCheckError | Abnormal event | TencentDB for MySQL instance dimension | No | The primary instance may be unable to determine whether the current primary instance node service status is active due to high load, maximum number of connections reached, runtime exceptions, network fluctuations, etc. | Node configurations can be increased appropriately to reduce the probability of risks. 1. If you receive a MasterHealthCheckRecovery event, it means that the primary node has recovered, HA switch rollback has occurred, 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 switch has occurred and the original primary instance has been rebuilt. |
MasterHealthCheckRecovery | Recovery event | TencentDB for MySQL instance dimension | No | Recovery after the database primary node encounters a service exception. | The database MasterHealthCheckError has recovered from the service exception and is now operating normally. |
SlaveHealthCheckError | Abnormal event | TencentDB for MySQL instance dimension | No | The replica instance may be unable to determine whether the current replica instance node service status is active due to high load, maximum number of connections reached, runtime exceptions, network fluctuations, etc. | Node configurations or the number of read-only nodes can be increased appropriately to reduce the probability of risks. 1. If you receive SlaveHealthCheckRecovery, it indicates the replica node has recovered. 2. If you does not receive SlaveHealthCheckRecovery, it indicates that the replica node health check has timed out and been rebuilt. |
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 switch, the original abnormal primary node recovers as a replica node. | 1. The database SlaveHealthCheckError has recovered from the service exception and is now operating normally. 2. The original MasterHealthCheckError of the database has recovered from the service exception and is now operating normally. |
Impact
This update will not affect your business database usage. If you have set up alarms for event indicators that are to be eliminated before July 1, 2024, these alarms will not be triggered after the elimination. Please ensure to set up alarms for the new event indicators timely. If you haven't set up alarms for the event indicators that are to be eliminated before July 1, 2024, we recommend you set up alarms for the new event indicators by then, to help you more clearly detect health check errors.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No