暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / 新炬运维避坑指南连载（十二）

新炬运维避坑指南连载（十二）

IT那活儿 2024-04-16
416

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


  
指南一分钟速览：

1. 磐维数据库主节点呈现readonly状态处置

2. 磐维2.0版本数据库添加数据库白名单出现白名单覆盖的情况

3. ANTDB数据库复制主库性能抖动处理

4. ANTDB数据库监控节点丢失处理

5. MYSQL主从从复制从库中断处置

6. 硬件更换导致K8S服务异常处理

7. ORACLE IPV6改造报错处置

8. ORACLE ADG同步延迟处置

9. OceanBase OAT中添加主机报错处置

10. GreatDB数据库主机开启防火墙导致节点通信故障


一

磐维数据库主节点呈现readonly状态处置

1.1 现象
panweidb主节点处于readonly状态。
1.2 处置过程
1）查看数据库状态发现只读模式被打开
2）排查数据库主节点资源状态
发现所在磁盘使用率未超阈值，默认60%。
gs_check -i CheckDataDiskUsage
3）关闭只读模式
gs_guc reload -N all -I all -c 'default_transaction_read_only = off'
4）清理数据目录磁盘空间
设置datastorage_threshold_value_check=85。
问题解决。
1.3 新炬建议

panweidb默认磁盘告警阈值过低，建议生产环境调高监控告警阈值，"数据库盘空闲率"须大于"数据库只读模式的磁盘占用阈值"。

二

磐维2.0版本数据库添加数据库白名单出现白名单覆盖的情况

2.1 现象
PanWeiDB2.0数据库添加数据库白名单出现白名单覆盖的情况。
2.2 处置过程
1）通过尝试，除了集群内部IP，添加业务IP白名单只能添加三个网段，继续添加会覆盖
2）通过白名单操作函数来替代gs_guc命令
命令格式：select * from modify_hba_config(1, 'host all all xx.xx.xx.xx/0 sha256'::cstring);
该函数直接操作pg_hba.conf文件，需要三个节点都执行。
3）经确认属于磐维2.0数据库在处理白名单时同一网段自动合并了
2.3 新炬建议

磐维2.0的新特性，实践出真知！

三

ANTDB数据库复制主库性能抖动处理

3.1 现象
在进行物理备库的复制的时候，主库的性能有明显的波动，cpu使用率瞬时偏高，系统负载瞬时升高，备库复制出现延迟，这个现象周期性的出现。
3.2 处置过程
1）排查发现物理备库上面设置了 vacuum_defer_cleanup_age这个参数
该参数代表了设置主库垃圾回收延迟，如果设置400，表示垃圾版本将延迟400个事务再被回收。
2）在测试环境中测试发现，有以下问题
主库表膨胀,重复扫描垃圾版本，重复耗费CPU资源进行垃圾回收。如果vacuum_defer_cleanup_age到达阈值同时antdb也产生大量的垃圾，在进行垃圾会少会产生大量的WAL日志，从而造成WAL的写IO波峰波谷的现象。
PS：与该参数相关的参数还有 hot_standby_feedback，max_standby_archive_delay， max_standby_streaming_delay。
3）在注释掉这个vacuum_defer_cleanup_age的参数，并在Prometheus+grafana观察几日后，该现象消失
3.3 新炬建议

在数据库参数在设置之前，需要深知其意、理解参数的具体使用场景，并在测试环境进行测试。

四

ANTDB数据库监控节点丢失处理

4.1 现象
在antdb3节点出现了一个antdb监控节点的丢失，在grafana里面找不到该节点，查询Prometheus日志发现，“Get http://10.142.x.x/metricsdial tcp 10.142.x.x：910x：connect no route to host”
4.2 处置过程
1）设置iptables,没有添加端口910x的防火墙规则
2）更换损坏磁盘，antdb数据库进行了重启
发现另外2台antdb节点，没有防火墙规则，没有丢失监控节点。
经过分析查询pg_stat_activity视图，发现监控账户是长连接，在数据库重启之后长连接断开，在此进行数据库连接的时候由于防火墙阻挡，导致监控节点丢失。而数据库没有重启的节点，由于长连接原因，正常监控。
最后添加这台antdb防火墙规则，开启Prometheus的端口。
问题解决。
4.3 新炬建议

