结果这样重装安装的环境，依旧报错，报错内容不变。
3.再次定位 # cluster_run_all_nodes "hostname; ls -lh /tmp/4803 " vnode01 srw-rw-rw- 1 501 501 0 9月 7 09:54 /tmp/4803 vnode02 srw-rw-rw-. 1 501 501 0 9月 7 09:19 /tmp/4803 vnode03 srw-rw-rw-. 1 501 501 0 9月 7 09:19 /tmp/4803 vnode04 srw-rw-rw- 1 501 501 0 9月 7 09:14 /tmp/4803可以看到/tmp/4803的所属用户和组都是未被识别的uid和gid，怀疑是否是这个问题影响，导致spread进程无法集群间通信。
4.解决问题再次重装时，dbadmin用户和组的uid，gid有了变化，所以我们将这个文件也先删除掉。
cluster_run_all_nodes "hostname; rm -rf /tmp/4803"此次环境dbadmin用户和组先统一：
--保持统一的uid gid cluster_run_all_nodes "hostname;groupadd -g 700 verticadba" cluster_run_all_nodes "hostname;useradd -g verticadba -u 700 dbadmin"再次重装，建库时，跟踪/tmp/4083的状态,发现各节点/tmp/4803依次开始正常：
# cluster_run_all_nodes "hostname; ls -lh /tmp/4803 " vnode01 srw-rw-rw- 1 dbadmin verticadba 0 9月 7 17:04 /tmp/4803 vnode02 ls: 无法访问/tmp/4803: 没有那个文件或目录 vnode03 ls: 无法访问/tmp/4803: 没有那个文件或目录 vnode04 ls: 无法访问/tmp/4803: 没有那个文件或目录最终确定果然就是这个问题,最终建库成功。
5.总结在重装Vertica集群时，需要关注 /tmp/4803是否权限有问题，否则会导致spread进程故障，进而导致整个库起不来。
各节点dbadmin用户的uid和gid尽量保持一致。