EMQX版本：5.7.2
操作系统：Debian 12
想知道之前官方文档里的参数 emqx_mria_lag 指的是什么方面的滞后性，对集群的复制节点会有什么影响呢
这个指标里有4个属性
emqx_cm_shard 从-2降到-8，route_shard 从 0 降到 -2需要补充一些信息才能更好地帮你排查：
麻烦补充一下，谢谢。
部署方式是k8s,一个core，两个repl
先给结论：emqx_mria_lag 就是复制节点落后核心节点的程度，数值越接近 0 越好。这个指标下的 emqx_cm_shard / route_shard / emqx_psk_shard / mria_meta_shard 是 Mria 不同 shard 的复制滞后，分别对应连接/会话管理、路由表、PSK 数据、Mria 元数据这几类表的 rlog。
你这个 pod 重启后 lag 从 -2 到 -8，本质是复制节点在追赶核心节点的变更，通常会自动恢复到 0；如果一直不回升，优先看 emqx_mria_replayq_len / emqx_mria_message_queue_len（应该接近 0），以及核心侧的 emqx_mria_server_mql 有没有堆积。
如果方便，把 的输出贴一下，我可以帮你确认每个 shard 里具体是哪些表，也能判断是不是网络延迟或核心负载导致追赶慢。
补一下命令：emqx ctl eval ‘mria_rlog:status().’ 。输出里会显示各 shard 的表和滞后情况，贴出来我就能更精确判断。
我看了下 emqx_mria_replayq_len，emqx_mria_message_queue_len 以及 emqx_mria_server_mql 最近都为0 (包括pod宕机以前)，emqx_mria_message_queue_len 出现过短暂的 0 ->1 的突刺，后面又变为0
你提到的命令 emqx ctl eval ‘mria_rlog:status().’ ，我在5.7.2的版本中输出是这样的情况 (本地和服务器都是)，命令行文档里也没有提到eval，看起来是这个版本不支持这条命令？
emqx_mria_lag 是复制节点相对 core 的事务滞后，越小越好。那几个 shard 大致对应 mria 的表/分片：emqx_cm_shard=连接/会话元数据，route_shard=路由表，emqx_psk_shard=PSK 认证表（没用 PSK 基本为 0），mria_meta_shard=MRIA 元数据。你这次重启后 -2→-8 这类波动正常，只要 emqx_mria_replayq_len / emqx_mria_message_queue_len 长期为 0，core 上 emqx_mria_server_mql 也为 0，通常表示已经追平，不用手动处理。
mria_rlog:status 文档里是 ，你截图里像是引号问题（用了中文引号）。
顺便说下部署方式（k8s/docker/安装包）和这个 pod 是 core 还是 replicant？再贴下 输出，我看下是否有异常。
如果 5.7.2 上没有 ctl eval，试 emqx eval ‘mria_rlog:status().’
用 emqx eval 'mria_rlog:status().' 的输出结果是（已做脱敏处理）：
./emqx eval 'mria_rlog:status().'
#{role => replicant,backend => rlog,shards_down => [],
shard_stats =>
#{'$mria_meta_shard' =>
#{message_queue_len => 0,state => normal,
upstream =>
'emqx-xxxx-yyyyy@emqx-xxxx-core.svc.cluster.local',
bootstrap_num_keys => 3,bootstrap_time => 2,lag => 0,
last_imported_trans => 28,replayq_len => 0},
emqx_common_shard =>
#{message_queue_len => 0,state => normal,
upstream =>
'emqx-xxxx-yyyyy@emqx-xxxx-core.svc.cluster.local',
bootstrap_num_keys => 7,bootstrap_time => 4,lag => 0,
last_imported_trans => 12,replayq_len => 0},
emqx_cm_shard =>
#{message_queue_len => 0,state => normal,
upstream =>
'emqx-xxxx-yyyyy@emqx-xxxx-core.svc.cluster.local',
bootstrap_num_keys => 300,bootstrap_time => 389,lag => -6,
last_imported_trans => 38259296,replayq_len => 0},
emqx_exclusive_shard =>
#{message_queue_len => 0,state => normal,
upstream =>
'emqx-xxxx-yyyyy@emqx-xxxx-core.svc.cluster.local',
bootstrap_num_keys => 1,bootstrap_time => 2,lag => 0,
last_imported_trans => 0,replayq_len => 0},
route_shard =>
#{message_queue_len => 0,state => normal,
upstream =>
'emqx-xxxx-yyyyy@emqx-xxxx-core.svc.cluster.local',
bootstrap_num_keys => 305,bootstrap_time => 358,lag => -2,
last_imported_trans => 35908433,replayq_len => 0},
emqx_shared_sub_shard =>
#{message_queue_len => 0,state => normal,
upstream =>
'emqx-xxxx-yyyyy@emqx-xxxx-core.svc.cluster.local',
bootstrap_num_keys => 2,bootstrap_time => 2,lag => 0,
last_imported_trans => 45254,replayq_len => 0},
emqx_cluster_rpc_shard =>
#{message_queue_len => 0,state => normal,
upstream =>
'emqx-xxxx-yyyyy@emqx-xxxx-core.svc.cluster.local',
bootstrap_num_keys => 4,bootstrap_time => 3,lag => 0,
last_imported_trans => 90,replayq_len => 0},
emqx_authn_shard =>
#{message_queue_len => 0,state => normal,
upstream =>
'emqx-xxxx-yyyyy@emqx-xxxx-core.svc.cluster.local',
bootstrap_num_keys => 3,bootstrap_time => 2,lag => 0,
last_imported_trans => 1,replayq_len => 0},
emqx_acl_sharded =>
#{message_queue_len => 0,state => normal,
upstream =>
'emqx-xxxx-yyyyy@emqx-xxxx-core.svc.cluster.local',
bootstrap_num_keys => 1,bootstrap_time => 1,lag => 0,
last_imported_trans => 0,replayq_len => 0},
emqx_dashboard_shard =>
#{message_queue_len => 0,state => normal,
upstream =>
'emqx-xxxx-yyyyy@emqx-xxxx-core.svc.cluster.local',
bootstrap_num_keys => 4,bootstrap_time => 2,lag => 0,
last_imported_trans => 62448,replayq_len => 0},
emqx_retainer_shard =>
#{message_queue_len => 0,state => normal,
upstream =>
'emqx-xxxx-yyyyy@emqx-xxxx-core.svc.cluster.local',
bootstrap_num_keys => 6,bootstrap_time => 4,lag => 0,
last_imported_trans => 9934951,replayq_len => 0},
emqx_psk_shard =>
#{message_queue_len => 0,state => normal,
upstream =>
'emqx-xxxx-yyyyy@emqx-xxxx-core.svc.cluster.local',
bootstrap_num_keys => 1,bootstrap_time => 1,lag => 0,
last_imported_trans => 0,replayq_len => 0},
emqx_telemetry_shard =>
#{message_queue_len => 0,state => normal,
upstream =>
'emqx-xxxx-yyyyy@emqx-xxxx-core.svc.cluster.local',
bootstrap_num_keys => 2,bootstrap_time => 1,lag => 0,
last_imported_trans => 1,replayq_len => 0}},
shards_in_sync =>
['$mria_meta_shard',emqx_acl_sharded,emqx_authn_shard,
emqx_cluster_rpc_shard,emqx_cm_shard,emqx_common_shard,
emqx_dashboard_shard,emqx_exclusive_shard,emqx_psk_shard,
emqx_retainer_shard,emqx_shared_sub_shard,emqx_telemetry_shard,
route_shard]}
宕机的pod是replicant的，部署方式是k8s，使用daemonset方式部署
结论：你这个状态正常，不用手动处理。emqx_mria_lag 表示复制节点相对上游 core 的滞后程度，数值越低越好。你贴的 mria_rlog:status 里各 shard 都是 state=normal，message_queue_len/replayq_len=0，shards_down=，说明已经同步上了。lag 出现 -6/-2 多半是重启后的短时波动，会自动 bootstrap+追平。
这几个 shard 大致对应的数据：
如果后面 lag 持续扩大，同时 message_queue_len 或 replayq_len 不是 0，再看 core 侧 emqx_mria_server_mql 有没有积压，必要时加 core 资源/节点。
了解了，非常感谢