跳到主要内容
版本: 最新版本-3.5

管理告警

本主题介绍来自不同维度的各种告警项，包括业务连续性、集群可用性和机器负载，并提供相应的解决方案。

注意

在以下示例中，所有变量都以 $ 为前缀。 应该根据您的业务环境进行替换。 例如，$job_name 应替换为 Prometheus 配置中相应的 Job Name，$fe_leader 应替换为 Leader FE 的 IP 地址。

服务中断告警​

FE 服务中断​

PromSQL

count(up{group="fe", job="$job_name"}) >= 3

告警描述

当活动 FE 节点的数量低于指定值时，会触发告警。 您可以根据 FE 节点的实际数量调整此值。

解决方案

尝试重启已暂停的 FE 节点。

BE 服务中断​

PromSQL

node_info{type="be_node_num", job="$job_name",state="dead"} > 1

告警描述

当多个 BE 节点暂停时，会触发告警。

解决方案

尝试重启已暂停的 BE 节点。

机器负载告警​

BE CPU 告警​

PromSQL

(1-(sum(rate(starrocks_be_cpu{mode="idle", job="$job_name",instance=~".*"}[5m])) by (job, instance)) / (sum(rate(starrocks_be_cpu{job="$job_name",host=~".*"}[5m])) by (job, instance))) * 100 > 90

告警描述

当 BE CPU 利用率超过 90% 时，会触发告警。

解决方案

检查是否存在大型查询或大规模数据加载，并将详细信息转发给支持团队进行进一步调查。

  1. 使用 top 命令检查进程的资源使用情况。

    top -Hp $be_pid

  2. 使用 perf 命令收集和分析性能数据。

    # Execute the command for 1-2 minutes, and terminate it by pressing CTRL+C.
    sudo perf top -p $be_pid -g >/tmp/perf.txt
注意

在紧急情况下，要快速恢复服务，您可以尝试在保留堆栈后重启相应的 BE 节点。 此处的紧急情况是指 BE 节点的 CPU 利用率仍然异常高，并且没有有效的手段来降低 CPU 使用率的情况。

内存告警​

PromSQL

(1-node_memory_MemAvailable_bytes{instance=~".*"}/node_memory_MemTotal_bytes{instance=~".*"})*100 > 90

告警描述

当内存使用量超过 90% 时，会触发告警。

解决方案

参考 获取堆配置文件 进行故障排除。

注意
  • 在紧急情况下，您可以尝试重启相应的 BE 服务以恢复服务。 此处的紧急情况是指 BE 节点的内存使用率仍然异常高，并且没有有效的手段来降低内存使用率的情况。
  • 如果其他混合部署的服务影响系统，您可以考虑在紧急情况下终止这些服务。

磁盘告警​

磁盘负载告警​

PromSQL

rate(node_disk_io_time_seconds_total{instance=~".*"}[1m]) * 100 > 90

告警描述

当磁盘负载超过 90% 时，会触发告警。

解决方案

如果集群触发 node_disk_io_time_seconds_total 告警，首先检查是否存在任何业务变更。 如果是，请考虑回滚更改以维持之前的资源平衡。 如果未发现任何更改或无法回滚，请考虑正常的业务增长是否推动了资源扩展的需求。 您可以使用 iotop 工具来分析磁盘 I/O 使用情况。 iotop 具有类似于 top 的 UI，并包含 pid、user 和 I/O 等信息。

您还可以使用以下 SQL 查询来识别消耗大量 I/O 的 Tablet，并将其追溯到特定任务和表。

-- "all" indicates all services. 10 indicates the collection lasts 10 seconds. 3 indicates fetching the top 3 results.
ADMIN EXECUTE ON $backend_id 'System.print(ExecEnv.io_profile_and_get_topn_stats("all", 10, 3))';

根路径容量告警​

PromSQL

node_filesystem_free_bytes{mountpoint="/"} /1024/1024/1024 < 5

告警描述

当根目录中的可用空间小于 5GB 时，会触发告警。

解决方案

