抓包的服务器上 tiproxy 是不是端口被占了没起来?连的 6000 端口又刚好发的是 x11 协议。tiproxy 是不会发 x11 协议的。
你代码里不是 6000,但是你抓包似乎用的是 6000
你用其他工具,比如 mysql client 能连上 tiproxy 吗
那是在 fallbackable 设为 false 的时候才会
把 proxy-protocol.fallbackable 设为 true,networks 设为 * 是否可行?这样不管客户端有没有用 proxy protocol 都能连接。
X11 是 Unix/Linux 用于图形界面显示的协议,X Server 的默认端口是 6000,刚好是 tiproxy 的默认端口号。有没有可能 tiproxy 因为端口占用没有起来,你连上了 X11 的 X Server 呢?
图中是 TiDB 的 CPU 还是 TiProxy 的 CPU?
CPU 和内存达到 80% 是指 TiDB 的还是 TiProxy 的?
CPU 忽高忽低是指 TiDB 的还是 TiProxy 的?
建议使用软负载均衡器。
其他方案还有硬负载均衡器、基于 DNS 的负载均衡、客户端负载均衡,但是比较少用。
应该是所有事务的 COMMIT 都聚合到一起了,所以看起来总时间最高。
针对这种场景,TiProxy 的负载均衡策略主要有两点改进:
负载均衡是动态的,能把连接从一台 TiDB 迁移到另一台,而不只是在路由时做负载均衡,这对长连接的应用更有效。例如你使用了连接池,而每个连接的负载是不固定的,所以 TiDB 的负载也是起伏的。又例如,你新扩了一台 TiDB 出来,长连接也会迁到新 TiDB 上。
负载均衡是基于资源使用率的,而不仅仅是 round-robin、随机这些简单的策略,因为简单策略假设每个连接的负载是相同的,但数据库应用更随机多变。
根据以上你的截图,我简单猜测下:要么 237 是新扩出来的节点;要么是断开连接时,刚好 237 上断开的连接更多。
你…
感谢。我说下之前的规划:
比较结果集:采集时记录行数、结果集的 checksum,然后在测试集群比对。问题是本来就很难保证结果一致,所以会产生很多误报。
比较性能:采集时记录 SQL 延迟,在测试集群比对。
比较执行计划:采集流量后,建两个测试集群,分别对应两个版本,TiProxy 在 SQL 前面加上 explain 去比对两个集群的计划,这样能比较所有 SQL 的所有参数,但是操作链路太长。
对比 STATEMENTS_SUMMARY_HISTORY 确实是个很好的方案,能比较的维度很多,尤其是扫描行数。缺点是比较不全面,例如 COMMIT 语句区分不出是哪个事务的,但问题也不大。
监控缺失是三台一起缺失,跟 “某一台虚拟机网络延迟很高” 不是同一件事吧?
如果是网络带宽问题,可能是 tiproxy 所在的那台机器网络带宽打满了
感谢反馈,我们近期就把 http api 加到文档上。
直接连 3080 的话,跟 tidb 的 10080 一样可以用 curl 127.0.0.1:3080/xxx 获取,常见的接口有:
/api/debug/health 是否健康
/api/admin/config/ 获取或设置配置
/metrics 获取监控
/debug/pprof/xxx 获取 profile
tidb v6.5.0 引入的包有 bug,需要升级到 v6.5.1。
不过升级之后 host 的 IP 是对的,port 一直为 0。
现在只考虑了连接数,不支持配置权重。上面的规划里考虑了 CPU、内存等。你说的资源应该主要指 CPU?如果考虑 CPU 使用率的时候结合了 TiDB 实例的核数,应该也能满足你的需求。