点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！
接收到ADG中断告警，经核查为密码过期导致crontab无法正常运行，影响自动清理任务以及告警发出，进而导致备库无法接收归档。原因是发现主机用户密码设置的90天生命周期，密码过期后会影响该用户下crontab任务的调用，导致依据crontab调用的一些重要脚本失效，如归档清理脚本无法自动清理而耗尽归档目录导致备库无法接收归档；crontab调用的告警脚本无法读取数据，告警信息无法正常发出等。若故障期间相关信息无法第一时间推送出来，会加剧该故障的影响。建议各场地加强对主机用户密码状态的管控，增加主机账号密码过期监控告警。或者建设专门的密码管控平台，将所有主机账号的密码生命周期纳入管理。
出现问题的设备为Proxy主机，安装了zabbix-proxy和snc-proxy，由于分配的磁盘较大，也在上面运行了一个kafka节点，一个zookeeper节点，所有服务都运行在挂载的磁盘空间内，在主机的内存使用率和线程占用飙升后，主机卡死，无法登陆，重启主机失败。由于出现问题的主机在稍早前出现过硬盘资源不够的问题，通过向资源池管理工程师提交资源扩容工单，多分配500g的磁盘。在得到分配后的硬盘时，通过使用lvextend -l +100%FREE dev/vg/root命令和xfs_growfs /dev/mapper/vg-root 命令将未使用空间在线扩展并同步文件系统。挂载点选则为ampdcp目录下。挂载后使用df -h查看主机磁盘挂载成功，但是通过上述命令挂载的磁盘，在/etc/fstab的配置文件中并没有对文件格式xfs配置，所以导致当主机重启后失败。1）在/etc/fstab配置问文件挂载磁盘时，一定要检查好格式是否有问题，否则在重启主机后有可能会失败。2）在配置磁盘挂载的时候，与以前正确的配置文件做一下对比保证磁盘挂载成功。
CRM库业务反馈缓慢，经核查发现大量TX锁，锁源和被堵会话均为insert语句，先通过查杀会话后恢复，十几分钟后TX锁又再次出现，刚开始怀疑业务逻辑有问题导致TX积压，继续kill会话，但业务反馈近期未做更新，抓取故障时间段的awr发现日志写入延迟非常高，查看主机日志发现存在链路报错信息，在更换故障链路后，业务恢复正常。分析故障问题需要结合多方面情况查看，很多表现出来的问题都是被影响的。完善监控体系，增加对syslog的监控。
检查原因，显示zone3合并未完成，observer日志显示有表转储有问题，修改该表primary_zone,对表级切主后合并正常。检查observer/rs日志尝试分析是否为表卡住导致合并延迟，尝试表级切主，应急可以尝试重启问题的zone，甚至集群（该类操作谨慎），mem'store使用低的情况下可以暂时先调大转储阈值，提工单帮助分析。目前该问题暂时无法规避，建议进行数据库升级或者协调OB原厂开发对应的补丁。
行云数据库集群各节点数据存在不均衡情况（整体使用率未超过90%，但部分节点达到了98%）。用Hadoop用户在非namenode 的某个节点上执行：hdfs dfsadmin -setBalancerBandwidth 104857600
- 这个命令是设置带宽的大小，单位是字节，如果带宽太大会使集群之间的IO通信负担过大，可能会使集群的部分进程挂掉，太小会让数据均衡执行太慢，所以要根据集群的性能来设置，默认是10M，推荐用100M。
./start-balancer.sh -threshold 5
- 这个命令是数据均衡开始执行，命令中-threshold 参数后面跟的是HDFS达到平衡状态的磁盘使用率偏差值，参数取值范围：0-100，参数含义：判断集群是否平衡的目标参数，每一个 datanode 存储使用率和集群总存储使用率的差值都应该小于这个阀值 ，理论上，该参数设置的越小，整个集群就越平衡，但是在线上环境中，hadoop集群在进行balance时，还在并发的进行数据的写入和删除，所以有可能无法到达设定的平衡参数值，默认设置：10，推荐用5执行。
hdfs dfsadmin -report | grep “Dfs Used%”
如果想停止数据均衡在Hadoop的sbin目录下执行./stop-balancer.sh注意数据均衡开始后会影响行云的性能，这些命令都要在同一节点下执行。3）发现有不平衡现象，及时使用相关步骤进行数据重平衡。4）执行数据重平衡时会对IO有影响，需要关注并发度以及业务性能。主集群执行clone备份约50分钟后报错，通过观察备份节点目录使用率发现上涨至3.5T就一直没有再变化，通过回显的报错信息，提示备份节点客户端被中断，并给出更改interactive_timeout和wai_timeout参数的提示，我侧评估后通过将主集群计算、存储节点和备份节点的该参数从原60分钟进行调至24h，重新发起备份后任然报错，并且在数据库日志中未发现相关的报错信息。通过查询`mysql`.`greatdb_flush_schedules`的数据结合存储过程的逻辑可以判断出现整个存储过程是卡在：FLUSH SCHEDULE START_FULL_BACKUP @greatdb_flush_id WITHOUT BINLOG;但是该操作能够找到的公开资料太少，并且FLUSH SCHEDULE START_FULL_BACKUP是greatdb的内部操作，不是开源版本所具有的，需要结合内部代码分析。协调业务侧进行一次数据清理，将目录使用率从4.1T下降至2.7T，考虑到数据量有较大变化，尝试进行一次全量数据备份，此次备份正常。1）本次遇到最复杂的问题为主集群通过克隆方式初始化备集群失败，主要体现在：报错回显提示无效、日志无明显指向、GreatDB商业版与GreatSQL开源版差异较大透明性不够无法进一步分析源码（FLUSH SCHEDULE START_FULL_BACKUP为Greatdb的内部操作，不是开源版本所具有的，相关部分公开资料太少）。只能通过相关经验对可能存在的怀疑点进行多次试错排除直至解决问题，在国产数据库替换的过程中，共同为生态建设添砖加瓦，众人拾柴火焰高。2）根据原厂建议，建议对数据库版本进行升级。
Greatdb主机内存不足，重启实例过程中触发datanode重同步1. 现象
万里开源greatdb 集群主机内存剩余过小，多次flush cache也释放不出多少。数据节点和计算节点的共享内存参数设置总和超过70%，给线程预留的私有内存过少，导致随着连接数的增加，主机内存剩余出现过低的情况。结合当晚窗口对节点进行切换释放内存，理论上对业务无感知，但切换后，所有节点hang，业务全阻。最终通过对计算节点，存储节点全停全起解决。节点全停全起后，有一个datanode一直处于revover状态，后经分析为触发万里数据库内部机制导致该节点数据文件重新同步。基于本次操作，有两个疑惑怀疑与万里数据库本身机制有关：一个是做datanode切换释放内存，所有节点都hang死。第二是全停全起恢复后，有一个datanode的数据文件被集群重新同步了（这种情况一般是事物相差太大，但我们对比了事务远小于参数配置，第二种可能是binlog丢失，可能因为切换后节点hang死后数据落盘异常，但这些都只能基于运维经验判断，数据库里面的日志没有任何报错信息）。1）数据节点和计算节点的共享内存参数设置总和不超过60%。2）做相关变更之前，将用户锁定，避免业务事务增长。3）部署剩余内存监控，并将剩余内存监控阀值调低，在剩余内存小于主机总内存大小的20%时，申请主动维护窗口进行重启，避免内存耗尽后引发故障。4）当前 MGR 的选主逻辑可能存在一些问题，比如3 个节点的MGR，主节点为 A，其它节点为 B，C。A节点故障时，假设B、C节点接收到了最新的数据，B回放的数据GTID为100，C节点回放的GTID为200，MGR依然会选择B为新主，此时B会将所有的relaylog回放完成才能提供服务，会造成集群一段时间不可用。
应用侧在GreatDB中添加字段时，发现特别慢，于是强制取消了添加字段的操作。再次添加该字段时，发现报错。Error code 8537，execute cmd error: duplicate column name <column_name>
在sqlnode计算节点执行以下语句，找到每个shard的active节点。GreatDB的计算节点一般为3306端口对应的实例，数据节点一般为3307端口对应的实例。select * from information_schema.GREATDB_DATANODES;
连接到步骤2中查出的active节点的数据节点实例（3307实例），查出问题表的所有分区。查看该表是否已存在该字段。如不存在，可以忽略；如存在，执行alter table drop column 进行删除。删除问题表中所有分区的异常字段：需要将问题表中所有分片新增的这个字段删除。删除字段时，删到最后几个分区可能越来越慢。
alter table `<db_name>`.`<table_name#p#num>` drop column <column_name>;
因过程数据库本身需要进一步完善，建议通过workround规避：- 执行ddl操作前，需停止相关业务。如无法停止业务，最好低谷期不要有其他语句在操作相关表，否则锁等待时间会很长。
- ddl执行期间不要手动中断，如果执行不了等返回报错，保持GreatDB内部状态的一致性。
上云应用所有pod的CPU资源使用率持续达到90%以上。2）分析线程目前运行代码段，使用jstack命令获取当前正在Running的代码段。3）代码段提交业务侧分析代码，业务侧对代码段中的代码进行分析，是由于while循环，一直返回false引起。1）建立代码开发规范，严格要求按照规范进行业务代码开发。2）加强上线代码审核，避免代码带病上线。
上云应用模块存在2个pod无业务请求，业务侧反馈是服务未注册至zookeeper导致。1）查看应用模块四个pod运行情况,cpu、内存及jvm配置，属正常情况。该应用4个pod后台日志都正常启动，没有明显报错的日志，连接数据库初始化正常。cat catalina.out|grep -i "Server startup" -C 30
cat catalina.out|grep -i "get pool connection" -C 30
3）查看各pod tcp请求及连接情况，分析请求数，各pod分配不均衡，是由于其中二个pod无新增请求。4）经核查，zk集群只注册了二个pod，后台查看日志,无请求的两个pod确实有注册到zk。5）进一步确认pod注册zk集群情况，发现存在2个zk集群，有二个pod注册到A集群，另二个pod注册到B集群；请求到web业务模块，web-jt模块从zk信息只能发现A集群中的pod-coor-service-jt注册成功的二个pod,所以导致另二个pod无请求转发。1）加强应急演练，引入混沌工程体系，通过混沌提前发现问题。3）引入流量监控体系，当某个pod流量长时间低于某个值时进行告警或者预警。
