【GAUSSDB(DWS)】GDS常见问题FAQ

Q1:集群遇见报错unexpected EOF on GDS怎么处理？

原因分析：当集群中出现大量这种错误时候首先考虑GDS机器的网络参数设置是否符合要求。可以参考下面的参数

参数参考值：

net.core.somaxconn = 65535  
net.ipv4.tcp_max_syn_backlog = 65535  
net.core.netdev_max_backlog = 65535  
net.ipv4.tcp_retries1 =5  
net.ipv4.tcp_retries2 = 60  
复制

查看方法

cat /proc/sys/net/core/somaxconn
cat /proc/sys/net/ipv4/tcp_max_syn_backlog
cat /proc/sys/net/core/netdev_max_backlog
cat /proc/sys/net/ipv4/tcp_retries1
cat /proc/sys/net/ipv4/tcp_retries2
复制

修改方法

修改对应参数：
vim /etc/sysctl.conf
永久生效：
sysctl -p
复制

Q2: GDS遇到到网络层错误 “connection timed out” 怎么处理？

原因1：由于高并发导入导出时GDS端向DN造成发送数据网络拥塞，当出现发送不成功后GDS会接收到网络层错误connection timed out 并主动 断开连接，之后DN 在下次请求GDS数据时也会接收到connection reset by peer 网络层错误. 经常发生在 数据传输过程中,可以调整系统 net.ipv4.tcp_retries2和 net.ipv4.tcp_retries1 参数

原因2： 也可能是因为gds处理请求较慢，以至于backlog listen队列被填满后，新来的请求会被拒绝,一般发生在建连截断。可以调大net.core.somaxconn参数解决

解决方法： 同上：

net.core.somaxconn =  65535  
net.ipv4.tcp_max_syn_backlog =65535  
net.core.netdev_max_backlog = 65535  
net.ipv4.tcp_retries1 =  5  
net.ipv4.tcp_retries2 =  60  
复制

Q3: DN 报错 ”The peer GDS has performed an orderly shutdown on current connection.“ 什么原因？

可能原因：

1. gds挂掉
2. tcp连接异常，参考上面两种情况修改gds参数。gs_check巡检集群系统参数是否合理.

Q4: GDS报错句柄不足，报错 too many open file 怎么处理？

原因分析： gds进程占用的文件句柄超过设置的值。 解决办法：

1. 修改最大进程打开文件句柄数:

/etc/security/limits.conf

* soft nofile 640000
* hard nofile 640000    
复制

