greenplum维护.docx
《greenplum维护.docx》由会员分享，可在线阅读，更多相关《greenplum维护.docx（18页珍藏版）》请在冰点文库上搜索。
greenplum维护
V0.2
GREENPLUM数据库日常维护手册
第一章GP服务器每日例行检查
1.1、检查时间
0）早上起床后（建议值班人员操作，如果无值班条件可以省略，有条件的可以适当提前）
1）早上上班后
2）中午午休前
3）中午午休后
4）晚上下班前
5）晚上休息前（建议值班人员操作，如果无值班条件可以省略）
1.2、检查方法
运行gm监控程序，运行方式为./gm
主监控界面如下，如果出现非正常显示在日检查表“GM程序运行正常”一栏填写实际情况，否则打勾即可。
1.3、检查内容
1.3.1各服务器硬盘使用情况
主要看硬盘使用占比boot、data、dev、shm、root。
对于ETL服务器，建议不要超过硬盘空间的85%；对于greenplum节点，建议不要超过硬盘空间的75%，以免影响greenplum数据库的效率。
将数据盘中占用最高的数值填写在日检查表“数据盘最高占用“一栏。
超限时要及时处理或向总部系统集成求助。
1.3.2各服务器硬盘读写情况
主要看各个segment数据节点读写情况R1K/S、W1K/S、R2K/S、W2K/S应该大致相同，如不同，需要检测不同的原因，一般可能是数据倾斜的问题。
对于其他原因，需要根据具体情况进行检测。
硬盘读写速度的大致平均数（前读后写中间加／符）填写在日检查表“IO速度率”一栏。
1.3.3各服务器内存使用情况
需要根据具体情况，如发现内存使用异常（MemIdl明显低于其他机器），则需执行top命令找出异常进程进行分析。
SWAP平均空闲值填写在日检查表“swap空闲”一栏；内存空闲值的大致平均数填写在日检查表“MemIdl”一栏。
1.3.4各服务器CPU使用情况
需要根据具体情况，如发现CPU使用异常（CpuIdl明显低于其他机器），则需执行top命令找出异常进程进行分析。
CPU空闲的大致平均数填写在日检查表“CpuIdl”一栏。
1.3.5各服务器IOWAIT情况
需要根据具体情况，如发现IOWAIT异常（IOWait明显高于其他机器，或所有机器都很高超过15%），则需执行top命令找出异常进程进行分析。
IOWAIT的大致平均数填写在日检查表“IOWait”一栏。
1.3.6查看RAID硬盘的状态
即WritePolicy参数，正常状态显示为WB即WriteBack状态。
全部为WB时在日检查表“WritePolicy”一栏打勾，有其他值时标注机器名和状态。
1.3.7查看RAID卡电池属性
即BATTS属性，正常状态显示为Ready状态。
全部为Ready时在日检查表“Batts”一栏打勾，有其他值时标注机器名和状态。
1.3.8查看greenplum镜像状态
即Mirroralert状态。
如果正常则没有显示，这时可在日检查表“MirrorAlert”一栏打勾，否则按实际界面报告情况填写。
如果出现镜像丢失，则会出现异常状态。
需要根据实际情况，对丢失的镜像及时进行修复，修复时记得要填写维护日志，一旦涉及到修改系统参数，务必先备份并在维护日志中记载备份文件名。
一般修复镜像需要在系统较空闲时进行，最好是没有任务时进行，必要时可以将/data/master/gpseg-1/pg_hba.conf中的相应行注释掉禁止可能连接数据库的终端连接数据库，修改后执行gpstop–u使临时配置生效，但一定要记得在修复后恢复配置，并运行gpstop–u使原配置生效。
修复指令根据镜像告警不同也有所不同，当告警信息如图所示时需要执行gprecoverseg修复。
如果告警信息如下图所示，需要执行先gprecoverseg修复，完成后一定要先重启数据库，再执gprecoverseg–r修复，目前已有三套数据库因为没有重启后再-r修复而报废，请务必注意。
如果告警信息如下图所示，需要执行gpinitstandby-n修复，注意修复过程会重启数据库，务必确认数据库中没有数据加工任务在运行，确实可以重启时运行此指令，
这个指令花费时间根据数据库的系统表大小会有很大差别。
可以进入到如下目录查看：
只有base和global的大小是相关的，其他无所谓
1.3.9查看是否存在WAITING操作
在runningcSql区域有一个列正常是空白的，如图所示的第4个列，如果这个列不是空白而是出现WAITING，就要及时与总部技术支持联系查找原因了。
空白时在日检查表“WAITING”一栏打勾，否则打X。
1.3.10查看硬件告警
正常情况下这告警区域（在最下方区域）是空白的，日检查表“SystemAlertlog”一栏打勾，否则将告警摘抄在这一栏。
如果出现告警需要确认故障，并及时报修。
如果不能确认或不会确认可以申请公司总部的技术支持。
或者告警很多时，可以请总部支持清除日志。
下图所示的故障发生在一次重启机器后，故障信息是电池充电由于温度过高的原因而中止。
这是一个可以忽略的故障，清除日志即可。
硬件出现紧急告警（Critical）的处理流程：
1、机器失联处理流程：
1）发现方法：
gm运行时，出现以下信息或者列表中缺少一台机器。
确认办法可以再开一个SSH窗口，运行gpssh–fhost_all
出现以上信息时表示ftp2这台机器已经无法连接上了，处于失联状态，需要到机房处理或远程idrac方式处理。
马上联系局方运维部门紧急联系人通知其处理。
如果联系不上通知公司项目经理或直接领导，进行紧急协调。
2）恢复联系ssh连接成功后，一般要进行镜像修复处理，参照镜像处理相关章节处理。
2、超温告警处理流程：
1）发现方法：
3、硬盘告警处理流程：
4、CPU告警处理流程：
5、内存告警处理流程：
硬件出现非紧急告警（Non-Critical）的处理流程：
第二章GP服务器每周例行检查
2.1、检查时间
每周二下午（可根据实际情况调整）
2.2、检查方法
进入机房目测体感记录
2.2.1观察告警灯
如果发现告警灯亮起，可以运行omreportsystemalertlog查看所有告警信息。
如果找不到故障，查看DESET日志，方法是运行./dell-dset-3.3.0.300_x86-64.bin，注意要先登录到故障机器，经常有人在主控机上就运行检查指令，结果找不到问题，这种错误很常见，需要特别注意。
2.2.2测量机位温度，电源情况
要求项目组购买便携式电子温湿度计，测试相应机位的温湿度，并记录在案，因为GP数据库集群往往安装密度较高温度明显高于机房整体温度。
查看机架上的电流电压表，记录在案。
一旦发现局部温湿度超标或电源异常报局方处理。
指标要求机器面板一侧的温度在18-25℃之间，湿度在40-60%之间。
电压在210-230V之间,
电流无指标要求，但要记录每次电流数值，波动在20%以上，并且没有设备增减的情况下，需要引起注意。
2.2.3检查设备情况
检查电缆及标签是否规整，护板是否齐全，如果发现异常记录在案并通知局方处理。
第三章GP服务器每月例行检查
3.1、检查时间
每月25日前，下午
3.2、检查方法
3.2.1检查DESET日志
3.2.1.1运行DESET日志收集过程
运行后先是提示一些帮助信息，一屏显示不全是会出如下提示，可打空格跳过，
再提示版权信息，回答y并且回车，
在如下菜单中选择2回车
接下来回答8次y加回车，注意是y回车y回车。
。
。
y回车，共8次
然后在如下提示下，输入root用户的密码，一定要输入正确。
并回车
然后需要等大约10分钟左右。
下图中最长的那一行，提示了日志文件存放位置及文件名。
2.2.1.2查看DESET日志
将生成的ZIP文件下载到客户端，解压缩，密码是dell
双击打开hat文件
打开System下的HardwareLog
找到打红X的行。
下边这张图最后一行表示CPU1出现故障需要维修，上数几行可以发现CPU2也发生了故障，参照16小时以下硬件维修流程进行
3.2.2检查重启时间及定期重启
在这里我们注意到sdw16、sdw14两台机器的资源占用较高，经反复查询居高不下，此种情况需要对此集群全体数据节点重启。
具体操作步骤如下
3.2.2.1定期重启流程
由于系统长时间运行后会产生资源泄露等问题，建议每月硬重启一次。
1）根据实际情况确定重启时间窗口。
业务部门、维护部门会同联通维护方协商确定时间窗口，建议以下午跑完数据即可开始，以免如此大量机器生启时发生故障没有预留处理时间，影响使用。
2）将以上时间窗确定后，发业务、维护部门及联通运维信息化相关人员。
3）执行前通知运维屏蔽相关机器的监控短信告警。
3）确认业务停止，后开始下达关闭数据库指令。
4）确认数据正常关闭后，与运维沟通确认短信已停好。
4）以集群为单位，确认停库后，关闭双号节点。
5）启动双号节点，确认无误后，关闭单号节点。
6）启动单号节点，确认无误后，启动数据库。
7）通知运维部门恢复相关机器的监控短信告警。
8）通知业务使用部门测试是否正常。
9）离场。
第四章系统及硬件维护流程
4.1硬件维护一般流程
4.1.1硬盘故障维修流程：
请将以下标签完善联系方式后打印并永久性放置于每台机器前部醒目位置
注意：
1、禁止同时更换同一RAID组内两块（含）以上硬盘，否则必然会丢失数据。
2、务必在第一块硬盘更换完毕，确认数据同步结束后（约两小时），再更换下一块硬盘。
3、操作前请将双手在机架金属裸露部分充分抚摸释放静电，必要时使用防静电手腕。
4、进行任何操作前，请与维护总管联系：
电话号，姓名
1）硬盘故障维护实际操作比较简单，支持热插拔，找到故障盘（有故障灯亮起）取下，然后插入新盘。
务必详细阅读以下注意事项后方可操作。
2）禁止同时更换同一RAID组内两块（含）以上硬盘，否则必然会丢失数据。
必须在第一块硬盘更换完毕，并且同步数据结束后，再更换下一块硬盘。
3）硬盘出现故障后须及时更换，以免造成数据丢失。
更换时限暂定72小时。
4）更换硬盘必须有局方随工人员随同，并注意操作前将手在机架金属裸露部分充分抚摸释放静电，如果在静电高发地区应参照当地机房规定使用防静电手腕。
5）监控实例：
执行指令：
omreportsystemalertlog这是河南联通的一次主动维护，从下往上看，第一块标注为硬盘出现紧急告警，第二块标注为旧硬盘被取下，第三块标注为新的硬盘被插入，第四块标注为新硬盘再次下线进行数据同步，第五块标注为新硬盘数据同步结束正式上线。
数据同步时间大约为2小时。
第一次告警到取下故障硬盘中间这段时间，每24小时系统重复告警一次，这个在下边的告警信息中也可以看得出来。
755:
Severity:
Ok
756:
ID:
2121
757:
DateandTime:
2013-06-2612:
31:
43
758:
Category:
StorageService
759:
Description:
Devicereturnedtonormal:
VirtualDisk2（VirtualDisk2）Controller0（PERCH710PMini）
761:
Severity:
Non-Critical
762:
ID:
2050
763:
DateandTime:
2013-06-2610:
33:
45
764:
Category:
StorageService
765:
Description:
Physicaldiskoffline:
PhysicalDisk0:
1:
6Controller0,Connector0
773:
Severity:
Ok
774:
ID:
2121
775:
DateandTime:
2013-06-2610:
33:
45
776:
Category:
StorageService
777:
Description:
Devicereturnedtonormal:
PhysicalDisk0:
1:
6Controller0,Connector0
785:
Severity:
Ok
786:
ID:
2121
787:
DateandTime:
2013-06-2610:
33:
44
788:
Category:
StorageService
789:
Description:
Devicereturnedtonormal:
PhysicalDisk0:
1:
6Controller0,Connector0
791:
Severity:
Non-Critical
792:
ID:
2049
793:
DateandTime:
2013-06-2610:
31:
59
794:
Category:
StorageService
795:
Description:
Physicaldeviceremoved:
PhysicalDisk0:
1:
6Controller0,Connector0
797:
Severity:
Non-Critical
798:
ID:
2094
799:
DateandTime:
2013-06-2603:
29:
23
800:
Category:
StorageService
801:
Description:
PredictiveFailurereported:
PhysicalDisk0:
1:
6Controller0,Connector0
809:
Severity:
Non-Critical
810:
ID:
2094
811:
DateandTime:
2013-06-2503:
21:
29
812:
Category:
StorageService
813:
Description:
PredictiveFailurereported:
PhysicalDisk0:
1:
6Controller0,Connector0
815:
Severity:
Non-Critical
816:
ID:
2094
817:
DateandTime:
2013-06-2403:
13:
33
818:
Category:
StorageService
819:
Description:
PredictiveFailurereported:
PhysicalDisk0:
1:
6Controller0,Connector0
821:
Severity:
Non-Critical
822:
ID:
2057
823:
DateandTime:
2013-06-2303:
05:
30
824:
Category:
StorageService
825:
Description:
Virtualdiskdegraded:
VirtualDisk2（VirtualDisk2）Controller0（PERCH710PMini）
833:
Severity:
Non-Critical
834:
ID:
2346
835:
DateandTime:
2013-06-2303:
05:
29
836:
Category:
StorageService
837:
Description:
Erroroccurred:
ErroronPD06（e0x20/s6）（Error02）.:
PhysicalDisk0:
1:
6Controller0,Connector0
839:
Severity:
Critical
840:
ID:
2048
841:
DateandTime:
2013-06-2303:
05:
29
842:
Category:
StorageService
843:
Description:
Devicefailed:
PhysicalDisk0:
1:
6Controller0,Connector0
845:
Severity:
Non-Critical
846:
ID:
2123
847:
DateandTime:
2013-06-2303:
05:
29
848:
Category:
StorageService
849:
Description:
Redundancylost:
VirtualDisk2（VirtualDisk2）Controller0（PERCH710PMini）
1001:
Severity:
Non-Critical
1002:
ID:
2094
1003:
DateandTime:
2013-06-2302:
55:
38
1004:
Category:
StorageService
1005:
Description:
PredictiveFailurereported:
PhysicalDisk0:
1:
6Controller0,Connector0
4.1.2主机硬件故障（不包含硬盘故障）下电维修流程。
1）判断维护时长，16小时以下维护转到3，16小时以上维护，转到2。
2）局方业务部门与上级主管部门协调可以开始维护，并报备。
3）制定维护方案，并设置紧急应对措施和回退方案。
4）局方系统维护人员与国信负责人确认可以开始维护。
5）通知使用人员停止使用。
6）停库。
7）关机（如果已故障关机此步骤可以省略）
8）实施维护。
如果发生超时风险，及时与局方业务部门协调启动紧急应对措施和回退方案。
9）开机。
10）启库。
11）确认功能正常。
12）通知人员离场。
4.2镜像维护流程
4.2.1确认当天数据加工任务已结束
4.2.2关闭数据库访问权限
cd/data/master/gpseg-1
cppg_hba.confpg_hba.conf_bak_当前日期
vipg_hba.conf把不希望连接上来的HOST注释掉保存
gpstop–u
4.2.2执行gpstate–e
上图表示有8个镜像需要修复
4.2.3执行gprecoverseg
执行过程中会出现打点的情况不要关闭连接，一般这个过程会很慢需要1个小时，并且结束后，还有修复任务在后台继续几个小时，修复过程中可以使用gpstate–e查看进度
4.2.4确认修复已进入收尾阶段
使用gpstate–e查看进度，当时度栏全部显示正常进度，没有0%的情况以后我们可以开启数据库的访问权限
4.2.5开启数据库访问权限
cd/data/master/gpseg-1
cppg_hba.conf_bak_当前日期pg_hba.conf
gpstop–u
4.2.6确认修复完毕
gpstate–e
上图表示镜像全部修复完毕修复流程到此结束
4.2.7注意是否存在镜像角色反转
如果上图所示表示有8个镜像存在镜像角色反转情况，需要修复，如果没有这种情况表示维护结束。
如果需要修复的话继续参照下面步骤进行
4.2.8重启数据库
gpstop-f
gpstart
4.2.9再次检查是否存在镜像角色反转
gpstate–e
有的版本会自动将反转现象恢复过来，但大多数仍然存在角色反转现象，需要手工执行命令转换回来。
***特别注意，在执行下面的这条gprecoverseg–r指令前务必先重启数据库。
参见４.２.８
gprecoverseg–r
***特别注意，在执行上面这这条gprecoverseg–r指令前务必先重启数据库。
参见４.２.８
如果业务运行中不允许重启，等可以重启时，再重启后运行
4.3疑难故障维护流程
拨打4006700009
按提示音输入3，5
SITEID：
4164233（联通总部的）
附件：
检查表
升级会员 