tiproxy:latest 没有更新了，请使用 tiproxy:v1.3.0
报错是因为引用的 tidb 库的一个 bug(panic at cgroup when to startup · Issue #42659 · pingcap/tidb · GitHub)，已被修复
1 小时前
可以只代理一部分的，给 tiproxy 和 tidb 分别打上 label，tiproxy 路由到同 label 的 tidb：https://docs.pingcap.com/zh/tidb/stable/tiproxy-load-balance#基于标签的负载均衡
这里主要用于隔离 tidb 资源的情况。顺便问下你的是什么场景，其他 tidb 是用其他代理吗？
2 个月前
图中是 TiDB 的 CPU 还是 TiProxy 的 CPU?
CPU 和内存达到 80% 是指 TiDB 的还是 TiProxy 的？
CPU 忽高忽低是指 TiDB 的还是 TiProxy 的？
2 个月前
感谢反馈。文档确实很分散，我提了个 PR 加上一些文档链接，另外改了下参数说明：tiproxy: improve deployment instructions for deploying TiProxy by djshow832 · Pull Request #19415 · pingcap/docs-cn · GitHub
3 个月前
针对这种场景，TiProxy 的负载均衡策略主要有两点改进：
负载均衡是动态的，能把连接从一台 TiDB 迁移到另一台，而不只是在路由时做负载均衡，这对长连接的应用更有效。例如你使用了连接池，而每个连接的负载是不固定的，所以 TiDB 的负载也是起伏的。又例如，你新扩了一台 TiDB 出来，长连接也会迁到新 TiDB 上。
负载均衡是基于资源使用率的，而不仅仅是 round-robin、随机这些简单的策略，因为简单策略假设每个连接的负载是相同的，但数据库应用更随机多变。
根据以上你的截图，我简单猜测下：要么 237 是新扩出来的节点；要么是断开连接时，刚好 237 上断开的连接更多。
你…
4 个月前
感谢。我说下之前的规划：
比较结果集：采集时记录行数、结果集的 checksum，然后在测试集群比对。问题是本来就很难保证结果一致，所以会产生很多误报。
比较性能：采集时记录 SQL 延迟，在测试集群比对。
比较执行计划：采集流量后，建两个测试集群，分别对应两个版本，TiProxy 在 SQL 前面加上 explain 去比对两个集群的计划，这样能比较所有 SQL 的所有参数，但是操作链路太长。
对比 STATEMENTS_SUMMARY_HISTORY 确实是个很好的方案，能比较的维度很多，尤其是扫描行数。缺点是比较不全面，例如 COMMIT 语句区分不出是哪个事务的，但问题也不大。
5 个月前
v1.1.0 支持用自定义的 label 来区分（而不是 zone），已经加进文档了，最近会发到官网上：tiproxy: add docs for label-based balance by djshow832 · Pull Request #18914 · pingcap/docs-cn · GitHub
5 个月前
监控缺失是三台一起缺失，跟 “某一台虚拟机网络延迟很高” 不是同一件事吧？
如果是网络带宽问题，可能是 tiproxy 所在的那台机器网络带宽打满了
8 个月前
10 个月前
感谢反馈，我们近期就把 http api 加到文档上。
直接连 3080 的话，跟 tidb 的 10080 一样可以用 curl 127.0.0.1:3080/xxx 获取，常见的接口有：
/api/debug/health 是否健康
/api/admin/config/ 获取或设置配置
/metrics 获取监控
/debug/pprof/xxx 获取 profile
10 个月前
现在只考虑了连接数，不支持配置权重。上面的规划里考虑了 CPU、内存等。你说的资源应该主要指 CPU？如果考虑 CPU 使用率的时候结合了 TiDB 实例的核数，应该也能满足你的需求。
1 年前
可以用 bin/tiproxyctl，它会连 3080。tiproxyctl --help 可以看到支持的命令，例如 tiproxyctl config get 获取 config。
直接连 3080 的话，跟 tidb 的 10080 一样可以用 curl 127.0.0.1:3080/xxx 获取，常见的接口有：
/api/admin/config/ 获取配置
/metrics 获取监控
/debug/pprof/xxx 获取 profile
1 年前
tidb 代码里很多地方强依赖 tikv 和 pd，并没有很好地解耦，替换不现实。
之前 foundationdb 想过直接用 tidb 做上层的 SQL 引擎，后来放弃了：Use FoundationDB as an alternative of TiKV for TiDB · Issue #19111 · pingcap/tidb · GitHub
1 年前
受教了，让 TiProxy 自己管理 VIP 确实更好。
不过我想调整一下，把 raft 选举改为在 PD 上的 etcd 选主，因为 TiDB 的正常运行都是依赖于 PD 的。在网络分区的情况下，etcd 选主总能选到和 PD leader 在同一个分区的 TiProxy，也就能路由到正常的 TiDB；而 raft 可能会路由到另一个分区，导致集群完全不可用。
另外我在想，也许让用户选择 primary 偏好，或者像 keepalived 一样配置权重能适应更多场景：
因为只有一台 primary 实例，它的硬件配置可能需要很高。用户为了省成本，可能想要 primary 32C，s…
1 年前
没有更多内容了