yashandb厓山数据库的安装 前置 前置软硬件需求、系统配置参考文档即可 安装 这里说下重点，下面的操作最好都使用 yashan 用户执行，否则会有错误，且提示非常不明显 使用第一个方法的 ./bin/yasboot init 方式交互安装，但根本没有看到这个子命令，所以选择手动安装 首先在远程机器 or 本地机器生成配置文件 ./bin/yasboot package se gen --cluster yashandb --recommend-param -u yashan -p thisISsuccez1212 --ip 192.168.10.165 --port 22 --install-path /data/yashan/yasdb_home --data-path /data/yashan/yasdb_data --begin-port 1688 执行安装数据库软件 ./bin/yasboot package install -t hosts.toml -i yashandb-23.2.4.100-linux-x86_64.tar.gz 部署数据库集群 ./bin/yasboot cluster deploy -t yashandb.toml 执行额外的环境变量，否则无法正常执行维护命令 简单维护 启动停止集群 关闭：使用 sys 登录数据库后用 shutdown immediate 关闭，这里跟 oracle 类似，但启动无法登录 sys 执行 startup 启动：使用 yasboot 维护命令来启动集群 清理归档日志 ALTER DATABASE DELETE ARCHIVELOG ALL FORCE; # 这是强行清理，不建议，建议按照正规流程 报错： YAS-06013 yashandb too many sql handle # 这是压测时候数据库日志出现的错误，使用 show parameter 看了下 max_sessions 是 1500，而并发测试才 900，没有什么思路，所以优化了如下参数 alter system set MAX_SESSIONS=3000 scope=spfile; alter system set OPEN_CURSORS=4096 scope=spfile; alter system set MAX_WORKERS=1024 scope=spfile; alter system set WORK_AREA_POOL_SIZE=4G scope=spfile;

mysql锁问题Lock wait timeout exceeded; try restarting transaction 问题 某同事提交故障如下: 显示执行的SQL为： UPDATE USER_STATUS SET REMEMBER_ME = '[["soo6K5cZk","thilY3jZk","5865d0554677eff2ba06014891a5635a",1734675764872]' WHERE USER_ID = 'xxx' # 报错 Lock wait timeout exceeded; try restarting transaction 排查 查询当前运行的sql，以分析是否有锁冲突 show processlist; # 结果只有当前运行的sql，这条update只有单条数据，理论上应该很快，但当前已经执行了超过 40 秒，到最后反馈超时 查询当前的事物表，存在哪些事物在执行 select * from information_schema.innodb_trx; # 查询到这条sql已经回滚结束了，但是仍然有一个几小时之前的事物，没有显示sql语句 根据其id，和运行中的信息关联查询 select * from (SELECT * FROM information_schema.processlist p LEFT JOIN information_schema.INNODB_TRX t ON p.id = t.trx_mysql_thread_id) a where id=7936144\G; # 发现其状态是 Running，但没有sql 如何处理 评估对业务影响不大，所以杀掉这个线程id后执行正常

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 最后一个参数用来忽略文件系统的检测

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 集群的安装参数，结果恢复后可以查询正常