点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！

1.1 现象

一体机的数据库备份在节点1进行，通过iscsi协议将备份服务端的磁盘(sdb/sdc)通过备份网络挂载到一体机上作为本地磁盘，并挂载为本地文件系统以此来存放数据库备份文件，备份完成后卸载该iscsi磁盘。

1.2 处置过程

1）检查实例重启前后数据库alert日志

发现大量datafilecopy header validation failure报错，报错路径均为备份厂商iscsi设备sdb盘上的数据文件备份copy；

随后数据库LGWR进程夯死，日志显示lgwr从异常到等待持续了74s，同时数据库CKPT一直获取不到控制文件锁，报此等待事件： enq: CF – contention，然后check point stuck，然后数据库实例被pmon终止；

crs检测到实例被终止后，主动拉起实例；出现了重启。

2）检查主机message日志

发现sdb磁盘多次报错与本机断连，大量IO错误并被移除的过程，直到实例重启后才彻底将磁盘sdb移除；sdb是通过iscsi挂载到本机，做备份用。

3）检查磁盘IO

发现sdb异常前后，磁盘繁忙度为100%，后逐渐变为持续繁忙，但读写为0，磁盘异常。

4）将备份挂载剔除

实例未发现再次重启，问题解决。

1.3 新炬建议

1）严格把关监控体系的建设

此次故障提醒我们，必须严格把关监控体系的建设。对于关键数据库等待事件和异常现象，应建立及时有效的预警机制。通过实时监控数据库的性能指标和异常事件，可以及时发现潜在问题并采取相应措施。

2）备份策略的优化

这也是此次故障带来的重要教训，虽然iscsi磁盘提供了高效便捷的备份方式，但其可靠性和稳定性仍需得到充分关注。在配置备份策略时，应充分考虑磁盘的负载能力、网络带宽以及备份频率等因素，以确保备份过程的顺利进行。

3）在发现异常数据库等待事件时，人工介入处理是至关重要的

通过及时分析日志、排查问题并采取相应措施，可以有效避免故障进一步扩大和恶化。同时，建立完善的应急处理流程和预案也是提高故障处理效率的重要手段。

4）磁盘的健康状况对于数据库的稳定运行至关重要

因此，应定期对磁盘进行健康检查和维护工作。通过检查磁盘的读写速度、错误率以及繁忙度等指标，可以及时发现磁盘存在的潜在问题并采取相应的维护措施。

2.1 现象

一体机CRMPDB ORA-1653 错误分析。

2.2 处置过程

背景：3/4节点CRMPDB在5.6日 13:39:12开始出现大量ORA-1653 报错， 增加datafile后，报错消失，数据库恢复正常。

• 数据库的SMON进程的一个作用是回收合并空闲空间(整理区碎片)

  SMON负责把那些在表空间中空闲的并且互相是邻近的Extent接合成一个较大的空闲扩展区，并回收空闲空间，以减少数据库的碎片化，每5分钟检查执行一次。当有大量insert数据的对象在碎片较多，free space 较少的表空间时，扩展空间申请的量很大，并发很高，会出现ORA-1653,申请空间失败，导致session hang。

• 表空间TS_HIS 有16168GB，free space 437GB，空闲率只有2.7%，碎片数量高达290436，大量碎片<1MB,实际可用空间只有360GB左右，应用运行一个复杂的，大批量insert数据的 sql。

• 根据报错信息，LUOXIONG2.SHENJI_TMP 类对象需要申请64MB的连续空间扩展，其它生产对象也基本申请64MB的连续空间，13：37：48秒时，TS_HIS表可用free space 只有200GB只有，碎片有29万多，没有大于64MB的连续空间可用，出现ORA-1653报错，session hang。

• 申请添加2个datafile后恢复服务正常。

2.3 新炬建议

1）生产业务高峰期，避免大批量的DML操作

尤其是占用大量空间的sql，操作前需提前检查空间使用情况。

2）生产业务表空间，free space 建议保持在15%以上

3）基于表空间分组

小于64m的所有连续区加起来的总空间除以该表空间所有连续区的总空间，超过85%需特别关注。

3.1 现象

开启drm导致数据库后端有ora-01558故障。

3.2 处置过程

业务反馈出现ORA-01558故障，然后通过重建undo解决了。

