如题，
1、想了解下实际大家是怎么做高可用的
2、在做了高可用的时候，针对特殊情况按照ID排序的场景，如何优化TIDB 不同server获取 ID区间缓存导致通过不同server写入的数据，ID不连续的问题呢？
1、TiProxy你值得拥有
2、个人觉得ID连续是个伪命题。
1 个赞
HAProxy和tiproxy可以做高可用和负载均衡
id不连续这个没有什么太好办法，确实需要可以程序自己生成
从6.4开始，可以通过设置表的AUTO_ID_CACHE为1来保证id连续的问题啊。。。
1 个赞
在每个TIDB上部署haproxy，然后通过F5轮休这些haproxy的服务端口，这种适合业务量大的情况，如果业务量不是那么大，可以在tidb上部署haproxy+keepalived的方式
你说的id是自增列么？现在自增列是支持连续递增的。
haproxy+keepalive，不过tidb好像有tiproxy了，只是没有用过
haproxy，tiproxy都不错。
但id要求连续肯定是个坏文明。
1 个赞
tiproxy
高可用可以用Haproxy，我们集群就是这样做负载的。另外一点，为了防止热点问题，不建议id连续，否则相近的数据都会存储到同一个region或者机器，导致机器资源不均衡
8之后好像集成了tiproxy,之前通过haproxy做tidb server高可用
auto_increment 后面是连续的
目前用的方案是haproxy+keepalive，还没有用TiProxy
id连续的目的是什么？
F5负载均衡 ，测试用haproxy
自增id不连续建表时候加上参数AUTO_ID_CACHE=1就连续了，但是我建议在7.5.2版本后用
自增的话用这个：
https://docs.pingcap.com/zh/tidb/v7.1/sql-statement-create-sequence#create-sequence
高可用的话有tiproxy
1、硬负载和软负载（国产的）都有用
2、基本没碰到过要 ID 自增的情况，虽然 tidb 提供了兼容的自增 ID，但是不建议用
- 高版本可以试试tiproxy了，老版本建议用的haproxy也是可以的
- 自增现在也支持连续了，没啥必要了
我去查查文档，目前使用的是6.1.0的版本
嗯，目前在测试环境尝试 keepalived + haproxy 的方案中
单个server区间内是连续的，但是多个server轮训的时候就不是啦