点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！
- 磐维数据库oracle迁移磐维pg_log报错问题分析；
- Goldendb数据库cdc复制关系异常问题分析；
- Goldendb数据库RDB主备数据不一致问题分析；
oracle迁移磐维，dtp迁移时，主节点coredump，pg_log报错 stack smashing detected。PanWeiDB_V2.0-S3.0.0_B01三节点集群。在将oracle数据迁移到三节点磐维集群后，发生主备切换。查看主节点数据库日志，分析产生的core日志。但因为core文件的生成大小被限制了，重新设置生成core文件的参数。修改/etc/sysctl.conf文件中croe文件的生成路径以及/etc/security/limits.conf 文件中omm soft core 和omm hard core参数大小，限制core文件的生成上限。上传分析core文件的工具。通过分析core文件，获得如下信息：- 堆栈中的：
in __stack_chk_fail () from /lib64/libc.so.6
in set_var_from_str (省略) at number.cpp:1126
in number_in (fcinfo=<optimized out>) at number.cpp:549
确定为已知缺陷，插入结尾存在大量 0 的 number 类型会触发。
确定为已知缺陷，插入结尾存在大量 0 的 number 类型会触发。createtable t_0929(a number);
insertinto t_0929 values ('11111111111111111111111111000000000000000000000000000000000000000000000000000000000');。
该缺陷在高版本中被修复，当前集群版本PanWeiDB_V2.0-S3.0.0_B01，解决该故障最低需要升级到PanWeiDB_V2.0-S3.0.1_B01，版本升级后上述复现用例正常执行后，未引起数据库异常。及时关注磐维数据库版本更新，以及更新后所解决问题。登录cdc节点，查询cdc的~/log/mysqld.log日志trx gtid的error信息。修改报错日志中的ctid号的强制合并参数force_merge=0：update mysql.cdc_discard_trx_ctid_info set force_merge=0where ctid='466032006987778';
stopslave cdc;
startslave cdc;
1）CDC ( Change Data Capture )节点指变动数据捕获节点，用于对 GoldenDB 数据库分布式模式下各个分片的 DN 节点进行数据捕获insight告警平台发现报“RDB主备数据不一致”告警。主管理节点的rdbagent日志中查询关键词inconsistent，发现表mds.gtm_info存在数据不一致问题。xxx.xxx.xxx.17RDB备节点表mds.gtm_info 中有3条数据的字段 gtm_status 字段与主RDB不一致。登录xxx.xxx.xxx.17 节点，切换用户到insight，停止备机复制。文件系统目录使用率告警，审计日志的删除使用rm -rf *.aud，报错：-bash: usr/bin/rm: Argument list too long
Linux 系统限制单次命令参数长度约 2MB，当文件数量超过数万时，rm 命令直接失败。空间剩余足够：mv adump adump.bak && mkdir adump rm -rf adump.bak
空间剩余不够：find /oracle/app/19.3.0/grid/rdbms/audit -name "*.aud" -mtime +30 -delete
ALTERSYSTEMSET audit_sys_operations=FALSESCOPE=spfile; -- 关闭sys审计
ALTERSYSTEMSET audit_trail=NONESCOPE=spfile; -- 关闭数据库审计
#!/bin/bash
# 保留7天审计日志
find oracle/app/*/grid/rdbms/audit -name "*.aud" -mtime +7 -delete
主库在 发生异常，系统检测到所有 HA peer 心跳失败，触发强制停止实例操作，随后由管理进程重新启动主库为 primary 模式。期间连接报错 “transaction aborted as connection handles were destroyed due to clean up stream failed”。故障发生时 CN 报错$GAUSSLOG/pg_log/cn2/***.log：failed to fetch tuples from datanodes, remote close socket unexpectedly。GTM 日志显示多会话超时被关闭$GAUSSLOG/pg_log/gtm1/***.log：close session ... due to session timeout : 60。在 gha_agent 日志中发现触发 kill instance 操作$GAUSSLOG/pg_log/ha/dn2_1/***.log：ping all ha peers failed, kill inst force。随后系统自动执行 gs_ctl stop，出现“single-user server is running”提示。紧接着自动执行 gs_ctl start -M primary，节点恢复正常。确认集群状态恢复后，未发现数据丢失。3）定期验证 GTM、CN、DN 间连接可达性与超时配置gbase8c异机备份报错:Connection timed out,client_loop:send disconnect:Broken pipe怀疑传输日志超时导致，调整了"wal_receiver_timeout = 1800s","wal_sender_timeout = 1800s";调整后依旧报错，继续调整sshd参数，MaxSessions 2000 MaxStartups 2000，调整后报错变成偶发性，怀疑并发过高导致；调整备份脚本并发数：-b PTRACK -j 4 后备份恢复正常；后续发现主机负载高峰时间段备份仍会出现偶发性wal日志传输失败，手动调整错峰备份后现象显著降低。做数据备份时要考虑网络传输带宽以及ssh传输超时问题，可适当调整备份线程数和调度任务以错峰执行。redis-cli --cluster add-node x.x.x.x:x x.x.x.x:x -a $passwd
redis-cli --cluster add-node x.x.x.x:x x.x.x.x:x -a $passwd --cluster-slave --cluster-master-id ******
redis-cli --cluster rebalance --cluster-use-empty-masters --cluster-threshold 1 x.x.x.x:x -a $passwd
提前规划好主从节点映射，计算好平衡需要花费的时间。业务侧使用的是通过kem 部署的redis集群，3主3从模式，进入到redis的pod里面，通过命令cluster info检查redis集群状态正常，执行 cluster nodes 检查3主3从节点也正常。登录redis cluster 3个主节点中，发现大量的slowlog 都是关于固定的key，排查redis 相关pod的监控，发现redis 每秒处理的命令数超过5000，且使用的cpu 已经到达99%。分析业务请求比之前大很多，有频繁的大Key操作，排查redis 相关监控数据，发现有两个redis 主节点每秒命令执行数为 9000次/s，redis 负载很高。当天业务被访问量突增，业务侧访问频繁大key引起,业务侧访问有大量slowlog 影响redis 处理性能，导致存储那些已经被客户端的TCP三次握手确认，但还没有被Redis服务器处理的连接请求队列满了，新的连接请求将被TCP层拒绝。2）echo never >/sys/kernel/mm/transparent_hugepage/enabled 的作用是禁用透明大页功能3）更改了net.core.somaxconn 内核参数，调整为65535 它定义了TCP连接监听队列的最大长度DCS参数max_replication_slots配置小于数据库复制槽个数，导致数据库启动失败，而修改DCS参数、重建etcd都无法解决问题，割接回退。研究后，删除patroni.dynamic.json文件，则重启patroni即可生效。部分品牌的物理机由于硬件的watchdog配置，导致触发watchdog重启的时候，主机启动异常，需去机房进行“contune"操作才可继续启动。关闭硬件watch dog ipmitool mc watchdog off
/dev/watchdog权限问题导致触发重启失败，引发数据库脑裂 。 主从切换后，需检查文件权限，检查patroni日志，确保watchdog已启用。1）数据库重要组件变更，建议使用迁移的方式进行，而不是直接修改组件Hadoop集群出现单NameNode节点异常宕机情况。尝试通过标准流程重启集群时，发现SSH连接至故障节点时触发以下报错：can't be established.ED25519 key fingerprint is SHA256:J5a33/DnLkZNpHppbrojLQeutNHA9+FcElmZmjHOiiQ.This host key is known by the following other names/addresses:~/.ssh/known_hosts
该错误直接导致集群无法完成节点间的SSH免密通信，进而阻断了HDFS、YARN等核心组件的启动流程。分析该错误，经过日志追踪发现，故障节点的SSH服务返回的主机密钥指纹（SHA256:J5a33/DnLkZNpHppbrojLQeutNHA9+FcElmZmjHOiiQ）与~/.ssh/known_hosts文件中记录的其他主机名/IP地址绑定的密钥存在冲突。导致hadoop集群使用的主机名无法通过该密钥建立免密关系。登陆故障节点，对~/.ssh/known_hosts文件进行备份，之后清理~/.ssh/known_hosts内保存的密钥信息，并重新为hadoop集群建立免密关系，建立完毕后尝试从其他节点ssh远程登陆异常节点。登陆成功后，为避免服务依赖冲突，采用分级重启策略，依次关闭yarn、dfs、zkfc、namenode、journalnode节点并尝试重新启动集群。1）Hadoop集群需要保持节点间的ssh互信，单点SSH信任关系异常即可导致全局服务启动失败2）节点主机名/IP地址变更后需及时同步更新SSH密钥信任关系新炬运维避坑指南连载合集链接：
https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzUxNTYzMjA5Mg==&action=getalbum&album_id=2846038717288693763#wechat_redirect
