dble执行语句后报“the dbInstance[xxxx] can't reach. Please check the dbInstance status”

[PanternBao]

dble 在执行语句之后，总是会报下面的错误：

the dbInstance[xxxx] can't reach. Please check the dbInstance status

如何排查？

[PanternBao]

当出现上述问题时，表明dble中对这个实例的心跳是不正常。

首先应该检查后端MySQL节点是否确实存在问题

如果MySQL节点正常，从dble侧来排查：

1. 收集dble.log以及wrapper.log辅助排查，wrapper.log的日志需要先关注

2. dble提供了以下管理命令观察

1. 可以通过dble提供的管理端命令查看各个dbInstance的心跳状态

https://github.com/actiontech/dble-docs-cn/blob/master/2.Function/2.1_manager_cmd/2.1.03_show.md#21326--show-heartbeat

上面的命令会将所有实例的心跳信息展现出来，需要关注返回结果的 RS_CODE 和 RS_MESSAG 两列：

• 当RS_CODE为INIT, OK, TIMEOUT时，message为null，
• 只有当RS_CODE为ERROR时，message才会显示最近一次心跳失败的信息

2. 通过下面的命令查看心跳连接的状态，通过 used_for_heartbeat = ‘true’过滤出

https://github.com/actiontech/dble-docs-cn/blob/master/2.Function/2.001_manager_dble_information.md#20112-backend_connections

下面列举了RS_CODE异常时的常见原因

当RS_CODE为ERROR时，具体可以通过message来判断失败的原因，下面列举常见的：

• MySQL实例异常关闭
• dble db.xml配置中的MySQL用户没有有权限执行心跳语句
• 网络环境比较差（针对此种情况，dble heartbeat提供errorCount重试次数）
• mysql的版本不对，导致dble连接不上后端MySQL（比如MySQL 5.1）
• dble 本身 cpu 负载比较高，导致处理心跳连接异常

当RS_CODE为Timeout时，下面列举常见的：

• MySQL实例是否本身负载比较高，执行心跳语句延迟
• dble 本身 cpu 负载比较高（比如发生了较长时间的gc，可以查看对应心跳超时时间段的gc日志），导致处理心跳连接不及时
• 排查MySQL机器的网络情况，比如tcp 的半连接队列是否满了，导致握手包被丢弃
• 针对心跳超时，dble进行了一轮修复，若不是上述原因，请更新至最新的小版本再观测

其他情况可以联系官方人员排查

[wangjuan-action]

如果遇到MySQL主从延时值过大或反复跳动，可参考 https://mp.weixin.qq.com/s/E1Pg3zq7Zb70oRbsGGaTjg 进行排查