本文由 dbaplus 社群授权转载。
继《GaussDB T分布式集群这样安装部署不踩坑》,我们开始 GaussDB T 每日维护必做的事情。新的一天从开启主机开始,把虚拟机打开后发现上次安装的数据库没有自启动,所有节点启动的相关进程仅 cm_agent 进程:
这个时候我们先要拉起 ETCD:
OK,ETCD 成功拉起,接下来我们拉起整个集群:
集群拉起成功。
后面我们会将 ETCD 及集群自动拉起加入自启动,下面开始回到开篇的主题,每日维护开始。
一、集群状态检查
第一件事当然是检查集群各节点资源状态情况啦,至于看啥,我们用一张图来了解要点:
1、查看各节点资源是否是 ON LINE,其中包括 CM,CN,DN,ETCD 等,如果不是,需进一步核查原因了。
2、查看各节点对比昨日是否涉及节点切换情况,查看节点对应的 HOST 即可。如有则异常,需进一步核查原因了。
二、检查主机资源使用情况(所有主机)
1、主机目录使用率
df -h
2、CPU、内存及 IO 使用情况
这个检查的方法很多,这里使用了 vmstat,iostat,free,请重点关注以下红框标示的位置。
释:id 列代表的是 CPU 空闲率,free 列代表的是空闲内存,单位为页。
释:rMB/s 及 wMB/s 的是每秒读写情况,%util 在统计时间内所有处理 IO 时间,除以总共统计时间。例如,如果统计间隔 1 秒,该设备有 0.8 秒在处理 IO,而 0.2 秒闲置,那么该设备的 %util = 0.8/1 = 80%,所以该参数暗示了设备的繁忙程度。如果该参数是 100%表示设备已经接近满负荷运行了(当然如果是多磁盘,即使 %util 是 100%,因为磁盘的并发能力,所以磁盘使用未必就到了瓶颈)。
释:重点关注 free 及 available。
注:本节资源检查需与基线进行比对,如出入过大需进一步核查原因。
三、核查各节点数据库状态
确认 CN 及 DN 都处于 open 状态,注意备 DN 是 mount 状态。
四、表空间使用率检查
当在进行使用率检查之前,先说下表空间如何创建。
1、连接到 cn
2、创建表空间
注:创建表空间时,使用 SHARD 关键字则支持将创建表空间语句自动下发至 CN 和 DN 节点且仅支持使用相对路径;若不使用 SHARD 关键字,则可使用绝对路径,同时需要在所有 CN 和主 DN 节点上都创建这个表空间后,才能正常在这个表空间下创建表。
3、检查数据文件,我们会发现在 CN 及 DN 都创建了对应的表空间及数据文件
注:连接主 DN 使用如下命令连接。
4、检查表空间的使用率
注:表空间使用率检查需在所有的主 CN 及主 DN 运行。
五、异常等待事件检查
注:在所有主 DN 核查是否存在异常等待事件。
如图所示存在 TX 等待,我们可以通过以下 SQL 查看下锁源在干啥:
如发现会话状态是非活动且是应用程序连上来的,可以联系应用核查是否正常,如可以 kill 我们可以运行 ALTER SYSTEM KILL SESSION ‘SID,SERIAL#’; 杀会话。
六、日志检查
在数据库运行过程中,会产生大量用于数据库日常维护的运行、审计、 DEBUG、告警等日志。在数据库发生故障时,可以使用这些日志进行问题定位和数据库恢复的操作。
下面就常用的日志类型做下简介:
1、运行日志
打印 GaussDB T 数据库运行信息,如果数据库出现故障,请查看 zengine.rlog。
日志目录:默认为“ $GSDB_DATA/log/run/zengine.rlog”或参数 log_home 对应的路径 run 子目录下,如果想修改其路径重启生效。
CN 节点:
DN 节点:
查看运行日志如下:
2、慢查询日志
打印 GaussDB 100 数据库执行时间超过阈值(由 LONGSQL_TIMEOUT 参数控制)的 SQL 信息到 zengine.lsql 日志文件中。
日志目录:默认为“ $GSDB_DATA/log/longsql/zengine.lsql”。
3、告警日志
打印 GaussDB 100 数据库运行告警信息。如需了解告警信息,请查看 zenith_alarm.log。
日志目录:“ $GSDB_DATA/log/zenith_alarm.log”。
4、操作日志
记录用户通过 ZSQL 工具对 GaussDB 100 数据库的操作信息。如果需要了解操作记录,请查看 zsql.olog。
日志目录:“ $GSDB_DATA/log/oper/zsql.olog”。
5、TRACE 日志
记录数据库会话死锁的信息。如需查看会话死锁信息,请查看 zengine_00003_xxxxxx.trc。
日志目录:“ $GSDB_DATA/trc/zengine_00003_xxxxxx.trc”。
常见错误码:
错误原因:不同会话中并发交叉操作了同一批数据,造成死锁。
解决办法:
查看 trace log 或者 run log (根据数据库版本不同,死锁日志位置不同);
根据日志里记录的具体信息,包括死锁类型,SQL 语句等,排查业务语句。
错误原因:快照过旧。
解决办法:
重新运行 SQL;
将长时间运行的高耗 SQL 优化或拆分。
错误原因:UNDO 表空间不足。
解决办法:
增大 UNDO 表空间大小;
将大事务 kill 释放 UNDO。
错误原因:网络 api 超时。
解决办法:
请确保主机网络正常。
错误原因:备机正在做 failover 时,主机的日志发送线程来连接备机。
解决办法:
将主机停止掉,待备机升主后,将原主降备。
错误原因:写 redo 日志文件的时候失败了,一般是文件系统或者磁盘有问题。
解决办法:
检查操作系统或磁盘。
GaussDB T 数据库维护的工作很多,除了以上每日必做的事情之外,还有会话连接失败、缓冲区刷盘失败、CN/DN 节点状态异常、CM Server 节点状态异常、主备 DN 节点日志同步延迟过大等等问题核查。其中很多我们可以通过使用 Database Manager 分析处理告警或者使用自己开发脚本实现告警。
维护的目的是让系统更稳定,维护工作越简单,维护人员就越不容易出错。尽可能的把维护工作脚本化、工具化、自动化,将人员解放出来做更有价值的事情是我们的目标。路漫漫其修远兮,一起加油吧!
作者介绍:
魏斌,新炬网络资深数据库专家,长期服务于运营商、金融、制造业及政企客户。从传统商业 DB 到开源分布式,均有涉猎及独到见解。职业以来扎根客户一线,对于紧急故障处置及性能问题优化具有丰富经验,尤善于灾备、多中心建设及异构数据迁移。
原文链接:
评论 1 条评论