在进行数据库重启或者主机重启之后重新加载防火墙规则。

五

MYSQL主从从复制从库中断处置

5.1 现象
业务mysql以主从从的方式进行搭建，其中主从io进程断开，导致主从从失败。
5.2 处置过程
因国产化系统替换，数据库迁移到国产BC系统，执行数据交换任务，以全量数据写入的方式写入当天最新的数据，对应写入的表数据量较大，缓冲区过小，心跳机制检查失误产生报错。根据告警时间，定位到具体的数据交换任务。
调整任务时间，使其错开执行，未再出现 IO 复制异常的问题。
5.3 新炬建议

尽量避免一次性提交大量更改：将大型事务拆分为较小的子事务，并在每个子事务之间定期提交，以减轻IO压力。

六

硬件更换导致K8S服务异常处理

6.1 现象
etcd的master节点不断选举，由于apiserver通常会使用etcd作为存储后端，存储集群状态信息，所以会导致apiserver的leader也不断选举。
因为应用节点要与apiserver进行交互，来管理和调度应用程序，上述故障会导致应用节点与apiserver及时的或者正确的通信，影响业务应用的使用。
6.2 处置过程
1）检查相关的master节点上的etcd服务运行的状态以及相关events
发现etcd集群不断的在选举，从而导致apiserver也不断在选举，因为apiserver配置的环路地址，并且etcd又在不同的主机上面，那么etcd无法通过apiserver的环路地址进行通信。
2）检查3个节点的服务器的系统状态及日志
发现某台主机（双网卡绑定）的网卡有发生过切换。
3）怀疑etcd选举与网卡发生切换有关，所以首先从控制台将有发生网卡切换的节点驱逐
4）观察k8s集群以及应用，后续逐渐恢复正常
5）将发生过网卡切换的节点提报给硬件厂商，检查相关的网卡硬件
6）硬件厂商更换网卡硬件后，重新纳入该节点到集群，并将该节点设为不可调度状态
7）持续观察一段时间，集群运行状态正常
6.3 新炬建议

对于k8s集群核心组件的故障，切忌盲目进行配置修改，首先应观察节点日志、集群事件。发现并非应用发引起的故障后才应驱逐该节点上的应用并将节点设置为不可调度，继续排查问题所在。

七

ORACLE IPV6改造报错处置

7.1 现象
使用IPv6的subnet[子网号],将新的public网口添加到集群时,报错。
xnpmdb1:/home/oracle(xnpmdb11)$oifcfg setif -global bond0/2409:8050:5a00::fdfb:1:4c00:public
PRIF-33: Failed to set or delete interface because hosts could not be discovered
CRS-02305: GPnP resource discovery (MDNSD) is not running on local node
7.2 处置过程
1）检查mdnsd服务是online的
crsctl status res -t -init
2）尝试重启mdnsd服务
/oracle/app/19.0.0/grid/bin/crsctl restart res ora.mdnsd -init
3）但重启mdnsd服务后,再次使用IPv6的subnet[子网号],将新的public网口添加到集群时仍然报相同的错误
怀疑是该资源对应的进程hang了。通过重启所有节点的CRS,确认CRS重启正常后再次修改成功。
/oracle/app/19.0.0/grid/bin/crsctl stop crs -f
/oracle/app/19.0.0/grid/bin/crsctl start crs
7.3 新炬建议

一定要加强测试，再牛逼的O产品也会有BUG。

八

ORACLE ADG同步延迟处置

