这种错误很常见，一般不是阻止tso推进的根因，可以看下cdc leader 的日志有没有相关报错信息，之前遇到过cdc延迟一直上涨，tso不推荐，是因为有dml语句，表没有索引导致下游执行时间超过2min。看监控图，现在是恢复了吗？可以 pause,resume 下看看

故障排查、性能优化、原理解读,运维操作

白屏操作，统一管理多个集群，自动化巡检

Blackbox_exporter ->Network Status 看下出现问题时间网络延迟呢

2台tikv 也可已是三副本吧，只是region分布不均

单机的需要自己能自己免密登录，也需要配置下

事务提交成功的标志，是多数的副本写入到rockdb tikv 中吧。现在这个场景的话，刚刚写到wal，数据还没有开始两阶段提交，这个时候是肯定不会查询到的吧。

已解决，非常感谢 select tidb_decode_key(‘7480000000006eb78d5f69800000000000003f0419b322f5cf0566d003a40000001216bfa8’); 找出对应的表，执行：ADMIN CHECK TABLE *** ，删除有问题的索引，重新启动changefeed，现已恢复正常

中断最开始的原因是下游tidb节点的4000端口不通，修改为4001端口之后，checkpoint 推进了一会，然后报这个错误。下游数据库是通过br恢复的，是需要在下游数据库执行select tidb_decode_key(‘7480000000006eb78d5f69800000000000003f0419b322f5cf0566d003a40000001216bfa8’);然后重建索引吧。我这边试下

已投票

安装ha，设置透传，可以显示出实际地址

场景需求： 数据归档，而且归档数据还会不定时的查询，保存单副本即可，在需要查询数据的时候可以进行数据恢复 你期望通过 TiKV 支持共享存储减少归档数据的备份频次 希望使用NAS来支撑该场景 痛点描述： 当前采用直通盘 Nvme硬件成本较高、扩展能力有限 功能需求： 期望 TiKV 可以支持nas来支持保存但副本数据

看下对应时间段是否有慢sql

执行下这个命令试试，ssh root@192.168.153.134

1.集群管理，提前预测风险点 2.监控告警 3.sql优化

感谢！

truncate 函数不支持下推 但是round 函数可以

比如他说的这个truncate 函数不知道下推，有没有介绍那些函数可以支持下推，官方没有看到这部分的介绍

【使用 TiCDC 】有 【场景+痛点】业务场景需要创建多个changefeed,有时候changefeed出现问题不能及时告警出来 【反馈+建议】是否可以将changefeed 的日志独立出来，增加changefeed相关的告警内容