When you build data pipelines with materialized views at scale, operational problems are hard to avoid: latency spikes, silent refresh failures, and views that consume resources without delivering value. AnalyticDB for MySQL addresses these with full-lifecycle observability — real-time alerting, lineage-based root cause tracing, task history analysis, and access-based cost management.
Prerequisites
Cluster kernel version 3.2.6 or later.
Set up alerting for refresh failures and latency
The AnalyticDB for MySQL kernel monitors materialized view refresh tasks and automatically pushes anomaly events — task failures and latency breaches — to Alibaba Cloud Monitor. Alerts can be delivered in real time via SMS, DingTalk, Lark, and other channels.
Before you configure alerting, create a materialized view.
To configure latency alerting:
In the left navigation pane, choose Data Management > Data Catalog.
Click the database that contains the materialized view, then click the Materialized Views tab.
Click the view name to open the view details page.
Enable alerting on the details page, then go to Alibaba Cloud Monitor and complete the event subscription with these settings:
Field Value Subscription type System event Product AnalyticDB for MySQL 3.0 Event type Anomaly Event name Materialized View Refresh Task Failed or Timeout Event level Critical/Alert
Trace anomalies using data lineage
For pipelines with nested materialized view refreshes, the console provides a DAG view that shows the complete dependency graph of a materialized view — all parent tables, base tables, and upstream materialized views, recursively. When a downstream view experiences latency, use the DAG graph to walk upstream and identify which node is the source of the delay.
To open the lineage graph:
In the left navigation pane, choose Data Management > Data Catalog.
Click the database that contains the materialized view, then click the Materialized Views tab.
Click the view name, then select the Lineage tab.
Diagnose task stacking
Refresh tasks can run longer than expected during peak write periods, when I/O resource contention is high or computing resources are insufficient. The result is a backlog of queued tasks. The following methods help you determine whether a task is running abnormally.
View refresh history in the console
On the Refresh Policy tab of the materialized view details page, the refresh history shows the status of each task.
Refresh task statuses
| Status | Description |
|---|---|
| PENDING | Waiting for the scheduling cycle to start. Resources have not been allocated yet. |
| RUNNING | Entered the scheduling cycle. Computing resources are being allocated or are already executing. |
| FINISHED | Refresh completed successfully. |
| FAILED | Refresh failed. The system retries automatically up to 10 times. If all retries fail, the current task is skipped. For incremental views, the next refresh rescans missing data to ensure eventual consistency. |
| TIMEOUT | The task did not complete within the expected time. The system marks it as timed out and triggers it again. Submit a ticket for further troubleshooting. |
Two refresh policies are available. For a comparison, see Select a refresh policy.
| Policy | Description |
|---|---|
| COMPLETE | Full refresh |
| FAST | Incremental refresh |
Query refresh records using SQL
Use the following query to retrieve auto-refresh task records for a specific materialized view:
-- Query auto-refresh tasks for a specified materialized view
-- mv_schema: database name where the materialized view is located
-- mv_name: name of the materialized view
SELECT * FROM information_schema.mv_auto_refresh_jobs
WHERE mv_schema = 'db_name' AND mv_name = 'mv_name';To determine whether a task is running abnormally, compare the current task duration against the historical average:
Find the latest task (typically in
PENDINGorRUNNINGstatus).Calculate the average duration of completed tasks:
end_time - start_time.Calculate the current task's elapsed time: if
RUNNING, usecurrent_time - start_time.If the current duration is significantly higher than the historical average, the task may be abnormal and requires further diagnosis.
For more information, see Query the refresh history of materialized views.
Identify low-value views for cost management
When many materialized views exist in a cluster, access statistics help you identify views that are rarely or never used, so you can decide whether to keep or remove them.
View access statistics in the console
On the Query Popularity tab of the materialized view details page, access metrics are shown for the last 7 days, updated hourly.
Two access types are tracked:
| Metric | Description |
|---|---|
Explicit access (explicit_hit) | A user SQL query directly references this materialized view, including parent view references to child views in nested refreshes. |
Implicit access (implicit_hit) | The query rewrite mechanism automatically selects this materialized view to accelerate a query, without the user explicitly naming it. |
Query access statistics using SQL
Use the following query to retrieve hit statistics for a specific materialized view:
-- Query hit statistics for a specified materialized view
-- explicit_hit: number of times a user query directly referenced this view
-- implicit_hit: number of times the query rewrite optimizer selected this view
SELECT explicit_hit, implicit_hit
FROM mv_info
WHERE mv_name = 'mv_db';A view with consistently low explicit_hit and implicit_hit counts is a candidate for cleanup. Zero access over an extended period indicates the view provides no measurable business value while continuously consuming CPU and storage.