分析原因发现是设置_gc_undo_affinity=FALSE，这样会更快的使用xid，导致undo xid耗尽引发故障。Oracle的开发认为这不是一个bug，所以不会有补丁。

解放方案：

• 1）_gc_undo_affinity=true，开启drm会带来其他性能问题，不建议。

• 2）针对undo xid使用情况进行监控，当xid使用了90%，重建undo。

3.3 新炬建议

1）合理配置 _gc_undo_affinity 参数

在数据库配置中，参数 _gc_undo_affinity=FALSE 会加速使用XID，导致UNDO XID被耗尽，引发ORA-01558故障。为避免此问题，建议将该参数设置为 TRUE。然而，开启DRM会引入其他性能问题，因此需要在性能与稳定性之间权衡，谨慎使用。

2）监控 XID 使用情况

对于使用UNDO XID的情况，需要进行严格监控。当UNDO XID使用率达到90%时，建议主动进行UNDO重建，以防止XID耗尽导致的故障发生。定期检查和优化UNDO空间的使用情况，可以有效减少潜在的风险。

4.1 现象

磐维3.0以下的版本账号未作连接数限制。

磐维3.0的版本账号连接数限制默认为100个【若为低版本升级至3.0，升级前创建的账号也无账号连接数限制】。

4.2 处置过程

执行"alter user xxx connection limit -1;"命令，取消账号连接数上限。

4.3 新炬建议

1）了解数据库版本特性

国产数据库在不同版本中可能会增加安全限制或优化功能，升级或上线前必须深入了解相关版本特性。

2）全面核查配置变更

在版本升级或系统上线时，需要对账号配置、资源限制等关键参数进行全面核查和调整，以避免影响正常业务运行。

5.1 现象

磐维数据库字符集是gbk，创建utf8的database报错。

5.2 处置过程

数据库初始化时，没有指定参数lc-collate=C、lc-ctype=C，那么数据库这两个参数就会使用主机环境的参数，而不是使用默认的C（opengauss默认的是C）。这样会导致创建的database，不能使用不同的字符集。

通过修改数据字典解决：

update pg_database set datcollate='C',datctype='C' ;

5.3 新炬建议

1）数据库初始化配置至关重要

在数据库初始化时，必须明确设置关键参数（如 lc-collate 和 lc-ctype），避免使用主机环境默认值。这种疏忽可能导致字符集和排序规则不兼容的问题。

2）深入了解产品定制化特性

磐维数据库在 OpenGauss 基础上做了大量修改，使用时必须充分理解这些改动，特别是与字符集相关的实现差异。严格按照官方文档进行配置和操作是避免问题的基础。

3）字符集与排序规则需与业务需求匹配

数据库字符集和排序规则的选择需要结合实际业务需求。统一设置和测试字符集的兼容性可以降低后续操作中的风险。

6.1 现象

本地上云应用日志接入，出现一个flink任务数据入库延迟现象。前端查询日志显示数据延迟大于10小时。

6.2 处置过程

1）分析flink任务

对比处理其他数据的flink业务，发现均无异常排除因flink本身导致的问题。

2）分析数据

对比7-9个月flink入库数据，未发现存在较大数据导致的入库延迟，但是随着需求增加，7-9月的数据量呈直行上升情况。

3）分析延迟任务架构

任务属于消费kafka数据入库es，分析上下游情况发现延迟全部集中在消费kafka这步，消费kafka由flink任务中的TaskManager决定，TaskManager(topic数=taskmanager数)*Slots数=Cpu核数  查配置当前值符合最佳理论配置。

4）分析TaskManager

发现TaskManage中存在大量的线程等待日志，当前配置符合最佳理论配置，但是通过flink日志内容以及前台查询数据延迟、kafka消息堆积分析，线程等待得出该配置已无法满足当前并发量。

6.3 新炬建议

1）灵活调整配置应对业务增长

随着数据量和业务需求的增长，静态的任务配置难以满足实时性要求。建议定期评估业务增长趋势，预留至少30%的资源冗余以应对突发情况，并灵活调整Flink任务的配置。

2）加强实时监控和预警机制

建立对Flink任务、Kafka消费、数据流状态的实时监控和预警机制，确保问题能够第一时间被发现，并及时采取措施缓解延迟现象。

3）优化TaskManager线程模型

