点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！
- oceanbase sql执行计划变更，导致cpu使用率打满
mysql5.7升级版本后版本回退导致数据文件损坏
在部署antdb的高可用组件etcd和patroni，安装完成etcd和patroni之后，会使用pip/pip3 list来检查所安装python安装包，在执行pip3 list的时候出现no moudle pip._internal问题。由于在服务器需要纳入4A系统，进行安全基线扫描，会暴露出很多的安全隐患，其中有一条安全隐患就是umask的设置umask=027。在没有修改umask的值创建一个文件是会有一个默认权限的，那么这个权限是怎么来的呢？这就是umask干的事情。umask用于设置用户创建文件或者目录的默认权限，umask设置的是权限的叫“补码”，而我们常用chmod设置的是文件权限。在进行安全基线的时候可以放弃安全基线的条目。保证文件和目录的权限不发生变化。在安装或配置软件过程中临时调整 umask 设置，安装完成后再恢复原来的严格设置。为特定目录或文件手动设置适当的权限，以满足应用运行的需求而不降低安全性。将这些变更记录在安全政策中，并进行定期审核，确保不会无意中引入安全隐患。确保系统配置始终符合安全策略的要求，同时快速发现并解决新的安全隐患。
oceanbase sql执行计划变更，导致cpu使用率打满
业务侧使用mybatis框架生成的SQL在每次有ddl操作后，sql的别名会改变，导致执行计划走选择性较差的索引，导致主机cpu打满。1）登录数据库后，通过__all_virtual_processlist来确认哪些sql占用的cpu线程较多4）分析定位问题为谓语后的条件中有列倾斜问题，导致生成的执行计划时有错误计划，从而sql复用计划时，该索引并没有这么好的选择性导致2）在版本上线之后针对该类型SQL通过脚本巡检，及时发现及时绑定执行计划确保索引设计与业务查询需求相匹配。避免过多无用索引或缺失必要索引，这两者都可能影响查询性能。2）针对那些性能差的 SQL，尝试重写或优化这些查询，减少全表扫描，确保使用最有效的索引3）对于关键的业务查询，可以考虑使用执行计划管理工具或特性锁定其执行计划设置机制监控执行计划的效率，一旦发现执行效率下降，自动或手动重新评估并优化执行计划。持续监控 SQL 执行时间、响应时间、系统资源利用率等关键指标。探索使用 AI 或 ML 技术自动调整数据库配置和优化 SQL 执行计划，减少人工干预。确保数据库统计信息的准确性，定期自动更新统计信息，尤其是在大量数据变动后，如批量插入、删除操作后。对于频繁变更的表，考虑设置更频繁的统计信息更新计划，以减少因统计信息过时引起的查询性能问题。确保所有变更都经过充分的测试，包括性能影响评估，在部署到生产环境前进行预备案的执行计划分析。10）为数据库的DDL和关键DML操作实施版本控制确保能够快速回滚至稳定状态以应对意外的性能问题或故障。11）推动OB改进版本，对执行计划突然问题修复
主备集群延迟大，cpu100%，导致应用侧弱读业务无法正常抽数。1）登录cpu高的主机使用top命令查看cpu被什么进程使用2）发现是oceanbase数据库进程导致的CPU使用率过高且sys使用率很高，又通过top-Hpobpid发现大量的dag_minor_metge和replay进程占用通过observer日志发现有问题节点和正常节点有rpc_net包最大有4s延时，但通过clockdiff命令看并没有延时的情况。4）之后又通过perf top发现sys中read_hpet高精度计时器占用了60%左右的CPU5）通过perp record 采集observer进程cpu堆栈信息，发现replay进程相关cpu都在hpet上6）查看 sys/devices/system/clocksource/clocksource0/current_clocksource 文件发现内核的现在使用的时钟配置为 hpet和其他正常主机对比而非使用的tsc时间戳时钟，看available_clocksource可用时钟文件中发现没有tsc时钟。尝试将系统时钟源切换到 tsc，如果 tsc 在 available_clocksource 中不可用，可能需要检查BIOS设置或更新系统内核。确认系统的其他配置，如CPU调度策略和内存管理，都已优化，以减少任何可能的系统级性能瓶颈。3）继续加强对数据库操作和系统资源使用的监控，特别是在高负载场景下- 使用如 OceanBase 自带的监控工具或第三方工具（如 Prometheus、Grafana）进行更精细的性能监控。
- 利用日志管理系统，如 ELK (Elasticsearch, Logstash, Kibana) 堆栈，进行日志的集中管理和分析，以便快速定位问题。
4）检查硬件和基础设施的配置是否满足 OceanBase 的性能需求
业务侧反馈业务中有慢sql，但从数据库中查看sql执行速度很快，之后通过proxy日志发现有大量DBMS_LOB包的调用 。1）查看gv$sql_audit中看sql的执行时间均在100ms以内，但应用侧client去查需要2秒钟左右2）通过sqlaudit中的trace_id查看observer日志看时间也并无其他耗时3）通过session_id去查看obproxy日志中用大量的call dbms_lob.open、read、close的调用5）测试将clob字段to_char下sql返回client正常6）ob原厂确认没有to_char时走的是lob流程返回lob locator调用dbms_lob.open、read、close是obci的行为，而to_cahr后就不是返回loblocator ，所以少了dbms_lob包调用的这些过程而在ob32x版本中loblocator中是保留着clob的完整数据的，所以并不需要去调用dbms_lob这些包，因为在业务sql的clob这一列在preparestatement 中定义SQLT_CLOB时绑定了返回数据，业务认为返回的是Loblocator，拿到这个数据之后，会再走一遍标准的oracle流程来获取数据（调用dbms_lob)，实际和oracle的调用逻辑是一样的。7）obci研发重新发版优化clob这块读取逻辑，dbms_lob包不返回内核处理如果业务逻辑允许，考虑在数据库层面将 CLOB 字段转换为字符类型（如您测试中使用的 TO_CHAR），这样可以减少应用层的处理负担，加快数据检索速度。在客户端应用中优化对大对象（LOB）的处理逻辑，确保在使用这些对象时尽量减少不必要的数据库调用。3）OB厂商在新版本中对 LOB 处理逻辑进行了优化评估和调整数据库参数，优化 LOB 处理的性能，例如增加缓存大小或调整数据库的 LOB 读取策略。5）持续监控数据库操作性能，尤其关注涉及大数据量传输的操作使用数据库和应用级别的日志记录工具，定位性能瓶颈。6）在系统测试阶段加大对 LOB 处理逻辑的测试覆盖在生产环境部署前，进行详细的性能评估，确保新的代码或配置修改不会引入新的性能问题。
k8s主机集群主机节点到端口8082不通（网络策略已经申请，并且网络策略已经实施完毕），网络策略配置没有问题，端口却依然不通。1）检查134.84.xx.xxx到目标主机134.84.xx.xxx 8082 端口不通同时不能ping通2）通过在目标主机上tcpdump抓包，没有抓到源主机 134.84.xx.xxx的请求数据包tcpdump -i any -nn host 134.84.xx.xxx
3）通过traceroute 定位分析，没有走网关134.84.25.14）通过路由表分析，到目标 134.84.xx.xxx 8082，没有经过网关 134.84.25.1134.84.xx.xxx/24是宿主机的地址，134.84.xx.xxx/16的是k8s apiserver 高可用使用的VIP。6）查看VIP 134.84.xx.xxx/16是keepalived容器在使用这个是apiserver的高可用配置的VIP，通过3个节点上运行的k8s-keepalive容器实现，通过查看，发现上面的VIP的子网掩码写成了16位了。先备份3个master节点上的配置文件，把配置文件里面的VIP子网掩码修改为24位。3个节点依次重启k8s-keepaive容器后，通过ip a |grep 134.84查看，VIP子网掩码依然为16位,修改映射到宿主机的配置文件后，没有用，还需要修改容器里面的配置文件。再次在宿主机上通过 ip a |grep 134.84查看 VIP子网掩码为24位了。路由表恢复正常。在修改网络配置后，应有一套验证流程来确保所有更改均已正确生效。这包括验证配置文件和运行时配置是否一致，以及确保所有相关服务（如keepalived）使用的是更新后的配置。考虑实施自动化工具来监测集群的网络状态和配置一致性。例如，可以开发一个简单的脚本定期检查VIP配置，并与预期状态对比，自动报告或修正偏差。在进行类似的网络配置更改时，记录详细的操作日志非常关键，有助于故障回溯，也有助于未来的问题预防和系统优化。建立和遵循严格的变更管理流程，任何网络或系统配置的更改都需经过适当的审查和批准。加强对关键网络组件（如VIP、路由器、网关等）的监控，设置适当的警报，以便在问题发生时能够及时发现并采取措施。
1）通过kubectl exec 命令进入pod，等待一会，报错，无法进入pod2）从执行命令的节点，ping pod所在的宿主机节点IP通。telnet 那个无法进入pod所在的宿主机的10250端口不通3）ssh到pod所在的节点，在本地telnet 1XX.0.0.1 10250不通查看节点上10250端口是在监听的，但telnet不通。4）怀疑是防火墙的问题,通过命令systemctl status firewalld服务是关闭的通过关闭systemctl stop kubelet kube-proxy，关闭docker进程，在进行重启，发现端口恢复了，再次执行kubectl exec ，就可以正常进入pod了。6）只重启kube-proxy 在另一个节点验证是不行，还需要重启docker进程1）实施实时监控，特别是针对关键服务和端口的可达性，以便及时发现并解决问题2）审查 kubelet、kube-proxy 和 Docker 服务之间的依赖关系和启动顺序。错误的启动顺序可能导致网络或服务初始化不正确3）制定一套标准化的网络故障恢复流程，包括服务重启、网络连接测试和验证步骤考虑自动化一些恢复步骤，如自动检测端口不通并尝试重启相关服务。
需要查询历年数据进行核对，db2数据保留的时间无法满足于当前需求，所以进行数据恢复供查证。问题1：恢复数据中，执行恢复脚本会出现的问题，出现过bad container…错误- 原因1：因为可能是指定的路径正在被自动存储使用。要确定是否是这种情况，可以列出表空间的容器路径，并确定是否正在使用自动存储。
- 处理1：Db2pd -d databasename -tab查看最后一项中的path是否存在，存在的且被使用的话，可以在他原来路径的子目录下新建一个目录。
问题2：SQL0294N The container is already in use. SQLSTATE=42730跑恢复脚本的时候会提示容器正在被使用。- 处理2：可以使用db2untag -f 报错的lv路径去除容器标记。
注意：使用untag时要特别小心。如果您对数据库仍在使用的容器发出命令，那么最初使用该容器的数据库以及现在正在使用该容器的数据库都将毁坏。1）在进行任何恢复操作前，确保有完整的备份，并验证备份数据的完整性2）尽可能在隔离环境中进行数据恢复操作，避免对生产环境造成干扰包括在测试服务器上进行恢复尝试，以确保所有步骤都不会对生产数据造成影响。这对于追踪错误、分析问题源以及未来的审计都非常关键。4）在遇到特定错误（如“bad container”）时，制定标准操作流程（SOP）流程应包括检查步骤、验证环节以及如何安全地解决问题而不影响现有数据。
goldendb上线前，需要验证快速拉起一套对应的镜像数据库，用于业务日常测试。在测试拉起过程中发现分片数据与源端不一致。在CN端无法查询到，例如:"select * from tab where id = 1"；如果指定分片可以查询到，例如:"select * from tab where id = 1 storagedb g1"；初步确定数据在g1上，但DB并没有到g1上去找数据， 通过执行计划方式能够比较直观的看到这一现象(执行计划extra提示：no matching row in const table, g5)。经备份厂家核实后反馈，该问题为程序bug(挂载的时候gid顺序出现bug，导致随机挂载)，经过修复bug后复测，数据正常。1）在部署和测试过程中，确保系统和应用的日志记录详尽并开启，这将有助于在问题发生时快速定位问题源2）实施自动化的数据一致性检查工具，定期或在关键操作后执行，以确保数据在各个分片之间保持一致3）开发更健壮的错误处理逻辑，一旦检测到数据一致性问题或其他关键错误，立即触发警报并启动预定义的回滚流程
登录主机参看cn节点状态，dbproxy进程已经被agent进程拉起，但不到5分钟后发现cn再次断连，异常节点为运维节点，和业务沟通后手动停止agent防止进程再次拉起，待找到根因并解决后在拉起。通过查看dbproxy.log未发现异常，无error信息。但/data/core下发现每次重启后都有异常的core文件。通过手动coredump文件发现是由于一条运维语句导致，在和业务确认后暂停该语句执行，再次拉起cn后未发生重启。当检测到系统关键组件失败时，能自动回滚到上一个稳定状态。如在检测到CN节点异常时，自动将流量切换到备用节点。确保所有软件都是最新的，并且已应用了所有安全补丁。包括触发CN节点断连的场景，以测试系统的恢复能力和操作团队的响应流程。
mysql5.7升级版本后版本回退导致数据文件损坏
mysql5.7升级mysql8版本回退出现引发数据文件损坏，数据库启动失败。1）通过分析数据库日志，当回退mysql版本到5.7时，以mysqld_safe安全方式启动mysqld进程，拉起服务时读取ibdata共享表空间文件失败，无法加载表元数据到服务层2）由于备份共享存储空间不足，导致最近的备份失败，所以无法采用全备方式来恢复数据3）采用ibd文件修复表数据和最近一次日常全备数据、增备数据和binlog日志恢复，同步进行数据恢复，修复未果4）使用mysql官方传输表空间方式恢复大表数据来尝试修复- 目标库表中discard TABLESPACE 移除新实例的ibd表空间；
- 复制备份的datadir原数据 idb 到数据目录下；
- 执行IMPORT TABLESPACE 从从ibd文件导入数据。
5）在备库上拉起一个mysql新实例3308，将datadir目录数据拷贝到新实例的data目录，移除旧的ib_logfile引擎日志数据，并修改innodb_force_recovery参数为0，mysql加载#innodb_redo下的innodb日志数据文件，成功拉起数据库6）在业务主库上拉起mysql8服务，使用mysql克隆将备库恢复出来的业务数据备份到生产库，启动主库mysql服务正常，检查业务系统数据正常1）在进行任何升级或回退操作之前，详细评估版本兼容性和官方文档，确保所有步骤符合最佳实践和兼容性指南2）强化数据备份机制，确保备份任务的成功执行，并定期验证备份数据的完整性和可恢复性3）扩展或优化备份存储空间，避免由于存储空间不足导致的备份失败4）制定更全面的灾难恢复计划，包括备份策略、紧急回滚操作、数据一致性检查和恢复演练新炬运维避坑指南连载合集链接：
https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzUxNTYzMjA5Mg==&action=getalbum&album_id=2846038717288693763#wechat_redirect
