docker安装vertica 目的 主要的目的是为了快速的启动、测试vertica，不用于生产环境 快速启动 docker run -p 5433:5433 -p 5444:5444 \ -e APP_DB_USER="dbadmin" \ -e APP_DB_PASSWORD="vertica123aa_1" \ --mount type=bind,source=/data/vertica,target=/data \ --name vertica_ce_v12 \ harbor.succez.com/sz/vertica/vertica-ce:12.0.4-0 要指定 APP_DB_USER、APP_DB_PASSWORD，只指定密码不生效，并且跟版本有关系，以前版本变量名不同 异常问题 看了N遍参考文档，在 docker swarm 上仍然无法正常启动，错误 OSError: [Errno 9] Bad file descriptor，一度怀疑是文档、镜像有问题，后来经过测试发现，不使用 nfs 就可以，怀疑使用nfs 无法正常找到文件 思考问题 那么 vertica 是如何查找文件的呢？

openstack安装vertica的问题 异常问题 在 openstack 上安装vertica的时候出现了几个问题 无法修改io scheduler，/sys/block/sda/queue/scheduler修改后查看仍然是none 出现错误 Error: 'NoneType' object has no attribute 'split'，在添加参数 --ignore-install-config 后仍然显示HALT 级别的错误，无法跳过 问题的根本原因： The root of the problem is that if you are installing Vertica on OpenStack it will have a metadata server (169.254.169.254), and if the install python script gets a response from it, it assumes its running under AWS, so it will request AWS specific metadata which doesnt exist, so it gets no response from the OpenStack metadata server. To fix the issue issue you have to edit the aws_metadata.py (/opt/vertica/oss/ python/lib/python2.7/site-ackages/vertica/system/aws_metadata.py) file. Inside the load function (def load, not in the def init) replace the self.is_aws part to self.is_aws = False 在文件中搜索def load后查看最近一行的self.is_aws = XXX ，修改内容为False，然后重新安装 参考链接： https://forum.vertica.com/discussion/235490/vertica-install-on-centos PS: 不知是否可以使用 --ignore-aws-instance-typ 这个参数跳过

vertica不支持xfs文件系统 文件系统问题 这是个老问题，现在的高版本vertica已经对文件系统的要求很低了，基本上都支持。所以这里只是记录一下历史 安装系统默认分区，使用的xfs文件系统，vertica在安装的时候只是给出了警告，把安装级别设置为FAIL仍然可以安装成功，但是在创建数据库页面遇到了错误，提示不支持的文件系统类型 需要使用命令行参数来创建数据库，使用 admintools -t create_db -D /home/dbadmin -c /home/dbadmin -d vetc -p dbadmin -s 192.168.3.250 --skip-fs-checks 最后一个参数用来忽略文件系统的检测

python连接vertica数据库 代码 import vertica_python import ssl conn_info = {'host':'xxx.xxx.com','port':5433,'user':'dbadmin','password':'dbadmin','database':'vtc','ssl':True} with vertica_python.connect(**conn_info) as conn: cur = conn.cursor() cur.execute('select current_schema()') print(cur.fetchone()[0])

vertica故障恢复之替换节点 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 集群的安装参数，结果恢复后可以查询正常