成功解决 -- An I/O error occured while sending data to the backend.

问题描述

Oracle通过kettle工具同步数据到Gauss报IO错误。

历史经验

• 应用侧

1. 获取连接后未及时关闭（DriverManager.gerConnection后未调用con.close），下次再使用连接时已被数据库侧清除，用户感知到IO错误。
2. 使用kettle表输入/输出方式同步数据：原理是开启一个事务，一次执行1000个insert，效率低，占用网络资源多，频繁地连接和断开，就会出现网络压力太大导致断开的问题。

• 数据库侧

1. 管理员通过 select pg_terminate_backend(pid) 主动终止连接
2. CN 节点（接收SQL请求的节点）重启
3. 数据库磁盘使用率 > 90% 转为只读

排查步骤

• 步骤1：服务端自检

1. 日志中无主动关闭用户连接的记录
2. CN节点问题出现附近无重启记录（如何查看）
3. 数据库磁盘状态良好

• 步骤2：从kettle工具入手

1. 客户确实使用的是表输入输出方式进行入库的
2. 提供kettle=>gauss插入数据的推荐用法(https://bbs.huaweicloud.com/forum/thread-26690-1-1.html)；底层用的copy语法，一次连接，每次传输量大，连接资源花销也不大。
3. 提供kettle=>gauss插入更新数据的解决思路；新建临时表 -> 通过推荐方式导入到临时表 -> 将临时表和目标表执行merge into。
4. 目前gauss还不支持upsert(插入更新)语法，已经在规划中。

• 步骤3：用户未反馈问题是否解决，但其它用户反馈出现非kettle工具与Gauss集群交互IO报错，排查方向转向“连接超时清除”

1. 部署服务端监控脚本，观察有无临界超时时间仍处于“idle”状态的连接
2. 应用侧自检：有无及时关闭连接，业务运行报错时机（即立即报错还是运行中报错）
3. 排查结果：应用侧使用连接池管理连接，业务整体运行时间 < 连接超时时间，基本排除连接超时，问题未解决。

• 步骤4：研发求助网络专家，排查到集群安装时设置的LVS存在错误

1. 各个方向均已排查完毕，仍未解决问题
2. 求助网络专家，提供另一条线索：keepalived中设置vrrp_id是否在IP段内冲突
3. 排查集群的LVS，发现租户1集群和租户2集群位于同一网段，且安装时你设置的vrrp_id设置相同，找到问题跟因

4. root # less /etc/keepalived/keepalived.conf

解决方法

• 修改keepalived中设置vrrp_id 并重启 root# > sh /etc/init.d/gs_keepalived restart

1. GaussDB A的lvs是基于vrrp+Keepalived+lvs架构，virtual_router_id意为虚拟路由的ID号,这个标识是同一个vrrp协议实例使用唯一的标识，即同一个VRRP组内，master和backup的virtual_router_id是一致的；
2. virtual_router_id决定多播的MAC地址，同时在整个vrrp内是唯一的，每个主备节点设置必须一样,相同的VRID 为一个组,因为其通信协议vrrp协议是多播方式；
3. 但同一网段内（没有划分vlan和物理网络隔离）的网络架构下，VRRP协议在多播的时候需要根据不同的virtual_router_id来区分不同的集群，从而将数据包转发到指定的cn上；
4. 如果不划分，在多播的时候就会给全都发，导致报文分发到了非预期的router上，而错误的节点接收到了错误的包，导致上层业务报连接超时。