1. 修改/etc/security/limits.d/*目录里的配置文件，对于配置文件中存在nofile配置的都需要修改，没有就跳过； 默认优先使用limits.d目录里的配置，再使用limits.conf的配置

* soft nofile 640000
* hard nofile 640000
复制

1. 修改 /etc/systemd/system.conf，修改行：DefaultLimitNOFILE=640000 保存退出.
2. 重新加载systemd服务配置

systemctl daemon-reload
systemctl daemon-reexec
复制

1. 重新打开一个session 以集群用户重启gds进程.
2. 执行cat /proc/gds的pid/limits查询，参数已更改.

Q5： GDS导入发现集群gaussdb IO异常高100%什么原因？

可能原因： 内表中包含了大量索引，如果是btree索引导数过程中大量的索引操作导致系统IO非常高。 排查方法： iotop 观察哪一个进程占用的io非常高，

   Total DISK READ: 0.00 B/s | Total DISK WRITE: 259.32 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
111958 be/4   sheng      0.00 B/s   16.73 K/s  0.00 %  0.00 % postgres: stats collector
54920 be/4   sheng      0.00 B/s    6.69 K/s  0.00 %  0.00 % gaussdb --coordinator -i -p 44548 -c log_statement=all -M normal -c logg~  sheng/GAUSS200_OLAP_TRUNK/Code/src/test/regress/./tmp_check/coordinator2
54986 be/4   sheng      0.00 B/s    500M/s  0.00 %  0.00 % gaussdb --datanode -i -p 44556 -c log_statement=all -M normal -c 
复制

发现 dn 进程号54986 写io非常高。
gstack 54986|grep -i write
查看当前进程在做什么操作

Q6： ERROR: dn_6001_6002: GDS max line size 1073741823 is exceeded. 为什么？

原因分析： GDS导数时候为了避免文件格式异常导致识别的单行数据过大甚至导致系统oom的场景，gds端限制单行不能超过1G。 解决方法： 首先考虑是否因为csv文件的quote没有成对出现，如果确实是因为quote导致的可以考虑修改外表的quote为不可见字符；
其次考虑单行数据是否确实的超过1G，手动删除改行。

Q7: Cannot enlarge buffer containing 1078343432 bytes by 40783434 为什么？

原因分析：copy或者导入的时候可能由于csv文件格式于文件格式异常导致识别的单行数据过大超过1G；或者单行数据大于1G。
解决方法： 出现此错误时候首先考虑是否因为csv文件的quote没有成对出现，可以考虑修改sql的quote为不可见字符； 其次考虑单行数据是否确实的超过1G，手动删除改行。

Q8: "unexpected message type 0x58 during COPY from stdin" 为什么

原因分析： 由于进群故障，如dn宕机后并且不能重试，cn会向dn下发‘X' 报文意味着cn正在关闭socket。属于正常报错信息。 解决办法： 查看集群日志分析为什么集群出现故障。

Q9: 为什么乱码？

原因分析：乱码的原因本质上是因为 字符编码转换不匹配
copy或者gds导入文件中存在混合编码 或者不能转换的字符 存在的原因： 文件来源于另外一个数据库系统，比如oracle或者gaussdb数据库编码设置为"不校验编码"一般为标准ascii类编码比如postgresql中的sqlascii编码,mysql中使用latin1作为"不校验编码"。 由于这种编码数据库内部都不做校验因此用户无论给定什么编码的数据他都会以字节流的方式存起来（也叫错入错处）但是这样会导致一张表里包含不同的编码的数据，如果从这样的系统导出文件自然文件中也会包含不同编码的内容。当使用这种文件导入到gaussdb中的时候有可能报错如“invalid byte sequence for encoding 'utf8': 0xc3”表示0xc4不是一个有效的utf8编码，或者会将乱码字符插入数据库。 预防方法： 设置客户端，外表，数据库的编码一致 。
解决方法： 设置gds或者copy的容错参数，或者使用iconv 命令将文件转码为统一的编码（其实iconv遇到转换不了的也会报错或者替换成？之类的字符和gaussdb的容错思路差不多） gds或者copy 的容错机制中有一种可以规避（注意是规避）这个问题。 gds和copy都有一个参数"COMPATIBLE_ILLEGAL_CHARS" 会将转换不了的字符替换成‘?'

Q10: 怎么确定文件编码和文件内容是什么编码？

其实一般程序更关心文件内容是什么编码而不是文件是什么编码，文件是什么编码取决于bom头写的是什么编码，文件是什么编码取决于结出来的编码有无乱码。 **注意：通过file 命令或者使用vim看到的编码格式不一定是实际的编码，因为他们都是通过识别bom头来确定是什么编码的，但是有些程序写入的数据并不会像在window上那样设置编码格式头也叫“bom头"**。

教一个方法:将你设置了终端（xshell后者crt）编辑器显示的编码打开文件如果发现语句通顺那这个文件中的内容就是你终端和编辑器的编码。 在中国大陆能看到最多的编码转换问题大多数是由于gbk,gb2312和utf8 的转换问题或者latin1和utf8的编码转换问题。如果不是这两种问题最好能转换成这种问题。因为gaussdb和pg数据库最擅长的就是处理这些编码转换。

​
编码建议：目前线网最常见的编码转换仍然是gbk到utf8编码的转换。虽然gaussdb数据库服务端已经支持设置GBK字符集但是强烈建议在设计之初将服务端数据库编码设置成utf8编码，因为utf8可以识别gbk识别不了的字符，除非你的系统以后都只服务汉字人群。 也不建议将数据库编码设置为“sqlascii”，虽然很灵活但是非常率容易出现混合编码后期维护很差。

如果后面要插入一些比较特殊的字符，虽然目前gaussdb已经支持了服务端的GBK编码但是某些场景可能尚未考虑到。sqlascii编码虽然方便但是后期不好维护。比如gaussdb目前latin1和gbk是不能互相转换的，但是latin1和utf8就可以互相转换。

Q11： GDS外表无数据查询为什么hang？

解决方法：

1. 查询gds和集群是否网络畅通.
2. 查询外表定义中location网络地址是否畅通。
3. 查询外表定义中location的协议是否正确对应 ssl->gsfss 普通协议->gsfs
4. 集群gtm或者dn故障。

Q12： GDS外表有数据数据查询为什么hang？。

解决方法：

1. 查询gds和集群是否网络畅通.

2. 查询外表定义中location网络地址是否畅通。

3. 查询外表定义中location的协议是否正确对应 ssl->gsfss 普通协议->gsfs

4. 集群gtm或者dn故障。

5. 网络拥塞：

6. 排查gds发送端 网络拥塞情况 netstat -taucp|grep gds端口

     tcp        0  74457 mpp116:31001            mpp098:62506            ESTABLISHED 48541/gds
复制

1. 排查DN接受端 网络拥塞情况 netstat -taucp|grep gds端口

  cp        0      0 mpp098:62506            mpp116:31001            ESTABLISHED 8824/gaussdb
复制

1. 观察现象发现GDS端TCP的Send Queue中堆积了大量数据，而DN端Recv Queue中无任何数据。并且通过-t的实时打印可以发现GDS端TCP的Send Queue中数据在一个较长的时间段能不会减少，而且数据减少的周期非常长且亦有阶段性，而DN端未检测到Recv Queue中有数据。因此定位为TCP连接数据传输被阻塞。

Q13： GDS -t 参数原理是什么？

1. 设置GDS并发线程数，其实是设置了GDS指的工作线程池大小。
2. 比如-t 指定为10 系统回见测试当前是否有空工作线程且当前工作线程小于10时候才会创建新线程，不会一启动就事先创建10个线程。
3. GDS是根据导入事务并发数来决定服务运行线程数的。也就是说即使启动GDS时设置了多线程，也并不会加速单个导入事务。未做过人为事务处理时，一条INSERT语句就是一个导入事务.