当时，确实是有并发被分配到某一台tidb-server上，如果使用F5做负载均衡的话，一般选择哪种负载策略。我们目前使用的是最小加权连接数算法策略，但是，看到的现象是负载连接数据并不均衡。每次，遇到高并发进来，都是同时，被打到一个tidb-server节点上。走到此节点被打挂，才会分配到其他节点上。
1 个赞
目前，这套集群为OLTP，公司是把TP和AP拆分来的。
不敢再升级了，以前，从v5.4.0升级到v6.5.0，遇到不少问题
我也觉得需要一个审计功能，哈哈
第三位版本是补丁，不是大版本升级 不用这么紧张。
F5我不清楚，haproxy的策略是根据连接数均衡。
起码能保证每个tidb实例的连接是平均的，不过4层代理可能在连接均衡的情况下，每个连接里面的负载也不一定是均衡的。
tiproxy倒是可以检测tidb实例的真实负载，再把新的请求分过去。
不过，从7.6开始tiproxy才登场了。这个对你来说，可能远水解不了近渴。
7.6是个DMR版本也不建议升级到这个版本。
https://docs.pingcap.com/zh/tidb/v7.6/tiproxy-overview
后面翻了下，负载均衡设备F5配置教程 - 腾讯云开发者社区-腾讯云
haproxy用的应该是这个模式。
III、Least Connection（最少的连接方式算法） ：传递新的连接给那些进行最少连接处理的服务器。
1 个赞
tiproxy官方说性能不如haproxy
可以从监控看下tidb 内存突然上涨的具体时间，再去慢日志看看，语句可能执行失败了。有topsql，可以更快找sql。
倒是很期待tidb官方的tiproxy，有机会测试一下。
也可以看一些dashboard 流量的看一下
一直没关注过tiproxy，有时间我也看看
有测试报告确实不如。
https://docs.pingcap.com/zh/tidb/v7.6/tiproxy-performance-test
一个工作在4层，不需要看包里面有啥，另一个还要提供自动故障转移。
多干了工作，也不太可能消耗一样或者更低。毕竟计算机可不讲既要又要。
1 个赞
上午的这个问题找到问题原因了，是因为：
1、业务操作了大量的欠费核销，近9万条，连续操作了两次
2、有大量的UPDATE语句，同时，也有SELECT，重点是事务被锁住
3、研发人员反馈，产品上没有限制，后续做调整限制
1 个赞
看来还是代码设计上不过关呀，update估计也没走索引