任务管理线程模型需随业务并发量调整。建议动态扩展TaskManager的线程数、Task Slots等参数，以适配数据流量的变化，防止线程等待和资源瓶颈。

7.1 现象

某中心地市反馈缴费、商品订购失败，重启后容器间ping丢包，业务切换至另一个中心后恢复正常。减少pod数量后，ping丢包现象消失，微服务容器重启后业务回切至开发区恢复正常。

7.2 处置过程

检查宿主机通信正常，非全部pod之间通信异常，部分业务pod间通信有明显丢包，跨主机ping pod ip，有明显丢包；

排查主机之间网络，ping包无丢包；查看监控页面，主机负载均在正常范围内；

查看calico配置文件，主机网卡配置正常；

收集主机messages日志、cni.log日志并发送二线分析；

查看微服务部署主机负载、容器负载均正常；查看主机、容器cpu、内存使用率均正常；

省侧主机工程师确认虚机底层未超分，问题宿主机kubectl top查询结果均显示正常；

在多台微服务部署主机上进行主机、容器间抓icmp协议包分析，部分主机承载的pod通信有明显丢包；

通过从集群所有主机分别ping k8s集群自有coredns、monitor-node-exporter服务podip以及业务容器podip，发现部分主机存在ping丢包现象；经过多次测试，发现这些存在ping pod丢包的主机均为业务微服务部署主机；30台微服务部署主机中约8台存在丢包现象；

将一台问题主机上calico容器进行重启验证是否calico网络影响，重启后pod间超时现象未消失；

将其中一台异常主机设置不可调度，将该主机上的业务pod逐个驱逐，在驱逐5个后，ping主机上还存在的podip，丢包现象消失；

将另一台异常主机设置不可调度，一次性驱逐5个业务pod后，ping主机上还存在的podip，丢包现象消失。

7.3 新炬建议

1）单节点资源限制需合理规划

单台主机上运行的Pod数量应限制在合理范围内（如20个以内），特别是在业务高峰期，以避免因资源争用导致的容器间通信问题。

2）加强网络性能监控和预警

集群中应建立网络性能的实时监控与预警机制，包括跨容器、跨节点的通信延迟和丢包率，便于快速定位和解决网络问题。

3）容器调度策略需优化

Kubernetes调度策略应考虑主机资源负载均衡，避免部分主机因Pod分布不均而承受过高压力，从而引发通信问题或性能瓶颈。

8.1 现象

某OB数据库全备失败，归档延迟较高，归档量大。

8.2 处置过程

该集群的clog比较大，导致初始搭建备集群时，延迟追不上，备集群搭建：调整rebuild_replica_data_lag_threshold参数，及时进行副本重建才勉强搭建起来备集群。

开启主库归档，会把日志盘io打满，导致归档延迟增大。无法进行全备。

8.3 新炬建议

1）业务分区与日志膨胀

经过深入分析，我们发现业务分区数较多且存在频繁的update操作，但并未指定分区键。这一设计缺陷导致了CLOG的急剧膨胀。

由于CLOG中包含了redo log、prepare log、commit log和clear log等多种类型的日志，当某个分区被更新时，该分区会生成所有类型的日志。而未被更新的分区虽然缺少redo log，但其他类型的日志仍然会生成。

此外，OB数据库默认采用了`binlog_row_image=FULL`的模式，以确保OMS（Online Metadata Store）的正常工作。这一配置进一步加剧了CLOG的膨胀问题，因为FULL模式会记录所有行的变更信息，无论这些变更是否对最终结果有影响。

2）日志量控制与性能优化

针对CLOG膨胀的问题，我们进行了业务调整。通过优化分区设计和指定合理的分区键，我们减少了不必要的日志生成。

同时，我们评估了`binlog_row_image`的配置，并考虑在不影响业务逻辑的前提下，调整为更简洁的日志记录模式，如`MINIMAL`或`COMPACT`，以减少日志量。这些调整措施显著降低了CLOG的生成速度，从每小时近300G的高位下降至10G左右，有效缓解了数据库集群的性能压力。

9.1 现象

网络瞬断导致两套集群rs处于无主状态，一套通过调整_ob_max_thread_num参数恢复正常，另一套当天晚上21:00重启主zone45节点完成恢复。

9.2 处置过程

