0x1 故障问题
某项目机器宕机无法启动，是vertica节点之一，好在 vertica 的冗余为1，不至于数据丢失，但是3节点丢失一个节点会导致vertica性能低下，如何能够更换节点让vertica能够正常恢复呢？
0x2 恢复方案
以下是恢复方案的分析：
方案一：尝试启动机器，添加节点，停止节点，在集群管理中选择replace。结果不行，在线 replace 只能选择在线的机器，而不能选择停止运行的机器
方案二：vertica 更换节点最好的方式就是踢掉此节点，然后增加新的节点，但是目前的情况是故障节点无法启动，而vertica要踢掉节点就必须要启动，所以这个办法是行不通了
方案三：新机器与故障节点配置的ip一致，并且目录结构也保持一致，正常安装vertica后直接启动，看是否能恢复数据到此节点上
这个方案有几个坑，如下：
-
如果是在新机器执行的安装，那么恢复集群后，只在原集群的节点中可以看到集群是up的正常状态，在新机器admintools进去看不到集群，甚至提示没有任何节点 解决方案： 需要同步配置文件到此机器，可以选择在集群中使用 distribute config files，那么会同步此节点的配置到选择的节点，这样可以正常显示状态
-
不知道原来的安装参数是什么，可能有一些特殊的配置，那么可以通过
/opt/vertica/config/admintools.conf查看原集群的安装参数
这个方案在安装方式上采用了两种模式都可行：
- 新节点安装，install_vertica 参数 hosts 只填新节点，然后在原集群中选择restart启动这个ip即可，数据自动恢复
- 原集群中的节点执行 install_vertica ，参数 hosts 写所有节点，这样看流程仍然只会安装新节点，所以是没有问题的，完成之后在集群中选择restart启动这个节点，数据恢复
恢复和异常
在使用方案三恢复后 vertica 后通过web查询(jdbc)，有时候会出现如下错误:
SQL Error [4236] [V1001]: [Vertica]VJDBC ROLLBACK: One or more nodes did not open a data connection to this node. This may indicate a network configuration problem. Check that the private interfaces used for communication among the cluster hosts reside in the same subnet and are returned first by host address lookup
恢复后的测试异常问题: 在数据恢复后，集群所有节点up，出现的现象是，在集群未故障的节点查询业务数据，一直报上述错误，但是新替换的节点可以查，如果关闭新节点，那么原来的所有节点又可用了，这个问题展现出来的确实很奇怪
基本上没有找到好的解决方案，在网上检索的资料都是不了了之，所以也无法知道原因，但经过测试发现，发现了几个可能影响的事项，首先安装节点的时候参数与之前的保持一致，再就是不能使用子网卡，因为我们采用一台已有的其他机器来增加子网卡的方式恢复。所以最后一次尝试安装，把原故障节点ip替换到此机器上（不再是子网卡的方式新增），并拿到 vertica 集群的安装参数，结果恢复后可以查询正常
评论