YMatrix 文档

快速上手

集群部署

数据模型

数据写入

数据查询

SQL参考

运维监控

工具指南

故障诊断

场景应用
版本历史

常见问题

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

原因

YMatrix 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

现象

报错：

error: could not access directory \"/data/mxdata_20221104084534/master/mxseg-1\": Permission denied

mxui 初始化日志：

"error": "execute: do execute: run: initialize_database: 7 errors occurred: * 
error execute \"/usr/local/matrixdb-4.5.0.community/bin/initdb\"\n\n STDOUT:
The files belonging to this database system will be owned by user \"mxadmin\".
This user must also own the server process.

  The database cluster will be initialized with locale \"en_US.utf8\".\n The default text search configuration will be set to \"english\".

  Data page checksums are enabled.

   STDERR:
      initdb: error: could not access directory \"/data/mxdata_20221104084534/master/mxseg-1\": Permission denied\n * error execute \"/usr/local/matrixdb-4.5.0.community/bin/initdb\"
   STDOUT:
      The files belonging to this database system will be owned by user \"mxadmin\".
      This user must also own the server process.\n\n The database cluster will be initialized with locale \"en_US.utf8\".
      The default text search configuration will be set to \"english\".
      Data page checksums are enabled.

原因

data 目录只有所有者有 rwx 权限， 所属组和其他用户无访问权限。

[root@mdw ~]# ll /
total 36
lrwxrwxrwx.   1 root    root       7 Jun  1 19:38 bin -> usr/bin
dr-xr-xr-x.   5 root    root    4096 Oct 26 18:28 boot
drwxr-xr-x   20 root    root    3200 Oct 26 14:45 dev
drwxr-xr-x.  80 root    root    8192 Oct 28 13:53 etc
drwxr-xr-x.   5 root    root    8192 Oct 26 18:17 export
drwxr-xr-x.   5 root    root     105 Oct 26 18:28 home
drwx------.   5 root    root     105 Oct 26 18:28 data

解决方案

修改数据目录权限即可。

sudo chmod 755 /data

问题 5

现象

setuptools 报告不支持参数:

unknown distribution option:"long_description_content_type'

原因

setuptools 版本比较老

解决方案

sudo python3 -m pip install --upgrade setuptools

问题 6

现象

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

原因

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

解决方案

  1. 删除 mxadmin 用户的 ~/.matrixdb.env
  2. 删除 /etc/matrixdb/cluster.conf
  3. 重启 supervisor
    • systemctl restart matrixdb.supervisor.service
  4. 再次刷新安装界面: http://<主节点 IP>:8240/installer

问题 7

现象

ssh 默认端口不是 22

解决方案

.ssh/config 文件中增加主机名、端口号和用户的配置：

Host mdw
   Hostname mdw
   Port 29022
   User mxadmin
Host sdw1
   Hostname sdw1
   Port 29022
   User mxadmin

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 开销大

原因

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

解决方案

  1. 切换 TCP interconnect
  2. 开启 ic proxy
  3. 调整 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 表

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

问题3

现象

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

原因

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

解决方案

执行 ANALYSE

问题4

现象

PARTITION 分区裁剪更新操作，两个会话（Session）独立更新会导致互锁。

原因

分布式死锁

解决方案

打开分布式死锁检测

gpconfig -c gp_enable_global_deadlock_detector -v on

4 存储

问题 1

现象

数据加载性能低

原因

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

解决方案

加载多块磁盘提升 I/O 性能，WA 和 Data 数据盘分开提升 I/O 性能

问题 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)

解决方案

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

问题 2

现象

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

解决方案

  1. 可以在选项里加入escaple 'off'
  2. 也可以使用 format 'text:multi'

6 监控

问题 1

现象

需要离线安装 Grafana 监控

解决方案

点击下载 Grafana 仓库依赖包，创建本地仓库后再安装即可。 

# ls
create_repo.sh  grafana-7.3.6-1.x86_64.rpm  grafana_repo

# sh create_repo.sh
Create ymatrix-grafana repo successfully!

#  yum install --disablerepo=* --enablerepo=ymatrix_grafana   grafana-7.3.6-1.x86_64.rpm