可能占用大量空间的常见目录包括 /var、**/**opt 和 /tmp。 使用以下命令检查大文件并清除不必要的文件。

du -sh / --max-depth=1

数据磁盘容量告警​

PromSQL

(SUM(starrocks_be_disks_total_capacity{job="$job"}) by (host, path) - SUM(starrocks_be_disks_avail_capacity{job="$job"}) by (host, path)) / SUM(starrocks_be_disks_total_capacity{job="$job"}) by (host, path) * 100 > 90

告警描述

当磁盘容量利用率超过 90% 时，会触发告警。

解决方案

  1. 检查加载的数据量是否发生变化。

    监控 Grafana 中的 load_bytes 指标。 如果数据加载量显着增加，您可能需要扩展系统资源。

  2. 检查是否有任何 DROP 操作。

    如果数据加载量没有太大变化，请运行 SHOW BACKENDS。 如果报告的磁盘使用情况与实际使用情况不符，请检查 FE 审计日志中最近的 DROP DATABASE、TABLE 或 PARTITION 操作。

    这些操作的元数据在 FE 内存中保留一天，允许您在 24 小时内使用 RECOVER 语句恢复数据，以避免误操作。 恢复后，实际磁盘使用量可能会超过 SHOW BACKENDS 中显示的使用量。

    可以使用 FE 动态参数 catalog_trash_expire_second（默认值：86400）调整内存中已删除数据的保留期限。

    ADMIN SET FRONTEND CONFIG ("catalog_trash_expire_second"="86400");

    要持久化此更改，请将配置项添加到 FE 配置文件 fe.conf。

    之后，已删除的数据将被移动到 BE 节点上的 trash 目录 ($storage_root_path/trash)。 默认情况下，已删除的数据在 trash 目录中保留一天，这也可能导致实际磁盘使用量超过 SHOW BACKENDS 中显示的使用量。

    可以使用 BE 动态参数 trash_file_expire_time_sec（默认值：86400）调整 trash 目录中已删除数据的保留时间。

    curl http://$be_ip:$be_http_port/api/update_config?trash_file_expire_time_sec=86400

FE 元数据磁盘容量告警​

PromSQL

node_filesystem_free_bytes{mountpoint="${meta_path}"} /1024/1024/1024 < 10

告警描述

当 FE 元数据的可用磁盘空间小于 10GB 时，会触发告警。

解决方案

使用以下命令检查占用大量空间的目录并清除不必要的文件。 元数据路径由 fe.conf 中的 meta_dir 配置指定。

du -sh /${meta_dir} --max-depth=1

如果元数据目录占用大量空间，通常是因为 bdb 目录很大，可能是由于 CheckPoint 失败。 请参阅 CheckPoint 失败告警 进行故障排除。 如果此方法无法解决问题，请联系技术支持团队。

集群服务异常告警​

Compaction 失败告警​

累积 Compaction 失败告警​

PromSQL

increase(starrocks_be_engine_requests_total{job="$job_name" ,status="failed",type="cumulative_compaction"}[1m]) > 3
increase(starrocks_be_engine_requests_total{job="$job_name" ,status="failed",type="base_compaction"}[1m]) > 3

告警描述

当最后一分钟内 Cumulative Compaction 或 Base Compaction 失败三次时，会触发告警。

解决方案

搜索相应 BE 节点的日志，查找以下关键字以识别涉及的 Tablet。

grep -E 'compaction' be.INFO | grep failed

以下日志记录表示 Compaction 失败。

W0924 17:52:56:537041 123639 comaction_task_cpp:193] compaction task:8482. tablet:8423674 failed.

您可以检查日志的上下文以分析失败原因。 通常，失败可能是由于 Compaction 过程中 DROP TABLE 或 PARTITION 操作引起的。 系统具有 Compaction 的内部重试机制，您也可以手动将 Tablet 的状态设置为 BAD 并触发 Clone 任务以修复它。

注意

在执行以下操作之前，请确保表至少有三个完整的副本。

ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "$tablet_id", "backend_id" = "$backend_id", "status" = "bad");

高 Compaction 压力告警​

PromSQL

starrocks_fe_max_tablet_compaction_score{job="$job_name",instance="$fe_leader"} > 100

告警描述

当最高 Compaction Score 超过 100 时，会触发告警，表示 Compaction 压力高。

解决方案

此告警通常由频繁的加载、INSERT INTO VALUES 或 DELETE 操作（每秒 1 次）引起。 建议将加载或 DELETE 任务之间的间隔设置为 5 秒以上，并避免提交高并发 DELETE 任务。

超过版本计数告警​

PromSQL

starrocks_be_max_tablet_rowset_num{job="$job_name"} > 700

告警描述

当 BE 节点上的 Tablet 具有超过 700 个数据版本时，会触发告警。

解决方案

使用以下命令检查版本过多的 Tablet

SELECT BE_ID,TABLET_ID FROM information_schema.be_tablets WHERE NUM_ROWSET>700;

Tablet ID 为 2889156 的示例

SHOW TABLET 2889156;

执行 DetailCmd 字段中返回的命令

SHOW PROC '/dbs/2601148/2889154/partitions/2889153/2889155/2889156';

show proc replica

正常情况下，如所示，所有三个副本都应处于 NORMAL 状态，并且 RowCount 和 DataSize 等其他指标应保持一致。 如果只有一个副本超过 700 的版本限制，您可以根据其他副本使用以下命令触发 Clone 任务

ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "$tablet_id", "backend_id" = "$backend_id", "status" = "bad");

如果两个或多个副本超过版本限制，您可以暂时增加版本计数限制

# Replace be_ip with the IP of the BE node which stores the tablet that exceeds the version limit.
# The default be_http_port is 8040.
# The default value of tablet_max_versions is 1000.
curl -XPOST http://$be_ip:$be_http_port/api/update_config?tablet_max_versions=2000

CheckPoint 失败告警​

PromSQL

starrocks_fe_meta_log_count{job="$job_name",instance="$fe_master"} > 100000

告警描述

当 FE 节点的 BDB 日志计数超过 100,000 时，会触发告警。 默认情况下，当 BDB 日志计数超过 50,000 时，系统会执行 CheckPoint，然后将计数重置为 0。

解决方案

此告警指示未执行 CheckPoint。 您需要调查 FE 日志以分析 CheckPoint 过程并解决问题

在 Leader FE 节点的 fe.log 中，搜索 begin to generate new image: image.xxxx 之类的记录。 如果找到，则表示系统已开始生成新镜像。 继续检查日志中 checkpoint finished save image.xxxx 之类的记录，以确认镜像创建成功。 如果找到 Exception when generate new image file，则镜像生成失败。 您应该根据具体错误仔细处理元数据。 建议联系支持团队进行进一步分析。

FE 线程计数过多告警​

PromSQL

starrocks_fe_thread_pool{job="$job_name", type!="completed_task_count"} > 3000

告警描述

当 FE 上的线程数超过 3000 时，会触发告警。

解决方案

FE 和 BE 节点的默认线程计数限制为 4096。 大量 UNION ALL 查询通常会导致线程计数过多。 建议减少 UNION ALL 查询的并发性并调整系统变量 pipeline_dop。 如果无法调整 SQL 查询粒度，您可以全局调整 pipeline_dop

SET GLOBAL pipeline_dop=8;
注意

在紧急情况下，要快速恢复服务，您可以增加 FE 动态参数 thrift_server_max_worker_threads（默认值：4096）。

ADMIN SET FRONTEND CONFIG ("thrift_server_max_worker_threads"="8192");

FE JVM 使用率高告警​

PromSQL

sum(jvm_heap_size_bytes{job="$job_name", type="used"}) * 100 / sum(jvm_heap_size_bytes{job="$job_name", type="max"}) > 90

告警描述

当 FE 节点上的 JVM 使用率超过 90% 时，会触发告警。

解决方案

此告警指示 JVM 使用率过高。 您可以使用 jmap 命令分析情况。 由于此指标的详细监控信息仍在开发中，因此直接的见解有限。 执行以下操作并将结果发送给支持团队进行分析

# Note that specifying `live` in the command may cause FE to restart.
jmap -histo[:live] $fe_pid > jmap.dump
注意

在紧急情况下，要快速恢复服务，您可以重启相应的 FE 节点或增加 JVM (Xmx) 大小，然后重启 FE 服务。

服务可用性告警​

加载异常告警​

加载失败告警​

PromSQL

rate(starrocks_fe_txn_failed{job="$job_name",instance="$fe_master"}[5m]) * 100 > 5

告警描述

当失败的加载事务数超过总数的 5% 时，会触发告警。

解决方案

检查 Leader FE 节点的日志，查找有关加载错误的信息。 搜索关键字 status: ABORTED 以识别失败的加载任务。

2024-04-09 18:34:02.363+08:00 INFO (thrift-server-pool-8845163|12111749) [DatabaseTransactionMgr.abortTransaction():1279] transaction:[TransactionState. txn_id: 7398864, label: 967009-2f20a55e-368d-48cf-833a-762cf1fe07c5, db id: 10139, table id list: 155532, callback id: 967009, coordinator: FE: 192.168.2.1, transaction status: ABORTED, error replicas num: 0, replica ids: , prepare time: 1712658795053, commit time: -1, finish time: 1712658842360, total cost: 47307ms, reason: [E1008]Reached timeout=30000ms @192.168.1.1:8060 attachment: RLTaskTxnCommitAttachment [filteredRows=0, loadedRows=0, unselectedRows=0, receivedBytes=1033110486, taskExecutionTimeMs=0, taskId=TUniqueId(hi:3395895943098091727, lo:-8990743770681178171), jobId=967009, progress=KafkaProgress [partitionIdToOffset=2_1211970882|7_1211893755]]] successfully rollback

Routine Load 消费延迟告警​

PromSQL

(sum by (job_name)(starrocks_fe_routine_load_max_lag_of_partition{job="$job_name",instance="$fe_mater"})) > 300000
starrocks_fe_routine_load_jobs{job="$job_name",host="$fe_mater",state="NEED_SCHEDULE"} > 3
starrocks_fe_routine_load_jobs{job="$job_name",host="$fe_mater",state="PAUSED"} > 0
starrocks_fe_routine_load_jobs{job="$job_name",host="$fe_mater",state="UNSTABLE"} > 0

告警描述

  • 当超过 300,000 个条目的消费延迟时，会触发告警。
  • 当挂起的 Routine Load 任务数超过 3 个时，会触发告警。
  • 当任务处于 PAUSED 状态时，会触发告警。
  • 当任务处于 UNSTABLE 状态时，会触发告警。

解决方案

  1. 首先，检查 Routine Load 任务状态是否为 RUNNING。

    SHOW ROUTINE LOAD FROM $db;

    注意返回数据中的 State 字段。

  2. 如果任何 Routine Load 任务处于 PAUSED 状态，请检查 ReasonOfStateChanged、ErrorLogUrls 和 TrackingSQL 字段。 通常，执行 TrackingSQL 中的 SQL 查询可以揭示具体错误。

    示例

    Tracking SQL

  3. 如果 Routine Load 任务状态为 RUNNING，您可以尝试增加任务的并发性。 单个 Routine Load 作业的并发性由以下四个参数的最小值决定

    • kafka_partition_num：Kafka 主题中的分区数。
    • desired_concurrent_number：任务的设置并发性。
    • alive_be_num：活动的 BE 节点数。
    • max_routine_load_task_concurrent_num：FE 配置参数，默认值为 5。

在大多数情况下，您可能需要调整任务的并发性或 Kafka 主题分区的数量（如有必要，请联系 Kafka 支持）。

以下示例显示如何设置任务的并发性。

ALTER ROUTINE LOAD FOR ${routine_load_jobname}
PROPERTIES
(
    "desired_concurrent_number" = "5"
);

单个数据库的加载事务限制告警​

PromSQL

sum(starrocks_fe_txn_running{job="$job_name"}) by(db) > 900

告警描述

当单个数据库的加载事务数超过 900 个时（v3.1 之前的版本为 100 个），会触发告警。

解决方案

此告警通常由大量新添加的加载任务触发。 您可以暂时增加单个数据库的加载事务限制。

ADMIN SET FRONTEND CONFIG ("max_running_txn_num_per_db" = "2000");

查询异常告警​

查询延迟告警​

PromSQL

starrocks_fe_query_latency_ms{job="$job_name", quantile="0.95"} > 5000

告警描述

当 P95 查询延迟超过 5 秒时，会触发告警。

解决方案

  1. 调查是否存在任何大查询。

    检查大查询是否在异常期间消耗了大量机器资源，导致其他查询超时或失败。

    • 执行 show proc '/current_queries'; 查看大查询的 QueryId。 如果您需要快速恢复服务，可以使用 KILL 命令终止长时间运行的查询。

      mysql> SHOW PROC '/current_queries';
      +--------------------------------------+--------------+------------+------+-----------+----------------+----------------+------------------+----------+
      | QueryId                              | ConnectionId | Database   | User | ScanBytes | ProcessRows    | CPUCostSeconds | MemoryUsageBytes | ExecTime |
      +--------------------------------------+--------------+------------+------+-----------+----------------+----------------+------------------+----------+
      | 7c56495f-ae8b-11ed-8ebf-00163e00accc | 4            | tpcds_100g | root | 37.88 MB  | 1075769 Rows   | 11.13 Seconds  | 146.70 MB        | 3804     |
      | 7d543160-ae8b-11ed-8ebf-00163e00accc | 6            | tpcds_100g | root | 13.02 GB  | 487873176 Rows | 81.23 Seconds  | 6.37 GB          | 2090     |
      +--------------------------------------+--------------+------------+------+-----------+----------------+----------------+------------------+----------+
      2 rows in set (0.01 sec)

    • 您也可以重启 CPU 利用率高的 BE 节点以解决此问题。

  2. 检查机器资源是否充足。

    验证异常期间 CPU、内存、磁盘 I/O 和网络流量是否正常。 如果检测到异常，请通过检查流量峰值变化和集群资源使用情况来调查根本原因。 如果问题仍然存在，请考虑重启受影响的节点。

注意

在紧急情况下，您可以通过以下方式解决此问题

  • 减少业务流量并在突然的流量峰值导致资源过度使用和查询失败时重启受影响的 BE 节点。
  • 如果资源使用率高是由于正常操作引起的，则扩展节点容量。

查询失败告警​

PromSQL

sum by (job,instance)(starrocks_fe_query_err_rate{job="$job_name"}) * 100 > 10

# This PromSQL is supported from v3.1.15, v3.2.11, and v3.3.3 onwards.
increase(starrocks_fe_query_internal_err{job="$job_name"})[1m] >10

告警描述

当查询失败率超过 0.1/秒或在一分钟内发生 10 个失败的查询时，会触发告警。

解决方案

触发此告警时，请检查日志以识别失败的查询。

grep 'State=ERR' fe.audit.log

如果您安装了 AuditLoader 插件，则可以使用以下查询找到相应的查询。

SELECT stmt FROM starrocks_audit_db__.starrocks_audit_tbl__ WHERE state='ERR';

请注意，由于语法错误或超时而失败的查询也会记录在 starrocks_fe_query_err_rate 中。

对于由内核问题引起的查询失败，请搜索 fe.log 中的错误并获取完整的堆栈跟踪和 查询转储，并联系支持团队进行故障排除。

查询过载告警​

PromSQL

abs((sum by (exported_job)(rate(starrocks_fe_query_total{process="FE",job="$job_name"}[3m]))-sum by (exported_job)(rate(starrocks_fe_query_total{process="FE",job="$job_name"}[3m] offset 1m)))/sum by (exported_job)(rate(starrocks_fe_query_total{process="FE",job="$job_name"}[3m]))) * 100 > 100
abs((sum(starrocks_fe_connection_total{job="$job_name"})-sum(starrocks_fe_connection_total{job="$job_name"} offset 3m))/sum(starrocks_fe_connection_total{job="$job_name"})) * 100 > 100

告警描述

当 QPS 或连接数在最后一分钟内增加 100% 时，会触发告警。

解决方案

检查 fe.audit.log 中的高频查询是否符合预期。 如果业务行为有合理的变化（例如，新服务上线或数据量增加），请监控机器负载并根据需要扩展 BE 节点。

超出用户连接限制告警​

PromSQL

sum(starrocks_fe_connection_total{job="$job_name"}) by(user) > 90

告警描述

当用户连接数超过 90 时，会触发告警。（从 v3.1.16、v3.2.12 和 v3.3.4 版本开始支持用户连接限制。）

解决方案

使用 SQL 命令 SHOW PROCESSLIST 检查当前连接数是否符合预期。 您可以使用 KILL 命令终止意外的连接。 此外，确保前端服务不会长时间保持连接打开状态，并考虑调整系统变量 wait_timeout（单位：秒），以加速系统自动终止空闲连接。

SET wait_timeout = 3600;
注意

在紧急情况下，您可以暂时增加用户连接限制以恢复服务

  • 对于 v3.1.16、v3.2.12 和 v3.3.4 或更高版本

    ALTER USER 'jack' SET PROPERTIES ("max_user_connections" = "1000");

  • 对于 v2.5 及更早版本

    SET PROPERTY FOR 'jack' 'max_user_connections' = '1000';

Schema Change 异常告警​

PromSQL

increase(starrocks_be_engine_requests_total{job="$job_name",type="schema_change", status="failed"}[1m]) > 1

告警描述

当最后一分钟内有多个 Schema Change 任务失败时，会触发告警。

解决方案

运行以下语句以检查 Msg 字段是否包含任何错误消息

SHOW ALTER COLUMN FROM $db;

如果未找到任何消息，请在 Leader FE 日志中搜索上一步的 JobId 以检索上下文。

  • Schema Change 内存不足

    如果 Schema Change 由于内存不足而失败，请搜索 be.WARNING 日志中的 failed to process the version、failed to process the schema change from tablet 或 Memory of schema change task exceeded limit 以识别以下显示的日志记录

    fail to execute schema change: Memory of schema change task exceed limit. DirectSchemaChange Used: 2149621304, Limit: 2147483648. You can change the limit by modify BE config [memory_limitation_per_thread_for_schema_change]

    内存限制错误通常是由于单个 Schema Change 超过 2GB 的内存限制引起的，该限制由 BE 动态参数 memory_limitation_per_thread_for_schema_change 控制。 您可以修改此参数以解决此问题。

    curl -XPOST http://be_host:http_port/api/update_config?memory_limitation_per_thread_for_schema_change=8

  • Schema Change 超时

    除了添加列（这是一种轻量级实现）之外，大多数 Schema Change 都涉及创建大量新 Tablet、重写原始数据以及通过 SWAP 实现操作。

    Create replicas failed. Error: Error replicas:21539953=99583471, 21539953=99583467, 21539953=99599851

    您可以通过以下方式解决此问题

    • 增加创建 Tablet 的超时时间（默认：10 秒）。

      ADMIN SET FRONTEND CONFIG ("tablet_create_timeout_second"="60");

    • 增加创建 Tablet 的线程数（默认：3）。

      curl -XPOST http://be_host:http_port/api/update_config?alter_tablet_worker_count=6

  • Tablet 非正常状态

    1. 如果 Tablet 处于非正常状态，请搜索 be.WARNING 日志中的 tablet is not normal 并执行 SHOW PROC '/statistic' 以检查集群级别的 UnhealthyTabletNum。

      show statistic

    2. 执行 SHOW PROC '/statistic/$DbId' 检查指定数据库中的不健康 Tablet 数量。

      show statistic db

    3. 执行 SHOW TABLET $tablet_id 查看相应 Tablet 的表信息。

      show tablet

    4. 执行 DetailCmd 字段中返回的命令，以识别不健康 Tablet 的原因。

      show proc

    通常，不健康以及不一致的副本通常是由高频加载引起的，其中写入不同副本的进度未同步。 您可以检查表是否有大量实时写入，并通过降低加载频率或暂时暂停服务并在之后重试任务来减少异常副本的数量。

注意

在紧急情况下，要恢复服务，您可以将非正常副本设置为 Bad 以触发 Clone 任务。

ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "$tablet_id", "backend_id" = "$backend_id", "status" = "bad");

在执行此操作之前，请确保该表至少有三个完整的副本，并且只有一个非正常副本。

物化视图刷新异常告警​

PromSQL

increase(starrocks_fe_mv_refresh_total_failed_jobs[5m]) > 0

告警描述

当过去五分钟内有多个物化视图刷新失败时，会触发告警。

解决方案

  1. 检查未能刷新的物化视图。

    SELECT TABLE_NAME,IS_ACTIVE,INACTIVE_REASON,TASK_NAME FROM information_schema.materialized_views WHERE LAST_REFRESH_STATE !=" SUCCESS";

  2. 尝试手动刷新物化视图。

    REFRESH MATERIALIZED VIEW $mv_name;

  3. 如果物化视图处于 INACTIVE 状态，请尝试手动激活它。

    ALTER MATERIALIZED VIEW $mv_name ACTIVE;

  4. 调查刷新失败的原因。

    SELECT * FROM information_schema.task_runs WHERE task_name ='mv-112517' \G