This page answers common questions about monitoring in AnalyticDB for MySQL.
Unless a product edition is specified, the answers on this page apply to Data Warehouse Edition only.
FAQ overview
How do I monitor disk usage for a Data Warehouse Edition cluster in reserved mode?
This applies to Data Warehouse Edition clusters in reserved mode only. Enterprise Edition, Basic Edition, and Data Lakehouse Edition clusters do not require disk monitoring alerts.
Set up a CloudMonitor alert rule to receive notifications before disk usage reaches a critical level.
Log on to the AnalyticDB for MySQL console. In the upper-left corner, select a region. In the left-side navigation pane, click Clusters, then click the cluster ID.
In the left-side navigation pane, click Monitoring and Alerts.
On the Monitoring and Alerts page, check the current disk usage.
In reserved mode, disk usage is displayed as a percentage. In elastic mode, the absolute disk usage of the read/write nodes is displayed.
Reserved mode
NoteThe maximum disk usage is the highest disk usage among all nodes in the cluster. If the value is 90% or higher, the disk is locked. Pay close attention to this metric.
Elastic mode
NoteThe disk usage is the maximum disk usage of a single read/write node. If the value is 8 TB or higher, data cannot be written to the cluster. Pay close attention to this metric.
Click the Alerts tab, then click Create Alert Rule.
In the Create Alert Rule panel, configure the parameters described in the following table.
Parameter Description Resource Range The resources the alert rule applies to. All Resources applies the rule to all clusters in your account (up to 1,000 resources per service). If your account contains more than 1,000 resources of the specified service, the system may not generate an alert regardless of whether the rule conditions are met. Before you configure the alert rule, we recommend that you classify resources into different application groups. Instances applies the rule to specific clusters only. Rule Description The conditions that trigger the alert. Click Add Rule, configure Alert Rule, Metric Type, Metric, Threshold and Alert Level, and Chart Preview in the Configure Rule Description panel, then click OK. Mute Period How long CloudMonitor waits before resending an alert notification while the alert remains active. If the alert is triggered within the mute period, CloudMonitor does not resend an alert notification. If the alert is not cleared after the mute period ends, CloudMonitor resends alert notifications. Valid values: 5 Minutes, 15 Minutes, 30 Minutes, 60 Minutes, 3 Hours, 6 Hours, 12 Hours, and 24 Hours. Effective Period The time window during which CloudMonitor evaluates the alert rule. Each contact receives up to four disk usage alert notifications per day. Alert Contact Group The contact group that receives alert notifications. For how to create contacts and groups, see Create an alert contact or alert contact group. Alert Callback (Optional — click Advanced Settings) A publicly accessible HTTP URL. CloudMonitor sends a POST request to this URL when an alert is triggered. For configuration details, see Use the alert callback feature to send notifications about threshold-triggered alerts. Auto Scaling (Optional — click Advanced Settings) When enabled, triggers a scaling rule when an alert fires. Requires Region, ESS Group, and ESS Rule. For setup, see Manage scaling groups and Configure scaling rules. Log Service (Optional — click Advanced Settings) When enabled, writes alert information to Simple Log Service. Requires Region, Project Name, and Logstore. For setup, see Collect and analyze ECS text logs using LoongCollector. Simple Message Queue (formerly MNS) - Topic When enabled, writes alert information to a Message Service topic. Select a region and topic. For how to create a topic, see Create a topic. Method to handle alerts when no monitoring data is found (Optional — click Advanced Settings) Specifies behavior when no monitoring data exists. Valid values: Do not do anything (default), Send alert notifications, and Treated as normal. Tag Key-value pairs added to alert notifications. Multiple pairs are supported. Click Confirm.
How do I view storage used for hot data and cold data?
Log on to the AnalyticDB for MySQL console. On the Monitoring and Alerts page, check the Disk Space Used chart — it shows Hot Data Size and Cold Data Size as separate metrics.
How do I check table size information?
Log on to the AnalyticDB for MySQL console. Navigate to Storage Analysis > Storage Overview for the cluster, then click the Table Storage Information tab.
Why is the hot data usage greater than the total data usage on the Monitoring Information page?
The two metrics measure different things:
Disk Data Usage shows the maximum usage of a single read/write node.
Hot Data Usage shows the combined usage across all read/write nodes.
If your cluster has multiple read/write nodes, Hot Data Usage will naturally exceed Disk Data Usage because it sums all nodes.
Why does average CPU utilization increase after a cluster switches from reserved mode to elastic mode?
When a C32 cluster switches from reserved mode to elastic mode, each node's core count drops to 8. Because BUILD jobs use 3 cores by default, they consume a higher proportion of available cores — raising the average CPU utilization reading.
If the increase does not affect your workload, no action is needed. If queries are slowing down, upgrade the cluster or submit a ticket for technical support. For more information about BUILD jobs, see BUILD.
Why does the Monitoring Information page show a long query response time, but no slow SQL query appears on the Diagnostics and Optimization page?
The two pages measure query time differently:
Query Response Time (Monitoring Information page): includes the time to cache the result set after query execution.
Total Duration (Diagnostics and Optimization page): does not include result-caching time.
For queries that return large result sets, caching can add significant time to Query Response Time without appearing in Total Duration. To find slow SQL queries, check the SQL Audit page.
To understand where time is spent in a query, AnalyticDB for MySQL processes SQL queries through these stages:
| Stage | Description |
|---|---|
| Queue | The query waits in a queue. High concurrency can cause long wait times. |
| Parse and plan | The execution engine parses the statement and generates an execution plan. |
| Execute | Subtasks run on storage and compute nodes. |
| Cache results | For large result sets, frontend nodes cache the data before returning it. This step contributes to Query Response Time but not to Total Duration. |
The following figure shows the time breakdown of an SQL query: