点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！
某主机中间件tomcat连接数告警处理，检查分析tomcat访问日志等，后续重启XX掌柜nginx及主机tomcat逐步恢复。2）重启23主机tomcat后过一段时间连接数涨起来；3）切换array负载至22主机，后过一段时间22主机tomcat连接数涨起来；4）同时重启大掌柜nginx及22、23主机tomcat逐步恢复。系统页面未设置防止重复点击功能，积压后重启后端服务，用户不断进行大量点击都会产生大量连接进而导致重启后积压不断重复此操作无法恢复业务，经验总结前后端同时重启后恢复。
KAFKA topic分区不足致新增proxy异常./bin/kafka-topics.sh --zookeeper IP:2181 --alter --partitions {proxy数量+N} --topic dcp_agent_command。需扩展proxy注册到zk对应的分区，kafka中会创建一个名为dcp_agent_command的topic用于下发监控指定给snc agent，默认创建6个分区(partitions)，当proxy数量超过6个时，应当新增分区数量，避免消息通道阻塞。需要根据业务提前做好topic分区。
1）mysql不断crash重启,日志提示访问表的page错误:Trying to access page number 1212435777 in space 27, space
name xxxxxxxxx, which is outside the tablespace bounds.
Byte offset 0, len 16384, i/o type read;
2）判断故障原因为os层文件损坏,通过mos进一步确认为文件损坏；3）通过设置innodb_force_recovery尝试恢复,从value 1--6仍然无法恢复,和业务沟通先drop故障表,恢复其他业务；4）使用备份+binlog异机恢复故障表,业务确认数据后导出并导入生产库。2）必须做定期恢复演练。
2）登录数据库查看从库的SLAVE日志(SHOW SLAVE STATUS),发现当前延迟（Seconds_Behind_Master:3500）较大。3） SHOW PROCESSLIST未发现事务锁，且当前活跃连接数大概10几个（4核的CPU），某几条delete、update执行时间过长。4）sar -d 1 3 查看到当前数据库服务器的磁盘IO写入很高。- --数据库延时大时，磁盘I/O写入较繁忙，可能的原因是innodb存储引擎引擎日志频繁的刷盘，fsync操作耗时导致。需要调整一下mysql数据库中innodb存储引擎日志的落盘机制，由于当前设置的 innodb_flush_log_at_trx_commit 为默认1，默认设置安全性最高但性能最差，因为每次事务都fsync操作。所以将 innodb_flush_log_at_trx_commit 设置为2，同时设置sync_binlog=0。
- --其次根据定位的耗资源的SQL发现有些SQL未命中索引，走的全表扫描。提取SQL告知业务侧进行优化。
通过上面操作优化redo和二进制日志的落盘策略后，延时慢慢的降下来了。7）开启read_only,向配置文件中加入read_only=1。
3）对参数进行调整innodb_flush_log_at_trx_commit=2 sync_binlog=0
1）代码未经适配直接使用，ob确认为bug，代码中insert all使用受限，写入数据行数过多时报错。1）数据库国产化过程中，务必加强场景测试，严禁代码未经适配直接上线生产。2）由OB原厂开发对应的补丁。
检查归档状态是中断状态，保存下日志，先恢复下，关闭归档重新开启，检查rs日志归档状态变更时间点，去库里查询rs_event历史视图有分区切主操作，该操作为正常rebalance操作，检查该时间点observer日志有找不到clog的报错，检查该日志存在，工单协助分析为日志断流导致，与backup_log_archive_option参数设置有关系，属于正常的偶发现象。该参数设置备份优先，不会丢失日志，但是可能会影响集群性能，设置集群可用优先可能会存在日志处理方法：与备份机制有关系，保证集群的高可用的情况下可能会做出备份断流的牺牲，是一种极少遇到的情况。alter system noarchivelog；alter system archivelog；
oracle 19.7 pdb row cache lock导致数据库hung。1）通过v$session_wait查找cache id。2）通过v$rowcache结合cache id查找row cache原因。3）DC_OBJECTS,DC_OBJECT_GRANT。4）定位到问题语句为普通的insert,update语句。5）AWR报告分析与ORACLE原厂确认为bug 33121934。2）出现问题时结合版本信息与bug编号进行补丁查询。3）数据库打补丁patch 33121934。
基线服务redis保存周期默认一百天，导致redis所在机器内存过大、持久化后导致磁盘打满，无法写入。2）基线服务redis保存周期由100天改为1天。修改application.baseline.item-history-data-redis-expire-day=100 为1。
在生产环境中部署squid正向代理，配置了acl localnet src ip地址，然后对ip地址进行访问限制，http_access allow ip，但是除了限制的地址之外的ip地址也可以进行squid代理访问。首先对整个的squid配置文件进行排查发现没有配置问题；然后对各个参数的控制权限allow、deny等进行位置排序挪移，发现问题依旧未能解决；最后通过对比域名白名单的控制权限，先对白名单之外的域名进行deny，再实现allow。http_access deny !whitelist http_access allow whitelist ，这样就可以实现除了白名单内的域名可以访问，别的域名均拒绝。然后配置http_access deny !localnet http_access allow localnet ，而且http_access deny !localnet 配置要放到acl控制的下边才能生效。这样配置就可以实现除了限定ip可以访问代理地址，其余均拒绝访问。1）部署squid代理地址的时候一定要多检查一下配置文件，多思考配置各个参数的含义，多进行测试，以防出现问题。2）http_access deny !localnet，位置要放到acl控制的下面才能生效。
由于出现问题的主机在稍早前出现过硬盘资源不够的问题，通过向资源池管理工程师提交资源扩容工单，多分配500g的磁盘。在得到分配后的硬盘时，通过使用lvextend -l +100%FREE dev/vg/root命令和xfs_growfs /dev/mapper/vg-root 命令将未使用空间在线扩展并同步文件系统。挂载点选则为ampdcp目录下。挂载后使用df -h查看主机磁盘挂载成功，但是通过上述命令挂载的磁盘，在/etc/fstab的配置文件中并没有对文件格式xfs配置，所以导致当主机重启后失败。最后通过修改错误的配置后重启成功。在配置磁盘挂载的时候，与以前正确的配置文件做一下对比保证磁盘挂载成功。
