问题描述
Oracle通过kettle工具同步数据到Gauss报IO错误。
![在这里插入图片描述](https://img-blog.csdnimg.cn/20210327093355660.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ4MDc1MA==,size_16,color_FFFFFF,t_70)
历史经验
- 获取连接后未及时关闭(DriverManager.gerConnection后未调用con.close),下次再使用连接时已被数据库侧清除,用户感知到IO错误。
- 使用kettle表输入/输出方式同步数据:原理是开启一个事务,一次执行1000个insert,效率低,占用网络资源多,频繁地连接和断开,就会出现网络压力太大导致断开的问题。
- 管理员通过 select pg_terminate_backend(pid) 主动终止连接
- CN 节点(接收SQL请求的节点)重启
- 数据库磁盘使用率 > 90% 转为只读
排查步骤
- 日志中无主动关闭用户连接的记录
- CN节点问题出现附近无重启记录(如何查看)
- 数据库磁盘状态良好
- 客户确实使用的是表输入输出方式进行入库的
- 提供kettle=>gauss插入数据的推荐用法(https://bbs.huaweicloud.com/forum/thread-26690-1-1.html);底层用的copy语法,一次连接,每次传输量大,连接资源花销也不大。
- 提供kettle=>gauss插入更新数据的解决思路;新建临时表 -> 通过推荐方式导入到临时表 -> 将临时表和目标表执行merge into。
- 目前gauss还不支持upsert(插入更新)语法,已经在规划中。
- 步骤3:用户未反馈问题是否解决,但其它用户反馈出现非kettle工具与Gauss集群交互IO报错,排查方向转向“连接超时清除”
![在这里插入图片描述](https://img-blog.csdnimg.cn/20210327093947984.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ4MDc1MA==,size_16,color_FFFFFF,t_70)
- 部署服务端监控脚本,观察有无临界超时时间仍处于“idle”状态的连接
- 应用侧自检:有无及时关闭连接,业务运行报错时机(即立即报错还是运行中报错)
- 排查结果:应用侧使用连接池管理连接,业务整体运行时间 < 连接超时时间,基本排除连接超时,问题未解决。
- 步骤4:研发求助网络专家,排查到集群安装时设置的LVS存在错误
- 各个方向均已排查完毕,仍未解决问题
- 求助网络专家,提供另一条线索:keepalived中设置vrrp_id是否在IP段内冲突
- 排查集群的LVS,发现租户1集群和租户2集群位于同一网段,且安装时你设置的vrrp_id设置相同,找到问题跟因
![在这里插入图片描述](https://img-blog.csdnimg.cn/20210327094041859.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ4MDc1MA==,size_16,color_FFFFFF,t_70)
root # less /etc/keepalived/keepalived.conf
![在这里插入图片描述](https://img-blog.csdnimg.cn/20210327094102502.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQ4MDc1MA==,size_16,color_FFFFFF,t_70)
解决方法
- 修改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上,而错误的节点接收到了错误的包,导致上层业务报连接超时。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)