点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！预安装检查无法通过，由于su安装用户omm时有错误提示，切用户时，不能有信息输出。1）执行过程中需要手动写入的：是否需要root互信、是否需要数据库安装用户互信、输入数据库用户的密码。输入yes来使gs_preinstall程序自动配置root用户互信和omn用户互信。2）如果gs_preinstall执行时报互信问题，说明互信配置有问题，须手动配置互信。CMDB故障解决指南）中互信相关错误处置。Failed to obtain network card RX value. Error: Cannot get device ring settings: Operation not supported
解决方法：修改gs_checkos文件第98行，去除98行把A11删除，重新运行gs_preinstall程序。Unable to import module: libpython3.6m.so.1.0: cannot open shared object file: No such file or directory.
解决方法：CentOS7.6报错,Pthon3.6库文件缺失，可查找libpython3.6m.so.1.0路径，链接到/usr/lib64下。数据库国产化，一路各种小怪兽，关关难过关关过。加强生态建设与技术储备。
业务侧反馈某业务侧访问redis集群服务器异常，且应用程序抛出内存日常错误。1）根绝业务侧提供的报错第一时间排查了redis主节点日志，发现无明显报错信息。2）进一步排查redis服务器的性能指标，通过redis-cli INFO 命令查看到“Memory指标”信息。3）可明显看到redis内存指标异常。其中used_memory_human 指标几乎接近初始配置的内存大小限制，且used_memory_peak_human 内存使用峰值也接近redis的最大可使用内存，说明当前redis服务器的可使用内存不够用（核实到当前配置的maxmemory较小），需要增加redis的最大使用内存。4）经过上面的分析后，将redis集群节点的maxmemory配置为当前操作系统可使用内存的70%（config set maxmemory 6442450944)，注意节点配置。1）初始配置redis集群时，分配的redis最大内存使用量不宜过小，建议配置为系统可用内存的50%-70%。2）redis监控告警可添加used_memory_human|used_memory_peak_human指标。
1）检查容器应用服务资源使用情况正常，业务反馈缓慢时，pod已全部重建，但查询仍然缓慢。2）数据库资源使用情况核查、数据库连接请求情况核查，均无异常。4）分析redis日志，发现Key频繁改变，请求频繁，RDB频繁。5）业务当前使用过滤器读redis，过滤所有访问请求，读取次数非常大，为减少对redis请求，临时把规则写死在代码，不请求redis.但是下次规则改变，需通过版本更新。经业务修改后业务已恢复。1）对于业务繁忙的且开启redis开启了rdb持久化的系统,调大redis save参数。2）上线前充分作业性能压力测试。
1）查看数据库会话， 发现会话数正常，也没有繁忙的会话，数据库主机负载正常；3）在宿主机上连接数据库测试， 测试正常，没有连不上的情况；4）查看数据库的dbproxy日志，未发现异常日志；5）再次回到POD，在POD内连接该数据库，确实出现有时连不上的情况，但是连接其他数据库，一切正常；怀疑可能还是数据库的问题；7）重启POD，再次测试，连不上的情况依然存在，并且不同的NODE节点都有这种情况；8）经过反复测试，验证，推断可能与网络冲突有关，随即检查数据库服务器网络情况，发现该主机开启了2个网络管理服务，一个是NetWorkManager, 另一个network，关掉其中一个(network)后，再次让业务应用部署测试，此类情况没有再次发生。1）在高版本的操作系统，或者开源操作系统中，可能开启了多个管理插件，如防火墙的filter 有iptables.service，firewalld，网络管理的NetWorkManager, network等，最好不要同时启用；2）正式上线前最好能做全面的压力测试，确保数据库及其相关服务器无问题。
2）查看数据库日志，并没有找到相关的delete语句；4）部署WalMiner工具，对wal日志进行了解析；6）WalMiner工具部署完成后，指定时间时间段，指定表解析wal日志；1）对业务的用户权限应该进行更加细粒度的管理，规避业务出现的一些误操作。2）在重要的系统安装WalMiner工具，减少恢复的时间。重要的事情说三遍。
Openssh后(9.1或9.3)导致sshd等服务失败
升级完成OPENSSH后，出现相关问题，表现如下：1）升级openssh后ssh免密失效，跳转出错，在/etc/ssh/sshd_config添加一些旧版的算法，并重启sshd服务，免密跳转恢复正常HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
在/etc/ssh/sshd_config添加一些旧版的算法，并重启sshd服务，免密跳转恢复正常。HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
3）升级openssh后导致sshd服务状态异常，为auto-restart或activating(start)- 如果遇到service sshd restart无法成功，解决办法为/usr/lib/systemd/system/sshd.service 这个文件删掉或拷贝出来，服务可能有冲突。
- openssh升级成功无异常，只是sshd服务状态异常，可以回退到低版本(如已升级到9.3p1，可回退为9.2p1)。
- 一般是key文件权限报错，将3个key文件权限修改为700
chmod 700 /etc/ssh/ssh_host_rsa_key
chmod 700 /etc/ssh/ssh_host_ecdsa_key
chmod 700 /etc/ssh/ssh_host_ed25519_key
- sshd -t 如果出现报错，Missing privilege separation directory: var/empty/sshd，原因是会寻找“localtime”的符号链接（软链接），可能是缺少权限分离目录：/var/empty/sshd，操作步骤如下:
mkdir -p /var/empty/sshd/etc
cd /var/empty/sshd/etc/
ln -s etc/localtime localtime
1）升级前，一定要对方案进行仔细测试并进行评审，做好回退方案；2）升级中，认真按照方案操作，不能疏忽导致漏掉步骤；3）升级后，仔细检查服务状态，确认升级后服务没影响。因为新版本的OpenSSH采用了更加严格的安全验证方式，例如默认禁用了DSA密钥验证、禁止使用具有弱算法的密钥等。这些更严格的安全措施可能会影响到原有的互信设置和用户权限，导致某些程序或功能失效，所以我们要允许使用旧版的算法或者关闭某些安全特性，但是这种做法可能会降低系统的安全性，需要根据实际情况谨慎考虑，具体情况还是要具体分析。mysql sql性能全面下降，业务访问超时无响应。1）优先检查主机内存、cpu、io；发现故障时间io写入降为零。2）检查sql，发现业务那个时段业务在跑批量更新数据。3）观察实时io发现，数据频繁的读写一块盘，且该块盘的最大iO才3M-5M之间；后通过主机检查发现该业务进行了多次少量扩容，底层挂了12块盘，从最开始的50G扩容到400G，最大的一块盘150G。结论：业务sql性能本身不佳、io性能过低、业务跑批导致数据库性能整体下降。多次扩容的虚拟机需要进行单盘io评估。
zookeeper作为业务的注册中心，业务程序启动后会在zookeeper中进行注册临时节点，业务程序宕机后临时节点未进行自动删除。导致通过调用zookeeper访问注册中心的程序会将请求分发到已宕机的程序，对业务造成影响。- 业务反馈这类问题后，第一时间查看zookeeper日志，查看是否有异常报错。结果未发现明显错误。
- 在搜索引擎针对故障现象进行搜索，寻找他人的解决方案。结果未发现完全相同的故障类型。
- 与业务方进行沟通，是否存在业务程序配置不合理，例如过期时间设置太长，zookeeper未能第一时间删除临时节点，导致业务被分发到故障节点，进而造成了业务影响。结果未发现业务侧有明显配置错误。
- 因为目前业务系统使用的zookeeper是cdh版本的zookeeper，并且版本为较早期的3.4.5，进而开始怀疑是否存在bug。通过在网上搜索对应版本的bug信息，以及与其他省份采用相同版本zookeeper的移动项目，最终确认这是一个版本bug。
- 前期联系业务方对新版本（3.6.4）进行兼容测试，最后通过升级版本解决故障。升级后，此故障未复现。
1）bug一般具有以下几个特性：复现难度高，频率低，日志记录不完全或者不记录，网上资料较少。2）当我们遇到中间件故障的时候，会默认觉得是配置文件不够优化，或者部署出现不合理等。更进一步会排查业务程序是否配置合理，但不会去关注中间件自身可能出现的bug。又由于bug具有第1点中的特性，所以排查起来非常困难。这里建议如果遇到非常棘手的问题，可以看看相关中间件的bug信息。
1）GolenDB paper集群业务反应存在一条慢sql，经分析需要创建索引优化，在和业务人员沟通后决定晚上9点进行索引创建。3）经查看后发现是创建索引导致锁表，随即马上取消创建索引。2）DDL语句执行需要选择窗口在业务停止后执行，避免锁表。
OceanBase核心库租户的OBserver主机连续几天出现CPU冲高到100%的情况。推测是SQL执行导致CPU打高。1）通过OCP平台的SQL诊断功能，发现主机CPU冲高时都跑了同一条SQL，该SQL响应时间超长，且占用CPU时间高。2）查看其执行计划，发现该SQL当时的执行计划走的索引和正常时候不一样。正常时走的索引应该是SERVICE_NUMBER字段，但是当时走的是STATUS字段，走STATUS字段时的效率很低。3）查询SERVICE_NUMBER字段是VARCHAR2类型，在环境测试发现，在该SQL的WHERE条件中的SERVICE_NUMBER的传参不带单引号，和带单引号的执行计划不同。不带单引号的执行效率低下。4）通过查询OB官网得知建表时是数值类型，在查询时传入的参数值为字符，此时执行计划无影响；如建表时是字符类型，在查询时传入的参数值为数字，此时会导致无法用到正确的索引。因此要避免后者类型的隐式转换。1）让业务核实执行的SQL的传参中，SERVICE_NUMBER字段是否传入了非字符串类型以外的值。传参必须与字段类型一样，为字符串类型的值。2）在OCP平台上将该SQL绑定了outline，后续的执行都走了对的索引，执行速度快。1）加强业务SQL开发培训，业务必须遵循割接上线前开会讨论的规定，比如避免字段是字符类型而传参为非字符类型的隐式转换。
