常见问题

1. 安装

问题1

现象

yum install matrixdb安装包后报错cpio read error

原因

用户环境为windows，使用vm15虚拟机，windows下载安装包后文件拖拽到虚拟机，导致文件被截断

解决方案

使用vm共享目录机制传输数据，参考https://blog.csdn.net/highning/article/details/106000215

问题2

现象

创建mars扩展时，报错:

could not load library "/usr/local/matrixdb-4.0.0.enterprise/lib/postgresql/mars.so": /lib64/libarrow.so.300: undefined symbol: LZ4F_resetDecompressionContext

原因

matrixdb 4依赖arrow 300， arrow需要LZ4的版本>= 1.8

解决方案

升级lz4

问题3

现象

初始化时报错：

could not connect to server: No route to host
 Is the server running on host "192.168.88.203" and accepting
 TCP/IP connections on port 40000?
 (seg0 192.168.88.203:40000)

原因

203机器关掉了iptables,但是没有disable,重启机器后，防火墙又起动了，端口默认没有放开，导致初始化时机器无法通信，现象就是初始化一直卡住，无法完成。

解决方案

清空203机器上的防火墙规则，停掉iptables服务并且disable，防止重启后，网络不通。

问题4

现象

setuptools报告不支持参数:

unknown distribution option:"long_description_content_type'

原因

setuptools 版本比较老

解决方案

sudo python3 -m pip install --upgrade setuptools

问题5

现象

卸载重装后，无法重新初始化集群

原因

重装集群需要做必要的清理工作

解决方案

删除 mxadmin用户的~/.matrixdb.env
删除 /etc/matrixdb/cluster.conf
重启supervisor
- systemctl restart matrixdb.supervisor.service
再次刷新安装界面: http://[主节点IP]:8240/installer

2. 网络

问题1

现象

JDBC查询压力测试，并发50，连接池采用阿里的druid。2.5分钟内响应时间平稳，之后响应时间变长，master开始出现如下错误：

ERROR "failed to acquire resources on one or more segments", "could not connect to server: Connection timed out"

segment无error/panic log

原因

分布式数据库会有大量的TCP/UDP数据传输，每次传输都会使用不同的端口号，这些端口号或连接在OS看来都是一次路由（连接conn），系统参数nf_conntrack_max的意思是OS最多可以同时维护路由信息的个数。因为我们的多台虚拟机在一个物理机上，虚拟网络用的应该是NAT，这样当大量并发查询同时来的时候，会导致虚拟路由信息暴增，可能在短时间内超过nf_conntrack_max限制，进而导致网卡主动丢弃掉来不及处理的package。这也可以解释之前一段时间内并发查询越大越容易发生丢包的现象。

解决方案

修改内核参数

sudo sysctl net.netfilter.nf_conntrack_buckets=262144
sudo sysctl net.netfilter.nf_conntrack_max=1048576

问题2

现象

查询中motion开销大

原因

环境为云环境，云环境对UDP处理低效，或导致UDF延迟高或丢包概率高，间接导致UDF数据传输时间变长
用户日志级别设置为debug5，大量log输出的过程中会影响UDP传输效率

解决方案

切换TCP interconnect
开启ic proxy
调整log Level

3. 查询

问题1

现象

UI客户端访问远程数据库，长查询过程中或长时间idle后发查询，客户端有些时候会收到log:

server closed the connection unexpectedly

原因

客户端存在查询超时cancel设置，或idle超时cancel连接设置

解决方案

更改客户端超时设置，取消超时

问题2

现象

PARTITION表简单Filter操作的UNION ALL查询比IN查询慢

原因

PARTITION表的IN查询，分区裁剪后只有1个default分区，但UNION ALL查询中每个子查询都裁剪到了default分区，做了多次default分区的扫描，性能影响明显

解决方案

对于PARTITION表

尽量避免default分区
尽量不用UNION而用in子句

问题3

现象

insert int类型，再select查询单独跑很快，放到plpgsql function里很慢

原因

plpgsql function内的查询是通过SPI运行，SPI Plan输出结果里是两表Join，采用了nestloop，语句rows=1，没有analyze

解决方案

执行analyze

问题4

现象

PARTITION分区裁剪更新操作，两个session独立更新会导致互锁

原因

分布式死锁

解决方案

打开分布式死锁检测

gpconfig -c gp_enable_global_deadlock_detector -v on

4. 存储

问题1

现象

数据加载性能低

原因

gpcheckperf看磁盘性能，网络性能，发现磁盘性能仅 80MB/s

解决方案

加载多块磁盘提升IO性能，WAL和Data数据盘分开提升IO性能

问题2

现象

mxgate同时开启加载30张表，报错：

failed to acquire resources on on or more segments ,fatal out of memory

原因

PG/GP是多进程模式，高并发请求过来，连接数过多，无法分配内存给相应的请求，从而报错。

解决方案

调整参数/etc/sysctl.conf vm.overcommit_memory = 2 mxgate prepared=10改为prepared=5

5. PXF

问题1

现象

PXF部署后，访问HDFS报错：

remote component error，Failed connect to localhost:5888; Connection refused (libchurl.c:950)

解决方案

PXF访问文件的方式需要在master节点开启pxf server，但是数据文件需要在segment pxf上
pxf/servers/core-site.xml和hdfs-site.xml一定要和hadoop配置文件相同
pxf/servers/core-site.xml配置用户访问权限
hadoop上文件的用户名和组需要和pxf/core-site.xml指定的一致

问题2

现象

文件入库时，某一个字段包含换行符，将一行数据切分成两行，再以分隔符切分，就会导致数据与字段数不一致，也就是说一行数据里有两个\n 一个在中间一个在尾部但是中间那个不能被当做换行符处理

解决方案

可以在option里加入escaple 'off'
也可以使用 format 'text:multi'