收到告警，observer进程不存在。赶紧检查集群，发现告警集群的三台server处于inactive的状态。业务的primary_zone是zone3，sys租户的primary_zone在zone1，inactive的是zone1的两台机器。zone2的一台机器，zone1是一个机房，zone2和zone3在另外的机房，万幸的是业务反馈告警时候断连了一批业务，重新拉起来就好了。

检查当时的网络有丢包，怀疑是网络问题触发的诱因。登录主机检查发现inactive的机器上observer进程还在，通过2881连接inactive的节点也可以登录。

分别对各个rs节点进行了队列积压的检查，并未发现异常。

检查各rs节点的rootservice有没有切主上任日志，发现有4019的WARN日志。

通过2881分别连接rs节点的sys租户，查询__all_virtual_clog_stat  的1099511627777系统表信息报错timout。

归档也卡在了问题时间点，位点不再推进，这时候还发现一个现象，在__all_server视图中查询到的rs主是zone1的rs节点，但是从__all_virtual_clog_stat视图查到的leader是zone2的rs节点。

执行切主命令，报错"rootserver is not the master"。

9.3 新炬建议

1）网络波动触发主从切换与observer bug

从故障现象来看，网络波动导致了rs的主从切换，从zone1切到了zone2。然而，这一过程中触发了observer的bug，导致线程满了。网络恢复后，zone2的rs没有正常卸任，造成了rs无主的情况。这一发现揭示了网络波动与集群内部状态管理之间的复杂相互作用，以及observer在处理这种复杂情况时的潜在缺陷。

2）归档进程与RS状态同步问题

归档进程在完成后需要向RS汇报，以推进备份时间。然而，在此次故障中，由于RS没有上任成功，归档进程无法推进备份时间，导致显示卡住。这一发现揭示了集群状态同步与备份进程之间的依赖关系，以及状态不一致对备份进程的影响。

10.1 现象

执行SQL报错4013问题。

10.2 处置过程

根据sql 文本确认是sql中的一条update语句执行抛出的内存不足的报错。

根据报错的sql文本去sql_audit 视图中捞取对应的trace_id ，过滤日志观察具体是哪个模块内存写满

日志中打印有限，因此在sql中增加了/*+LOG_LEVEL(debug)*/ hint，增加日志的输出

根据更多的日志，可以看到SQL执行时，merge sort过程 ob_dtl_interm_result_manager 中间结果数据落盘过大，造成租户内存不足。

10.3 新炬建议

1）避免产生过多的中间结果数据

在处理此次故障的过程中，我们发现SQL执行时merge sort过程中的ob_dtl_interm_result_manager中间结果数据落盘过大，这是导致租户内存不足的主要原因。

因此，我们总结出的第一条经验教训是，在设计SQL语句和数据处理逻辑时，应尽量避免产生过多的中间结果数据。

这可以通过优化SQL查询逻辑、减少不必要的数据连接和排序操作等方式来实现。同时，对于确实需要处理大量数据的场景，可以考虑使用分批处理或分段执行的策略，以减轻单次SQL执行时的内存压力。

2）优先考虑拆分复杂的SQL语句

另外，我们还发现，当SQL语句过于复杂或处理的数据量过大时，容易导致内存不足的问题。

因此，我们总结出的第二条经验教训是，在遇到内存不足的问题时，可以优先考虑拆分复杂的SQL语句。

通过将一个大而复杂的SQL语句拆分成多个小而简单的语句来执行，可以显著减少单次SQL执行时的内存占用。这种拆分策略不仅有助于解决内存不足的问题，还可以提高SQL语句的可读性和可维护性。

3）加强数据库的日志监控与预警机制

此次故障处理过程中，我们深刻体会到了日志监控与预警机制的重要性。通过增加日志级别并仔细分析日志信息，我们才能够快速定位到问题发生的具体原因。

因此，我们总结出的第三条经验教训是，应加强数据库的日志监控与预警机制。

通过配置合理的日志级别和监控策略，可以及时发现并预警潜在的内存不足等问题。同时，还应建立完善的日志分析流程和方法论，以便在问题发生时能够迅速准确地找到问题根源并采取相应的解决措施。

新炬运维避坑指南连载合集链接：

https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzUxNTYzMjA5Mg==&action=getalbum&album_id=2846038717288693763#wechat_redirect

END