问题描述
Oracle通过kettle工具同步数据到Gauss报IO错误。
历史经验
- 应用侧
- 获取连接后未及时关闭（DriverManager.gerConnection后未调用con.close），下次再使用连接时已被数据库侧清除，用户感知到IO错误。
- 使用kettle表输入/输出方式同步数据：原理是开启一个事务，一次执行1000个insert，效率低，占用网络资源多，频繁地连接和断开，就会出现网络压力太大导致断开的问题。
- 数据库侧
- 管理员通过 select pg_terminate_backend(pid) 主动终止连接
- CN 节点（接收SQL请求的节点）重启
- 数据库磁盘使用率 > 90% 转为只读
排查步骤
- 步骤1：服务端自检
- 日志中无主动关闭用户连接的记录
- CN节点问题出现附近无重启记录（如何查看）
- 数据库磁盘状态良好
- 步骤2：从kettle工具入手
- 客户确实使用的是表输入输出方式进行入库的
- 提供kettle=>gauss插入数据的推荐用法(https://bbs.huaweicloud.com/forum/thread-26690-1-1.html)；底层用的copy语法，一次连接，每次传输量大，连接资源花销也不大。
- 提供kettle=>gauss插入更新数据的解决思路；新建临时表 -> 通过推荐方式导入到临时表 -> 将临时表和目标表执行merge into。
- 目前gauss还不支持upsert(插入更新)语法，已经在规划中。
- 步骤3：用户未反馈问题是否解决，但其它用户反馈出现非kettle工具与Gauss集群交互IO报错，排查方向转向“连接超时清除”
- 部署服务端监控脚本，观察有无临界超时时间仍处于“idle”状态的连接
- 应用侧自检：有无及时关闭连接，业务运行报错时机（即立即报错还是运行中报错）
- 排查结果：应用侧使用连接池管理连接，业务整体运行时间 < 连接超时时间，基本排除连接超时，问题未解决。
- 步骤4：研发求助网络专家，排查到集群安装时设置的LVS存在错误
- 各个方向均已排查完毕，仍未解决问题
- 求助网络专家，提供另一条线索：keepalived中设置vrrp_id是否在IP段内冲突
- 排查集群的LVS，发现租户1集群和租户2集群位于同一网段，且安装时你设置的vrrp_id设置相同，找到问题跟因
root # less /etc/keepalived/keepalived.conf
解决方法
- 修改keepalived中设置vrrp_id 并重启
root# > sh /etc/init.d/gs_keepalived restart
- GaussDB A的lvs是基于vrrp+Keepalived+lvs架构，virtual_router_id意为虚拟路由的ID号,这个标识是同一个vrrp协议实例使用唯一的标识，即同一个VRRP组内，master和backup的virtual_router_id是一致的；
- virtual_router_id决定多播的MAC地址，同时在整个vrrp内是唯一的，每个主备节点设置必须一样,相同的VRID 为一个组,因为其通信协议vrrp协议是多播方式；
- 但同一网段内（没有划分vlan和物理网络隔离）的网络架构下，VRRP协议在多播的时候需要根据不同的virtual_router_id来区分不同的集群，从而将数据包转发到指定的cn上；
- 如果不划分，在多播的时候就会给全都发，导致报文分发到了非预期的router上，而错误的节点接收到了错误的包，导致上层业务报连接超时。
扫一扫
7700
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
