【 TiDB 使用环境】生产环境
【 TiDB 版本】7.5.1
目前生产环境TIDB集群 版本7.5.1 ，三个Server节点，通过内部dns解析配置一个master， 一个slave，一个backup，backup节点未实际对外使用，只是给Server做备份
目前想做高可用方案。 不知道大家对于 tiproxy 和 haproxy 的选择更趋向于那个，分别基于什么考虑呢，如果上线高可用的方案的话，历史id cache 区间的问题会不会受到影响呢？
请各位给小弟一些建议和参考~
官网文档介绍了功能和性能对比，选哪个看需求
三个Server节点，通过内部dns解析配置一个master， 一个slave，一个backup 你们怎么会这么部署？
haproxy 和tiproxy都可以，haproxy性能好点，官网有haproxy也有配置文档
历史id cache 区间 具体什么问题？
那你们没有使用proxy的时候Server节点是怎么部署和规划的呀？
tidb server我们这边用haproxy比较多。id cache区间是指tidb server切换后auto_increment自增跳变吗？
我们用负载均衡haproxy了
不同的Server节点分配的 id cache区间不一样，使用proxy之后，写入会在不同的server之间跳吧，那么这个时候id的“增长就不是递增的” ，会不会产生id冲突呢？
主要是tiproxy 文档是从8.1才开始的， 目前的版本是7.5.1 ，所以想看看大家在 7.5 版本下的使用情况
对是的，haproxy之后会不会对现有的id cache问题造成影响呢，
haproxy就可以了，稳定
可以考虑建表设置cache_id=1
1 个赞
新表可以这样，但是目前TIDB是从MySQL迁移过来的，没有设置这个
那就要修改表结构了，不同的tidb server写入自增值会有这个问题的，一般生产要设置AUTO_ID_CACHE=1来避免。
参考https://docs.pingcap.com/zh/tidb/v7.5/auto-increment#缓存大小控制
其实核心点在于 即使在不同server之间跳也行，主要不发生id冲突就行，（当然业务上也要求排序不按主键ID来才行）
目前没有看到文档说明或者实际验证会 不发生冲突这个点
自增只要不显式指定，即使tidb切换了也是不会出现冲突的，因为每个tidb cache的范围是不同的。
但是这里有个疑问就是 server节点重启之后之前的id cache 被清空，再次获取的cache范围在多个server的情况，它能否保证是从当前所有server节点最大范围之上获取呢？
现在实际发现个问题，ID在切换之后，增长跑回到 历史某个cache 区间未被使用的子区间去了，
现在有个担心的问题就是，当前使用的“子区间” 是新划分的cache 区间，那么可能就会包括其他sever已经分别的区间的一部分
如果不显式指定应该不会出现这种情况。
你这个测试是基于集群中只有一个server节点吧？
haproxy稳定