商丘网站制作,做网站哪些,商丘seo博客,seo3立体构型Cassandra是Facebook开源的一个NoSQL数据库#xff0c;它除了具备一般的NoSQL分布式数据库特点以外#xff0c;最大的一个特点是去中心化架构设计#xff0c;这和Hadoop HDFS/HBase等不一样#xff0c;比如HDFS分为NameNode和DataNode#xff0c;而Cassandra集群中所有节点… Cassandra是Facebook开源的一个NoSQL数据库它除了具备一般的NoSQL分布式数据库特点以外最大的一个特点是去中心化架构设计这和Hadoop HDFS/HBase等不一样比如HDFS分为NameNode和DataNode而Cassandra集群中所有节点都是数据节点每一个节点都在集群中承担相同的角色。 我们开始在2013年做大数据存储系统选型过程中也考虑过Cassandra不过最终选择了MongoDB之后又使用Elasticsearch一直与Cassandra无缘不过前几年我们引入了一款商业的AI类系统它的后台存储系统选择了Cassandra迫使我们不得不去熟悉Cassandra系统然而一般是运维人员去维护它常常也是咨询厂家运维人员来解决具体问题。 最近由于某地市平台的运维人员休长假由我来暂时接管其运维工作。这个系统中的Cassandra被限制只能存储2亿特征向量数据到达这个阙值之后系统将不永许再新增任何特征向量记录。我们每天大概几百万的采集量大概3月左右就会存储满所以运维人员写了一个定时清除脚本指定一个上限阙值一旦超过这个阙值脚本将删除最早的一天数据一直到存储量低于这个阙值才停止比如阙值190000000但是在crontab配置时编辑错误也没有事后进行检查致使一直没有生效时间到了3个月之后某一天客户发现数据前一天没有入库马上给我电话他立即赶到现场稍微分析发现Cassandra容量已经刚好达到2亿厂家业务系统停止入库了。 得知具体原因之后我和主开发人员商量清理一部分数据反正客户也不要求那么多天数据我们的特征向量存储远比图片文件存储的时间长所以主开发人员给我建议是先删除5000万。这个数据量也不大我也没想那么多使用厂家删除库接口进行删除我们是一天一个特征向量库的于是用Python脚本调用厂家接口从最早库进行删除一直删除到库容量小于1.5亿删除倒是很快完成删除之后我第一时间用库列表查询接口去看第一次查询还能出结果但是再次查询的时候接口就返回错误: no hosts availed in the pool整个系统所有接口都不能调用了先前还只是新增特征向量接口不行现在什么都不行吓了我一跳系统这么脆弱。 一边第一时间联系厂家远程运维人员一边登录这台AI系统所在服务器按厂家运维人员去看系统状态这个系统只有一台机器厂家却在上面安装了一个k8s单集群本人没有使用过k8s系统一切只能边baidu边摸索用命令看容器状态 kubectl get pod -A 发现Cassandra也是只有一个容器实例已经是0/1了肯定是发起删除操作的时候让整个系统垮掉了于是手工删除它让k8s去重启它 kubectl delete pod -n component Cassandra-default-0 但是还是启动不起来于是强制删除 kubectl delete pod --force --grace-period0 -n compent Cassandra-default-0 容器终于启动起来了然后看容器日志 kubectl logs -f -n component Cassandra-default-0 这时日志没有ERROR级别错误只是大量gc1日志看来JVM在做大量垃圾回收处理这肯定跟删除有关了。 再访问厂家API接口不管是查询库列表接口、创建库接口还是新增特征向量接口、搜索特征向量接口都不可用全部返回先前的错误描述no hosts availed in the pool。 咨询厂家运维人员运维人员去问内部开发人员答复是从来没碰到一次性删除5000万数据的删除1千万数据可能要5个小时。我说5000万数据不是要25个小时这简直不可接受啊但是也没办法对方是大公司开发人员应该是有水平只有等了。 但是我还是不甘心就要自己分析Cassandra为什么会这么慢系统内部状态是什么。于是就进入容器直接用docker命令 docker ps | grep cassandra docker exec -it container-ID /bin/bash 进入容器之后看进程 ps -ef | grep cassandra 然后看端口 sudo netstat -ntlp 9042 native协议服务端口 7199 : JMX服务端口 这两个重要的端口都是正常存在的于是用cqlsh工具去连接需要密码问厂家运维人员回答账号在k8s环境里于是执行 kubectl gett secrets password-secrets -o yaml | grep cassandra 得到一个json格式的账号列表Cassandra、MySQL、MinIO等登录账号都在这里于是对密码进行Base64解码得到密码原文。 登录Cassandra cqlsh -u username -p password help 所有命令都出来了然后看键空间和表找到特征向量所在的表其实就一张表而已查询都没有问题感觉Cassandra应该已经好了啊不至于要25个小时再去看docker容器日志全部是INFO和DEBUG级别日志都是在删除sstable数据看不出任何问题。 我怀疑Cassandra可能已经正常说不定是厂家自己的应用系统的问题。于是咨询厂家运维人员他们自家开发的系统到底是怎么一个部署架构之间是怎么调用的我要分析一下他们的系统到底是打印什么错误。 然后我和厂家运维从kong网关查起发现厂家的两个程序有大量错误错误描述还是no hosts availed in the pool。 我怀疑是cql连接池处理不好于是重启厂家那两个需要连接Cassandra系统重启之后再去调用厂家所有API接口一切正常。阿弥陀佛庆幸自己没有听他们开发人员所谓的1千万数据删除要5个小时的断论坚持了自己去分析各个系统分析系统运行日志整个系统提前恢复服务。 这个过程中也怀疑过Cassandra的删除机制墓碑问题其实不可能那么慢5000万数据对一个NoSQL数据库应该不至于致命但是稳定性确实有问题单点部署情况下删除导致单点故障而不能恢复确实是Cassandra一个小问题但是一般用Cassandra应该至少3个以上节点做集群做副本集才有意义。
