haproxy透传问题

[hygame]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
5.4
【概述】场景+问题概述
使用haproxy透传功能后，tidb-server持续报

haproxy配置：
listen prod-tidb-cluster
bind 10.106.10.91:5000
mode tcp
balance roundrobin
server 10.106.30.17:4000 10.106.30.17:4000 send-proxy check inter 2000 rise 2 fall 3
server 10.106.30.19:4000 10.106.30.19:4000 send-proxy check inter 2000 rise 2 fall 3
tidb配置:

注：透传功能正常，业务正常，tidb-server日志erro刷得太快

【背景】做过哪些操作
【现象】业务和数据库现象
【业务影响】
【TiDB 版本】
【附件】

• 相关日志 和 监控

1. TiUP Cluster Display 信息

2. TiUP Cluster Edit Config 信息

3. TiDB- Overview 监控

• 对应模块日志（包含问题前后1小时日志）

[h5n1]

配置proxy-protocol.networks后 参数里的IP只能使用harpxoy去连，不能直连tidb server了

[hygame]

proxy-protocol.networks

proxy-protocol.networks里面的ip是haproxy的，是不是不应该写haproxy的ip，用*啊

[h5n1]

那就所有都不能直连了

[hygame]

哦哦，好的，我试一下

[hygame]

proxy-protocol.networks中的两个ip是允许这两个ip使用proxy协议连接tidb，那相当于我配置是对的，可为什么tidb-server 还会报[ERROR] [terror.go:307] [“encountered error”] [error=“write tcp 10.106.30.17:4000->10.106.10.18:7613: write: connection reset by peer”] [stack=“github.com/pingcap/tidb/parser/terror.Log\ \t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/parser/terror/terror.go:307\ github.com/pingcap/tidb/server.(*Server).onConn\ \t/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/server/server.go:516”]

[hygame]

我前端有两个haproxy，10.106.10.18,10.106.10.19，这两个是ip，程序连接的域名映射的是一个vip，在10.106.10.18,10.106.10.19这两个上面飘

[h5n1]

tiup display cluster看下

[hygame]

[h5n1]

应该是17像18普罗写数据，18和17间因为18配置了透传，不能直连，导致的报错

[hygame]

10.106.30段是tidb，10.106.10段是haproxy，这个是tidb server访问haproxy端口导致的，但是不知道为啥要访问haproxy的端口

[Christophe (Doudouwyh)]

应该是与client的通信

[hygame]

请问这个怎么解决，tidb-server日志因为这个错误增长太快

[jansu-dev]

问题分析

1. 在建立 tcp 连接之后，被心跳 reset 了而 tidb 不知道，客户端新请求发过来的时候会发现断了;
   于是被 tidb 关闭心跳前的原有连接，报错 reset by peer；
   

   

2. RST 标识位说明 from https://blog.csdn.net/a_tu_/article/details/80389878：
           RST表示复位，用来异常的关闭连接，在TCP的设计中它是不可或缺的。就像上面说的一样，发送RST包关闭连接时，不必等缓冲区的包都发出去（不像上面的FIN包），直接就丢弃缓存区的包发送RST包。而接收端收到RST包后，也不必发送ACK包来确认。
          TCP处理程序会在自己认为的异常时刻发送RST包。例如，A向B发起连接，但B之上并未监听相应的端口，这时B操作系统上的TCP处理程序会发RST包。
          又比如，AB正常建立连接了，正在通讯时，A向B发送了FIN包要求关连接，B发送ACK后，网断了，A通过若干原因放弃了这个连接（例如进程重启）。网通了后，B又开始发数据包，A收到后表示压力很大，不知道这野连接哪来的，就发了个RST包强制把连接关了，B收到后会出现connect reset by peer错误。

解决办法：

1. 等新 PR 把这个报错降低成 debug 级别用新版；
2. 写个 shell 定期 log 挪位置，制定个策略之类（暂时没太好直接规避问题的参数）；
3. 不用透传，感觉透传是个锦上添花的功能，没实际需求就没必要用；