背景信息：一个7*24小时的交易系统，采用集中式实例，1主5从。凌晨执行卸数批量时，出现"proxy erroy：no available address"报错。报错的SQL语句中采用了hint语法/*slave:localslave,slaveonly,20*/，表示选择主从延迟小于20s的从库执行sql语句，如果找不到主从延迟小于20s的从库，则报错。
排查思路；
1、查询proxy节点上的interf日志，在报错时间点附近找到了对应的"proxy erroy：no available address"记录，确认报错。
2、检查问题时间点附近慢SQL，未发现大事务，排除大事务造成的主从延迟。
3、结合造成主从延迟的原因+报错信息，可以排除掉长时间未提交事务、锁超时。
4、 查看赤兔binlog增长速率，发现问题时间点附近binlog有突增，再比较interf日志生成时间，发现问题时间点附近短短几分钟内就产生了好几个大小1G的日志，由此，可以确认造成主从延迟的原因为短时间内有大量写入binlog的sql执行。
5、通过proxy日志问题时间段过滤出insert、delete、update语句，发给项目组确认，为另外一个批量发起的SQL。
至此，问题原因以及查明：另外一个批量在短时间内发起大量执行速度很快的insert、delete、update语句，造成了所有从库的主从延迟超过20s，卸数批量SQL语句找不到满足的从库，因而报错。后续整改方案就是卸数批量避开其他批量以及业务高峰期。