接下来《GaussDB T分布式集群这样安装部署不踩坑》开始GaussDBT的日常维护必做。新的一天从开启主机开始，开启虚拟机后发现上次安装的数据库并没有自动启动，所有节点启动的相关进程只有cm_agent进程：此时，我们首先要启动ETCD：OK，ETCD启动成功，接下来，我们拉起整个集群：集群拉起成功。后面我们会自动拉起etcd和集群加入自启动，再回到开篇的话题，开始日常维护。1、查看集群状态首先当然是查看集群中各个节点的资源状态。至于看什么，我们用一张图来理解要点：1、查看各个节点的资源是否ONLINE，包括CM、CN、DN、ETCD等，如果没有，需要进一步分析原因检查。2、查看每个节点与昨天的对比是否涉及节点切换，查看该节点对应的HOST即可。如有异常，需进一步调查。二、查看主机资源使用情况（所有主机）1、主机目录使用情况df-h2，CPU、内存、IO使用情况。有很多方法可以检查这一点。这里使用了vmstat、iostat和free。请重点关注以下红框位置。说明：id列代表CPU闲置率，free列代表空闲内存，单位为page。解释：rMB/s和wMB/s是每秒读写，%util将统计时间内所有处理IO的时间除以统计总时间。例如统计间隔为1秒，设备处理IO时间为0.8秒，空闲时间为0.2秒，则设备的%util=0.8/1=80%，所以这个参数暗示了设备有多忙.如果参数为100%，表示设备接近满负荷运行（当然，如果是多盘，即使%util为100%，因为磁盘的并发，磁盘使用率可能不是瓶颈）。说明：关注免费和可用。注：本节资源检查需要与baseline进行对比。如果差异过大，则需要进一步检查原因。3、查看各节点的数据库状态，确认CN和DN都处于open状态，注意standbyDN处于mount状态。四、表空间使用情况检查在检查使用情况之前，我们先来说说如何创建表空间。1、连接cnzsqlomm/gaussdb_123@127.0.0.1:8000–q2。创建表空间CREATETABLESPACEtbs_test1DATAFILE'tbs_test1'size100mSHARD;注意：创建表空间时，使用SHARD关键字，支持创建表空间语句自动发送到CN和DN节点，只支持使用相对路径；如果不使用SHARD关键字，可以使用绝对路径，需要在所有的CN和primaryDN节点上创建这个表空间，才能正常使用这个表空间下面创建一个表。3、查看数据文件，我们会发现在CN和DN中已经创建了对应的表空间和数据文件。注意：使用以下命令连接到主DN。zsql/assysdba-D/gaussdb/data/data_dn1-q4、检查表空间的使用率setline300setpages2000settimingoffcoltablespace_namefora25colsum_GBfora15colfree_GBfora15coluse_precentfora15selectb.tablespace_name,round(sum(b.bytes)/1024/1024/1024,0)sum_GB,round(sum(nvl(a.bytes,0))/1024/1024/1024,0)free_GB,round((sum(b.bytes)-sum(nvl(a.bytes,0)))/sum(b.bytes),4)*100use_precent,count(*)from(selecttablespace_name,file_id,sum(bytes)bytesfromadm_free_spacegroupbytablespace_name,file_id)a,adm_data_filesbwherea.file_id(+)=b.file_idanda.tablespace_name(+)=b.tablespace_namegroupbyb.tablespace_namehaving(s(字节)-sum(nvl(a.bytes,0)))/sum(b.bytes),4)*100>=0orderby4desc;注意：需要在所有主CN和主DN上运行表空间使用情况检查。5.查看异常等待事件coleventforma38selectevent,count(*)fromDV_SESSIONSwhereLOCK_WAIT='Y'groupbyeventorderby2desc;注意：检查所有主DN是否有异常等待事件。如图，有TX等待。我们可以通过下面的SQL查看锁源做了什么：selectSID,SERIAL#,USERNAME,CURR_SCHEMA,CLIENT_IP,CLIENT_PORT,OSUSER,MACHINE,PROGRAM,STATUS,LOCK_WAIT,EVENT,MODULE,CURRENT_SQLfromdv_sessionswheresidin(selectWAIT_SIDfromv$sessionwhereeventlike'%TX%');如果应用发现session状态为inactive和connected，可以联系应用检查是否正常。如果你能杀死它，我们可以运行ALTERSYSTEMKILLSESSION'SID,SERIAL#';杀死会话。6、日志检查数据库在运行过程中，会产生大量用于数据库日常维护的操作、审计、DEBUG、告警日志。当数据库发生故障时，这些日志可以用于问题定位和数据库恢复操作。下面简单介绍一下常用的日志类型：1、操作日志打印GaussDBT数据库的操作信息。如果数据库失败，请检查zengine.rlog。日志目录：默认为“$GSDB_DATA/log/run/zengine.rlog”或参数log_home对应的路径run子目录。如果要修改路径，需要重启才能生效。CN节点：DN节点：查看运行日志如下：2、慢查询日志将GaussDB100数据库执行时间超过阈值（由LONGSQL_TIMEOUT参数控制）的SQL信息打印到zengine.lsql日志文件。日志目录：默认为“$GSDB_DATA/log/longsql/zengine.lsql”。3、报警日志打印GaussDB100数据库运行的报警信息。有关警报信息，请参阅zenith_alarm.log。日志目录：“$GSDB_DATA/log/zenith_alarm.log”。4、操作日志通过ZSQL工具记录用户对GaussDB100数据库的操作信息。如果需要了解操作记录，请查看zsql.olog。日志目录：“$GSDB_DATA/log/oper/zsql.olog”。5.TRACE日志记录了数据库会话死锁的信息。有关会话死锁信息，请参阅zengine_00003_xxxxxx.trc。日志目录：“$GSDB_DATA/trc/zengine_00003_xxxxxx.trc”。常见错误码：GS-00716:Found%sdeadlockinsession(%u)错误原因：同一批数据在不同会话中并发操作，导致死锁。解决方法：查看trace日志或运行日志（死锁日志位置根据数据库版本不同）；根据日志中记录的具体信息查看业务语句，包括死锁类型、SQL语句等。GS-00715：快照已过时。原因：快照已过时。解决方法：重新运行SQL；优化或拆分长时间运行的高消耗SQL。GS-00713:Nofreeundopage错误原因：UNDO表空间不足。解决方法：增加UNDO表空间的大小；杀死大事务以释放UNDO。GS-00305：%s超时错误原因：网络api超时。解决方法：请确保主机网络正常。GS-00774:Failoverinprogress,cannotconnected错误原因：备机在做failover时，主机的日志发送线程连接到备机。解决方法：停止主机，将备机升级为主机，将原主机降级为备机。GS-00839:Flushredofile:%s,offset:%u,size:%lufailed原因：写入重做日志文件失败，通常是文件系统或磁盘有问题。解决方法：检查操作系统或磁盘。GaussDBT数据库维护工作量很大。除了上述日常任务外，还有session连接失败、bufferflushing失败、CN/DN节点状态异常、CMServer节点状态异常、主备DN节点日志同步等。过度延迟等问题验证。对于其中的很多，我们可以使用数据库管理器来分析和处理告警，或者使用我们自己的开发脚本来实现告警。维护的目的是让系统更稳定。维护工作越简单，维护人员就越不容易出错。我们的目标是尽可能将维护工作脚本化、工具化和自动化，让人们有时间去做更有价值的事情。路漫漫其修远兮，我们一起努力吧！
