点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！
时慢时快Redis集群：9台物理主机一主两从配置，共405个节点；通过spark访问redis取全省数据做计算，数据量都在千万级以上。3）Redis node内存使用2G左右，没有明显波动，不存在内存问题；5）Redis慢日志记录都是keys value*操作。
2）节点的cpu有上浮，总使用都在50%以内，但是基本都是sys-cpu偏高。
1）直接通过业务执行的del key操作定位耗时；3）通过ping发现慢的三台主机延迟较高，通过定位发现都慢在主机分配端口上。
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes =5
net.ipv4.ip_local_port_range = 10240 65535
修改生效后，sys-cpu使用瞬间降为几，且ping延迟都在零点几毫秒；业务访问再未出现慢的情况。随着开源软件，开源数据库的引入，在提升效率降低成本的同时，也增加了系统运行稳定性的风险，需要引入最佳实践落地，而最佳实践往往需要通过规模化，通过无数的踩坑才能形成避坑指南，我们可以充分利用他山之玉。
SqlServer新增ogg表到oracle数据传输失败。1）多次检查并重建中间进程依旧无法传输数据到目标端。2）检查目标端中间进程日志发现有两端字段不一致的警告，判断因数据原因导致无法使用中间进程导入数据到目标端。3）最终注销目标端中间进程参数“BULKLOAD”（批量导入参数），重启源端中间进程，数据成功导入至目标端。1）OGG问题需从多点切入：配置、数据、表结构都需要检查。2）sqlserver表迁移时不使用BULKLOAD参数。
1）查看延迟的从库，并没有发现有大事务正在执行，这里排除大事务导致的复制延迟；2）没有发现metadata lock排除对表DDL导致的复制延迟；3）查看线程具体等待情况，有等待提交的 、有等待MTS顺序提交，等待提交锁要主要是由一条flush table with read lock导致的；4）通过确认语句是由备份发起的，kill掉flush read lock的会话，复制恢复正常。1）避免在从库执行 flush table with read lock语句。2）slave_preserve_commit_order=0 关闭从库 binlog 的顺序提交，避免这个死锁的出现。3）从库监控flush table with read lock语句。
1. 现象
Mysql主从同步异常。
1）主从同步异常，从库执行inster语句失败，使用mysqlbinlog命令查询报错时间点的sql语句，根据此sql删除从库重复数据。2）查看从库bin-log日志发现故障前从库有做inster操作。3）查看从库read_only配置，发现从库未开启read_only。5）开启read_only,向配置文件中加入read_only=1。1）应用用户不允许有super权限，加强权限管控。2）增加从库read_only参数检查。
某库1节点JDBC连接失败，登录数据库主机检查数据库状态正常，但是操作系统输入命令响应时间较长，用TOP命令检查发现主机上存在10W+的僵尸进程，并且还在持续增长。接到告警某库1节点JDBC连接失败，登录数据库主机检查数据库状态正常，但是操作系统输入命令响应时间较长，用TOP命令检查发现主机上存在10W+的僵尸进程，并且还在持续增长，该部分僵尸进程都是某监控厂商的监控agent程序发起的。在尝试杀掉僵尸进程无效后，按主机工程师建议对数据库1节点主机进行重启，16:10分数据库主机重启后僵尸进程全部释放，主机和数据库恢复正常。监控厂商工程师核查反馈可能是在操作系统出现问题时影响到监控进程，导致不停的产生僵尸进程，监控进程无论执行结果成功或失败每5分钟会执行一次，针对可能会带来产生大量僵尸进程的情况，已经发布oc-agent来替换subagent。再监控本身也是应用程序，也有出现BUG的可能，要做好自身监控以及沙盒，出现问题异常要有自杀机制，避免因为监控影响业务，相关主机部署agent进程之前，需对agent进程进行压力测试，确保agent不会占用过多的主机资源从而影响到数据库软件的运行。
某场地应用侧反馈计费采集任务处理失败，怀疑可能是数据库出现异常。应用侧反馈计费采集任务处理失败，怀疑可能是数据库出现异常，DBA登录数据库检查：发现有大量gc类型的等待事件,最终通过阻塞链定位到都在等待LGWR写日志，最终的阻塞源是LGWR进程。随后查看log file parallel write 等待事件的平均响应时长发现在23:00由1ms变成了19ms左右，说明存储IO性能出现问题,进一步排查是rman增量备份任务在23:00挂起，怀疑可能和rman备份有关系,于是立即手动杀掉rman进程后，数据库恢复正常。1）RMAN备份时候读取数据文件会消耗占用大量的IO资源，数据库在首次配置RMAN备份任务前，需提前对数据库的存储IO性能进行评估，明确RMAN备份时开启多少通道及是否需要做限速。2）针对log file sync、db file parallel read响应时间进行监控。
udev绑定的别名消失，导致磁盘被踢后，DG要进行rebalance。DG是normal的，磁盘被踢出后，没用空间再进行rebalance，通过resize 数据文件腾挪空间保证rebalance完成，再将被踢出的磁盘加入到DG中，同时申请扩容存储，在问题未解决前保证即使磁盘被踢后也能正常rebalance完。核查主机日志、存储、交换机都未见报错，通过部署脚本发现，掉盘时间点，只是udev绑定的别名磁盘在OS上消失了，multipath聚合绑定的dm-*和/dev.mapper/下的盘正常。目前还未找到具体原因，从现象看multipath聚合磁盘没有问题，udev生成的别名磁盘出现问题，怀疑可能udev存在兼容性bug，还需要进一步确认。之前很多系统都是通过udev绑定别名磁盘后给数据库使用，一直沿用的此模式。后续可根据环境调整，如对于multipath多路径软件通过wwid绑定的磁盘，可直接使用，不必再用udev生成别名磁盘；增加asm磁盘数量监控。
两套3节点的国产磐维库，在配合修改主机参数disk cache policy时，有一台机器重启后，集群无法拉起。手动尝试各种方式都无法拉起，日志也无任何报错，一直显示在starting。期初以为是调整了参数disk cache policy导致，经与原厂的人沟通，集群安装的时候会自动配置一个om_monitor的crontab任务，主要负责监控cm_agent进程，由操作系统定期拉起。这个crontab之前被手动注释掉了，才导致集群无法启动。把crontab任务放开后，cmserver正常启动。对于不熟悉的配置，不轻易做调整。过于相信经验判读，没想到crontab也会影响到数据库启动。
3）我侧介入分析，发现某pod的cpu比其它15个pod cpu高，然后做线程快照，未发现阻塞进程。 4）查询该pod的并发访问量比其它pod要高一倍多，怀疑k8s负载均衡不均衡引发。5）ccse平台侧进一步查看k8s日志未发现在报错日志。6）对该pod删除，并重建，过一会儿，cpu又上来 。7）与业务侧沟通整个访问逻辑，发现业务注册zk时，并非用的是k8s自带的，用的是Dubbo的负载均衡，并且用的是默认均衡策略(加权随机策略),这种默认策略存在雪崩风险，建议修改为加权轮询模式 8）临时方案，由于重保期间，删除有问题的pod,再水平伸缩pod至20个。1）使用dubbo负载均衡，建议采用加权轮询模式。2）pod不均衡访问时，业务有可能并非使用k8s自带的负载均衡。3）后续增加对每个pod cpu基线，以及是否均衡的告警。4）业务上线前，应尽可能熟悉整个业务流程，每个组件的默认策略都有可能存在风险，需经优化测试后上线。某运营商账务中心业务调用出现超时，持续一段时间后又自动恢复。1）通过pinpoint观察，发现整个调用链中某个服务调用缓慢，并有超时现象；2）通过查看该服务的调用堆栈，发现是调用ctgcache超时，并在故障时段频发；3）查看相关的ctgcache 接入机以及后端redis主从的日志，发现接入机日志有大量报错；4）查询该实例的主机性能情况，cpu及内存，io、网络都很正常；5）手工使用redis-cli去连接是正常的，读写均正常，猜疑不一定是接入机的问题。6）反编译集团组件ctgcache 接入机服务端相关的class文件，发现根据提示的错误信息，定位到的代码段是get到redis key-value后返回给客户端时报错，所以判断应该是应用程序端有问题。7）应用端定位发现是自身的tcp socket有异常。故障出现后，通过pingpoint分析的指向是正确的，但也许还只是表面现象， 更深层的原因，需要我们去挖掘。故障线索的表面指向不一定正确，通过读取相关的源代码，了解错误提示信息背后的逻辑，更能够帮助我们了解故障的真实情况。当然部署pingpoint等工具或者APM工具能快速协助我们定位问题。同时也为后续的智能运维提供基础数据支撑。