8.1 现象
ORACLE ADG搭建过程中，数据通过RMAN做duplicate后，追积累归档，始终追不上。
2023-10-07 08:28:00,2760 ERROR [pool-11-thread-10] [] [HttpsUtil.java:73] - req exception:
org.springframework.web.client.ResourceAccessException: I/O error on POST request for "http://1x.xx.xx.x:8021/api/insightAgent/commonInterface": 拒绝连接
(Connection refused); nested exception is java.net.ConnectException: 拒绝连接 (Connection refused)。
8.2 处置过程
1）怀疑主库归档切换过于频繁
主库的归档切换频繁，每小时约切换130个REDO日志；所以决定优化主库日志，降低减少主备之间的交互次数；调整后再次同步仍无法追平。
2）怀疑主备网络传输问题
主备数据网传输速度测试，主库写到备库的速度约200M/S，做了sqlnet trace未发现异常。
3）怀疑备库存储问题
  • dd命令测试主机存储IO，写入速度500M/S，速度比较正常；
  • 在ASM命令中执行CP，发现32G文件传输大概需要半小时；
  • 传输归档过程中通过OSW监控， iostat 的输出中ASM复制测试期间表现为 util%将近100%，并且 wkB/s 并不高,代表 IO 等待时间的w_await和 r_await 也非常高。
4）定位到磁盘问题后我侧协调主机排查了储存链路问题
当前存储是配置了8条链路，在8条链路逐一测试后，发现其中有两条链路存在问题，踢掉两条链路后，ASM 复制大约80M/S，待应用侧完成链路调整，追平归档。
8.3 新炬建议
1）主机侧交付主机环境后对CPU，内存，储存等做检查

2）搭建完RAC后，可以在ASM中做数据文件复制来测试ASM中磁盘的IO效率

九

OceanBase OAT中添加主机报错处置

9.1 现象
OB oat中添加主机，precheck环境校验步骤报错openfiles配置值太小。
9.2 处置过程
1）部署背景
  • oat上添加服务器主机，服务器用途配置为OBServer；
  • 凭证使用root用户；
  • 操作系统为统信OS V20；
2）检查报错内容
[2024-03-08T15:40:09.047+0800] ERROR - check current session hard limit of open_files (ulimit -H -n): 4096 != 655360 ... EXPECT 655360 ... FAIL
[2024-03-08T15:40:09.047+0800] ERROR - TIPS: excute: ulimit -H -n 655360
[2024-03-08T15:40:09.047+0800] ERROR - check current session soft limit of open_files (ulimit -S -n): 1024 != 655360 ... EXPECT 655360 ... FAIL
[2024-03-08T15:40:09.047+0800] ERROR - TIPS: excute: ulimit -S -n 655360
3）过程排查
  • 通过检查oat中precheck.sh脚本中与openfiles相关的内容，发现脚本会对root用户和admin用户都进行最大打开文件资源配置进行检测；
  • 本地查看ulimit参数也都符合要求；
  • 在本地通过ssh方式远程执行precheck.sh脚本发现会与使用oat执行该脚本报一样的错误。
4）分析故障
  • 通过百度分析ssh的UsePAM参数可能会导致openfiles等ulimit配置检测异常；
  • 统信OS sshd默认关闭UsePAM；
  • 修改sshd_config，配置UsePAM 为yes，重启sshd服务后继续执行oat任务检测通过。
9.3 新炬建议

OB数据库对资源限制相关配置要求比较严格，PAM参数会影响OpenSSH会话的资源限制。针对远程检测ulimit资源限制，注意Openssh的UsePAM配置。

十

GreatDB数据库主机开启防火墙导致节点通信故障

10.1 现象
GreatDB数据库主机开启了防火墙导致节点通信故障。放开防火墙后，事务出现异常sqlnode节点无法加入集群。
10.2 处置过程
踢掉报错的sqlnode error节点，重新初始化sqlnode节点。
10.3 新炬建议
目前国产数据库整体文档、生态均属于建设过程中，摸石头过河，此案例其实就是一个摸石头过河的案例。

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

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


END


本文作者：秘而不宣(上海新炬中北团队）

本文来源：“IT那活儿”公众号

数据库集群集群技术防火墙集群服务器数据库
文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论