1、登录
应用程序可以使用Postgresql jdbc驱动包连接GreenPlum（GP）数据库，命令行登录GP：
写道
su - gpadmin
// psql -h 192.168.1.2 -d test -U user
psql -h ip -d dbname -U user
// psql -h 192.168.1.2 -d test -U user
psql -h ip -d dbname -U user
2、创建表
创建表模板如下，主要注意标红色的地方：
With：指定创建表时存储参数（列或行存储、是否压缩等）
Distribute：数据分布方式指定具体列（Hash或随机）
Partition：节点数据分区（按范转或列值分区）
With：指定创建表时存储参数（列或行存储、是否压缩等）
Distribute：数据分布方式指定具体列（Hash或随机）
Partition：节点数据分区（按范转或列值分区）
CREATE [[GLOBAL | LOCAL] {TEMPORARY | TEMP}] TABLE table_name(
[ { column_name data_type[ DEFAULT default_expr]
[column_constraint[ ... ]
[ ENCODING ( storage_directive[,...] ) ]
]
| table_constraint
| LIKE other_table[{INCLUDING | EXCLUDING}
{DEFAULTS | CONSTRAINTS}] ...}
[, ... ] ]
)
[ INHERITS ( parent_table[, ... ] ) ]
[ WITH ( storage_parameter=value[, ... ] )
[ ON COMMIT {PRESERVE ROWS | DELETE ROWS | DROP} ]
[ TABLESPACE tablespace]
[ DISTRIBUTED BY (column, [ ... ] ) | DISTRIBUTED RANDOMLY ]
[ PARTITION BY partition_type(column)
[ SUBPARTITION BY partition_type(column) ]
[ SUBPARTITION TEMPLATE ( template_spec ) ]
[...]
( partition_spec)
| [ SUBPARTITION BY partition_type(column) ]
[...]
( partition_spec
[ ( subpartition_spec
[(...)]
) ]
)
/**With下的存储参数如下*/
// true=列式存储 false=行式存储
APPENDONLY={TRUE|FALSE}
// 数据块大小
BLOCKSIZE={8192-2097152}
ORIENTATION={COLUMN|ROW}
CHECKSUM={TRUE|FALSE}
// 数据压缩类型
COMPRESSTYPE={ZLIB|QUICKLZ|RLE_TYPE|NONE}
// 数据存储压缩级别，查询时减少IO
COMPRESSLEVEL={1-9}
FILLFACTOR={10-100}
// 创建表时默认为false
OIDS[=TRUE|FALSE]
CREATE TABLE "public"."test" (
"user" varchar(15),
"namd" varchar(2),
"create" date,
"zt" NUMERIC(2)
)
WITH (orientation=column,appendonly=true,compresslevel=5)
distributed randomly
partition by range(create)
(
partition p201501 start ('2015-01-01'::date) end ('2015-02-01'::date),
partition p201502 start ('2015-02-01'::date) end ('2015-03-01'::date)
);
3、数据导入
实时数据写入慢，一般都是通过外部表、文件的方式将数据导入表。另外可能以通过Create table AS 或Insert into table query 数据非常快。
GP索引类型支持Btree、Bitmap
GP索引类型支持Btree、Bitmap
4、函数
GP为Postgresql升级过来的产品，大部份Postgresql函数在GP支持分析函数与窗口函数等
日期常用函数：to_date、to_char、date_part、date_truct
日期常用函数：to_date、to_char、date_part、date_truct
5、百亿级数据范围查询, 分组排序窗口取值 极致优化
6、distinct xx和count(distinct xx)的变态递归优化方法 写道
7、Postgresql资料大全 写道
注意项 写道
1）创建分区表后，再创建相关索引，执行统计分析或查询时不走索引？
先执行 anlysize table
2）采用ORACLE SQL预编译方法行不通（查询更慢），直接采用SQL并接查询效率更高
先执行 anlysize table
2）采用ORACLE SQL预编译方法行不通（查询更慢），直接采用SQL并接查询效率更高
8、添加分区 写道
ALTER TABLE <table> ADD PARTITION p201906 START ('2019-06-01'::date) INCLUSIVE END ('2015-07-01'::date) EXCLUSIVE;
ALTER TABLE <table> ADD PARTITION p201907 START ('2019-07-01'::date) INCLUSIVE END ('2015-08-01'::date) EXCLUSIVE;
ALTER TABLE <table> ADD PARTITION p201907 START ('2019-07-01'::date) INCLUSIVE END ('2015-08-01'::date) EXCLUSIVE;
9、集群节点角色异常 写道
// gp nodes status
select * from gp_segment_configuration order by 1;
// segment status
gpstate -s
// segment mill status
gpstate -m
//恢复方法
一、同步数据
1）同步下故障节点的数据,恢复原来架构
$>gprecoverseg
输入Y确认
【备注】重启故障主机（但是不会恢复原来架构）
二、切换角色
$>gprecoverseg –r
三、查看主备节点是否在同步数据
$>gpstate –e
//gp_configuration_history字典来查看数据库的切换信息
select * from gp_configuration_history
//重新启动
$>gpstop -r
select * from gp_segment_configuration order by 1;
// segment status
gpstate -s
// segment mill status
gpstate -m
//恢复方法
一、同步数据
1）同步下故障节点的数据,恢复原来架构
$>gprecoverseg
输入Y确认
【备注】重启故障主机（但是不会恢复原来架构）
二、切换角色
$>gprecoverseg –r
三、查看主备节点是否在同步数据
$>gpstate –e
//gp_configuration_history字典来查看数据库的切换信息
select * from gp_configuration_history
//重新启动
$>gpstop -r
10、删除分区表 写道
标准DML:
truncate 只删除数据；drop 删除表和数据
// 删除数据，但不删分区表
Alter table <主表名> truncate partition <partitionname>
// 如果创建分区时未指定分区名（分区表名！=分区名）
// 删除按范围分区的第1个分区（慎用）
Alter table <主表名> truncate partion for(rank(1))
// 删除数据表
Alter table <主表名> drop partition <partitionname>
Alter table <主表名> drop partition for(rank(1))
// 查看分区名
select * from pg_patitions where tablename=<主表>
truncate 只删除数据；drop 删除表和数据
// 删除数据，但不删分区表
Alter table <主表名> truncate partition <partitionname>
// 如果创建分区时未指定分区名（分区表名！=分区名）
// 删除按范围分区的第1个分区（慎用）
Alter table <主表名> truncate partion for(rank(1))
// 删除数据表
Alter table <主表名> drop partition <partitionname>
Alter table <主表名> drop partition for(rank(1))
// 查看分区名
select * from pg_patitions where tablename=<主表>
11、Linx Crontab调度 写道
1) 用户调度位置
/var/spool/cron/<user file>
2）系统调度位置
/etc/crontab
/var/spool/cron/<user file>
2）系统调度位置
/etc/crontab
写道
//======================常用命令=========================
$>su - gpadmin
增量更新
$>gprecoverseg
// 全部更新(慎用)
// 默认会将segment状态为'd'的mirror中base,pg_xlog清除
$>gprecoverseg -F
// 切换原始角色
$>gprecoverseg -r
// 停止启动
$>gpstop -M immediate
// 重启
$>gpstop -r
// 启动GP
$>gpstart
//查看segment状态
$>gpstate -m/-s/-e
// 查看error日志内容
$>gplogfilter -t
// 查询表的分区名称
// 分区表名!=分区名
select tablename,partitionname from pg_partitions where tablename='yp_passrec_area';
// 清除数据，只删除数据，不删除表
// 根据分区名，删除分区数据
#alter table yp_passrec_area truncate partition <partitionname>;
// 根据分范围排序，删除排列（有效分区,随分区数变化）在第1分区数据
#alter table yp_passrec_area truncate partition for(rank(1));
// 删除表
// 问题1：相应索引数据是否删除？？
#alter table yp_passrec_area drop partition for(rank(1)); //分区排序
#alter table yp_passrec_ydcp truncate partition for(rank(2));
// 用户级调度任务，root用户修改以用户命名的文件内容
[root@mdw1]$vim /var/spool/cron/hdfs
// 切换hdfs用户
[root@mdw1 psqlsh]$ su - hdfs
// 查看hdfs用户的调度任列表信息
[hdfs@mdw1 psqlsh]$ crontab -l
#oracle to greenplum
#*/5 * * * * /bin/bash /greenplum/import/kettle/kettle_58_v2/kitchen_oracle2gp_58_v2.sh hn_veh_passrec
#auto_delete_csv
30 1 * * * /greenplum/import/scripts/auto_delete_kettle_csv.sh
0 3 * * * /bin/bash /greenplum/import/kettle/kettle_ajxx/pan_oracle2gp_ajxx.sh
0 3 * * * /bin/bash /greenplum/import/kettle/kettle_jcjxx/pan_oracle2gp_jcjxx.sh
0 4 * * * /bin/bash /greenplum/import/kettle/kettle_dzwz/pan_oracle2gp_dzwz.sh
0 4 * * * /bin/bash /greenplum/import/kettle/kettle_vehicle/pan_oracle2gp_vehicle.sh
#gp_gcsj_predeal
0 1 * * * /greenplum/import/kettle/psqlsh/jm_veh_passrec_predeal.sh
0 1 * * * /greenplum/import/kettle/psqlsh/yp_passrec_ydcp_predeal.sh
*/10 * * * * /greenplum/import/kettle/psqlsh/yp_passrec_area_predeal.sh
*/5 * * * * /greenplum/import/ydbsynchelper/bin/ydb2greenplum.sh > /greenplum/import/ydbsynchelper/record.txt 2>&1
// 集群Segment down分析:
// psql -h <ip> -d <database> -U <user>
// 查询Segmeng状态表
jcbk=> select * from gp_segment_configuration where (status,mode) != ('u','s');
dbid | content | role | preferred_role | mode | status | port | hostname | address | replication_port | san_mounts
------+---------+------+----------------+------+--------+-------+----------+---------+------------------+------------
12 | 10 | p | p | c | u | 40000 | qbsdw6 | sdw6 | 41000 |
28 | 10 | m | m | r | d | 50000 | qbsdw7 | sdw7 | 51000 |
13 | 11 | p | p | c | u | 40001 | qbsdw6 | sdw6 | 41001 |
29 | 11 | m | m | r | d | 50001 | qbsdw7 | sdw7 | 51001 |
31 | 13 | p | m | c | u | 50001 | qbsdw8 | sdw8 | 51001 |
15 | 13 | m | p | r | d | 40001 | qbsdw7 | sdw7 | 41001 |
30 | 12 | p | m | c | u | 50000 | qbsdw8 | sdw8 | 51000 |
14 | 12 | m | p | r | d | 40000 | qbsdw7 | sdw7 | 41000 |
(8 rows)
// 查看GP segment
[gpadmin@mdw1 ~]$ gpstate -c
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:-Starting gpstate with args: -c
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:-local Greenplum Version: 'postgres (Greenplum Database) 4.3.8.1 build 1'
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:-master Greenplum Version: 'PostgreSQL 8.2.15 (Greenplum Database 4.3.8.1 build 1) on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.4.2 compiled on Apr 20 2016 08:08:56'
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:-Obtaining Segment details from master...
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:--------------------------------------------------------------
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:--Current GPDB mirror list and status
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:--Type = Group
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:--------------------------------------------------------------
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Status Data State Primary Datadir Port Mirror Datadir Port
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw1 /greenplum/primary1/gpseg0 40000 sdw2 /greenplum/mirror1/gpseg0 50000
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw1 /greenplum/primary2/gpseg1 40001 sdw2 /greenplum/mirror2/gpseg1 50001
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw2 /greenplum/primary1/gpseg2 40000 sdw3 /greenplum/mirror1/gpseg2 50000
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw2 /greenplum/primary2/gpseg3 40001 sdw3 /greenplum/mirror2/gpseg3 50001
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw3 /greenplum/primary1/gpseg4 40000 sdw4 /greenplum/mirror1/gpseg4 50000
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw3 /greenplum/primary2/gpseg5 40001 sdw4 /greenplum/mirror2/gpseg5 50001
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw4 /greenplum/primary1/gpseg6 40000 sdw5 /greenplum/mirror1/gpseg6 50000
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw4 /greenplum/primary2/gpseg7 40001 sdw5 /greenplum/mirror2/gpseg7 50001
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw5 /greenplum/primary1/gpseg8 40000 sdw6 /greenplum/mirror1/gpseg8 50000
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw5 /greenplum/primary2/gpseg9 40001 sdw6 /greenplum/mirror2/gpseg9 50001
// 存在问题
// 1）Primary Active, Mirror Failed 主segment正常，镜像失败
// 2）Mirror Active, Primary Failed 主segment失败，镜像激活有效
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[WARNING]:-Primary Active, Mirror Failed Change Tracking sdw6 /greenplum/primary1/gpseg10 40000 sdw7 /greenplum/mirror1/gpseg10 50000 <<<<<<<<
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[WARNING]:-Primary Active, Mirror Failed Change Tracking sdw6 /greenplum/primary2/gpseg11 40001 sdw7 /greenplum/mirror2/gpseg11 50001 <<<<<<<<
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[WARNING]:-Mirror Active, Primary Failed Change Tracking sdw7 /greenplum/primary1/gpseg12 40000 sdw8 /greenplum/mirror1/gpseg12 50000 <<<<<<<<
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[WARNING]:-Mirror Active, Primary Failed Change Tracking sdw7 /greenplum/primary2/gpseg13 40001 sdw8 /greenplum/mirror2/gpseg13 50001 <<<<<<<<
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw8 /greenplum/primary1/gpseg14 40000 sdw1 /greenplum/mirror1/gpseg14 50000
// 1）主要sdw7服务器节点内容segment10、segment11 镜像复本down掉，数据无法从sdw6节点
// 同步数据;
// 2）sdw7节点服务器上segment12、segment13 的主本down掉，由在sdw8节点相应的镜像复本
// 升级主本;
// 3）针对sdw7网络测试pring sdw7(172段万兆网，10.142段千兆网)，存在分片组合超时异常
// 其它服务器上执行：ping sdw7 -s 6550
// 4）查看网卡ifconfig eth0，存在RX error,frame等错信息
// 5）查看节点sdw7、sdw6、sdw8节点I/O,CPU等情况（将数据同步、预处理关闭），
// 执行iostat -d -x -k 3，磁盘读写很少，也不存在I/O等待
// 6）执行GP同步程序gprecoverseg（增量同步，加-F参数为全量同步）后，通过gpstate -e
// 查看同步进度，待同步数据8G，同步进基本只0.04%左右
// 查看待同步mirror节点下的gp_log文件，存在gp_segment_connection_timeout或者EOF
// 错误信息
节点sdw7 segment 10 副本同步失败,掉线; primary节点sdw6
sdw7 mirror down not syncing----> sdw6 primary primary change tracking
节点sdw7 segment 11 副本同步失败,掉线; primary节点sdw6
sdw7 mirror down not syncing-----> sdw6 primary primary change tracking
节点sdw7 segment 12 主本下线---> 节点 sdw8 副本启动
sdw7 primary down not syncing ----> sdw8 m-->p up change tracking
节点sdw7 segment 13 主本下线---->节点 sdw8 副本启动
sdw7 primary down not syncing ----> sdw8 m-->p up change tracking
//===========================================================
GP error:
2019-09-26 08:35:30.489490 CST,"hdfs","jcbk",p17854,th-1279940832,"[local]",,2019-09-26 08:35:04 CST,43223421,con12979,cmd60,seg-1,,dx31936,x43223421,sx1,"ERROR","22M01","no partition for partitioning key",,,,,"COPY hn_veh_passrec, line 749: ""431500100380,1,2019-09-26 08:25:54,2010-08-17 16:09:44,430000201117507245,1,02,湘F996Z8,2,0,62,,,K3...""","COPY hn_veh_passrec ( kkbh,cdh,rksj,gcsj,gcxh,fxlx,hpzl,hphm,hpys,cwkc,clsd,csys,clpp,cllx,fzhpzl,fzhphm,fzhpys,tplj,tp1,tp2,tp3,byzd,tztp,drtp1,drtp2,fsbz,clwx,xszt,wfbj,clxs,cwhphm,cwhpys,hpyz,cdlx,yrksj ) FROM '/greenplum/import/data/ydb_export/20190926/ydb_t_vs_tracks_20190926083501896_f315ed71-7f3e-4758-bcd0-8610bdae238f/part-r-00059-a83cf281-38ad-49b1-85ff-95c9f166dc2e' WITH CSV DELIMITER E',' ;",0,,"execMain.c",4070,
$>nc -v sdw7 51001
// ==============集群恢复============
// 1）因segment 掉线，执行gprecoverseg同步失败导致集群启动不了，
// 其它情况需要分析具体日志错误
$>su - gpadmin
// 只启动维护模式
$>gpstart -m
// 登录GP
$>PGOPTIONS='-c gp_session_role=utility' psql -d postgres
// 配置表操作模式
$>set allow_system_table_mods='dml';
// 配置segment原状态，绕过GP启动检查（当有Segment被标记为’d’后，Master将不会对其
// 做处理，GP实例的启动（重启）也会将其忽略）
// 对比gpstate -s 与 gp_segment_configuration状态是否一致
// 执行gprecoverseg前，提前备份表gp_segment_configuration
#psql>update gp_segment_configuration set mode='c' where dbid=31;
#psql>update gp_segment_configuration set status='d' where dbid=15;
//===================常见问题解决==========================
问题一：启动时提示，GP segment 启动成功，但是数据库无法启动
1）执行gpstate -s 查看各个segment状态，如下所示
gpstate:mdw-:gpadmin-[INFO]:- Segment Info
gpstate:mdw-:gpadmin-[INFO]:- Hostname = sdw-
gpstate:mdw-:gpadmin-[INFO]:- Address = sdw-
gpstate:mdw-:gpadmin-[INFO]:- Datadir = /gpadmin/data/primary/gpseg0
gpstate:mdw-:gpadmin-[INFO]:- Port =
gpstate:mdw-:gpadmin-[INFO]:- Mirroring Info
gpstate:mdw-:gpadmin-[INFO]:- Current role = Mirror
gpstate:mdw-:gpadmin-[INFO]:- Preferred role = Primary
gpstate:mdw-:gpadmin-[INFO]:- Mirror status = Resynchronizing
gpstate:mdw-:gpadmin-[INFO]:- Status
gpstate:mdw-:gpadmin-[INFO]:- PID =
//gp_segment_configuration配置此segment 状态为 up;
//segment status= Down
gpstate:mdw-:gpadmin-[INFO]:- Configuration reports status as = Up
gpstate:mdw-:gpadmin-[WARNING]:- Segment status = Down
2）停止gp,执行gpstart -m 只启动维护模式
连接数据库:
$>PGOPTIONS='-c gp_session_role=utility' psql -d postgres
$>set allow_system_table_mods='dml';
修改相应表gp_segment_configuration表中相应segment 的配置状态，上述修改为 Down即可启动
3）重新启动gp集群
问题2：执行recoverseg -r 前需要保证所有segment都是正常，才能生效
问题3：执行recoverseg mirror<->primary 同步数据期间经常断
1）检查网络是否正常
2）检查磁盘是否满或者写入性能
3）检查相应segment所有服务器日志
提示gp_segment_connect_timeout,同时存在警告../base/12323 文件或者目录不存在
分析可以存在上一次数据同步期间，文件丢失
4）执行recoverseg -F只能针对存在问题segment 执行全量同步
//===================日常巡检==========================
巡检频率：每天
巡检过程：1）查看GP console 控制台是否存在segment掉线
2）查看每个节点磁盘空间（数据盘、系统盘），达到90%以上时，及时的馈
3）如果存在segment掉线，检查掉线服务器网络
执行ping <主机名> -s 6550，如ping sdw7 -s 6550(必须是172段)
//===================GP 目录==========================
gp 数据目录中最重要有3个目录：
1）base：数据（包括基础元数据）
2）pg_xlog：事务日志
3) pg_log: 日志
//===================gpstate -s 参数说明=============
[备注]primary所在的segment才有database status
//====================================================
// h表示heap 行存储表
//c表示append only column 存储表
//a表示表示append only 行存储表
select relname, relkind, relstorage from pg_class where relkind='r';
// 资源
http://mysql.taobao.org/monthly/2016/04/03/
$>su - gpadmin
增量更新
$>gprecoverseg
// 全部更新(慎用)
// 默认会将segment状态为'd'的mirror中base,pg_xlog清除
$>gprecoverseg -F
// 切换原始角色
$>gprecoverseg -r
// 停止启动
$>gpstop -M immediate
// 重启
$>gpstop -r
// 启动GP
$>gpstart
//查看segment状态
$>gpstate -m/-s/-e
// 查看error日志内容
$>gplogfilter -t
// 查询表的分区名称
// 分区表名!=分区名
select tablename,partitionname from pg_partitions where tablename='yp_passrec_area';
// 清除数据，只删除数据，不删除表
// 根据分区名，删除分区数据
#alter table yp_passrec_area truncate partition <partitionname>;
// 根据分范围排序，删除排列（有效分区,随分区数变化）在第1分区数据
#alter table yp_passrec_area truncate partition for(rank(1));
// 删除表
// 问题1：相应索引数据是否删除？？
#alter table yp_passrec_area drop partition for(rank(1)); //分区排序
#alter table yp_passrec_ydcp truncate partition for(rank(2));
// 用户级调度任务，root用户修改以用户命名的文件内容
[root@mdw1]$vim /var/spool/cron/hdfs
// 切换hdfs用户
[root@mdw1 psqlsh]$ su - hdfs
// 查看hdfs用户的调度任列表信息
[hdfs@mdw1 psqlsh]$ crontab -l
#oracle to greenplum
#*/5 * * * * /bin/bash /greenplum/import/kettle/kettle_58_v2/kitchen_oracle2gp_58_v2.sh hn_veh_passrec
#auto_delete_csv
30 1 * * * /greenplum/import/scripts/auto_delete_kettle_csv.sh
0 3 * * * /bin/bash /greenplum/import/kettle/kettle_ajxx/pan_oracle2gp_ajxx.sh
0 3 * * * /bin/bash /greenplum/import/kettle/kettle_jcjxx/pan_oracle2gp_jcjxx.sh
0 4 * * * /bin/bash /greenplum/import/kettle/kettle_dzwz/pan_oracle2gp_dzwz.sh
0 4 * * * /bin/bash /greenplum/import/kettle/kettle_vehicle/pan_oracle2gp_vehicle.sh
#gp_gcsj_predeal
0 1 * * * /greenplum/import/kettle/psqlsh/jm_veh_passrec_predeal.sh
0 1 * * * /greenplum/import/kettle/psqlsh/yp_passrec_ydcp_predeal.sh
*/10 * * * * /greenplum/import/kettle/psqlsh/yp_passrec_area_predeal.sh
*/5 * * * * /greenplum/import/ydbsynchelper/bin/ydb2greenplum.sh > /greenplum/import/ydbsynchelper/record.txt 2>&1
// 集群Segment down分析:
// psql -h <ip> -d <database> -U <user>
// 查询Segmeng状态表
jcbk=> select * from gp_segment_configuration where (status,mode) != ('u','s');
dbid | content | role | preferred_role | mode | status | port | hostname | address | replication_port | san_mounts
------+---------+------+----------------+------+--------+-------+----------+---------+------------------+------------
12 | 10 | p | p | c | u | 40000 | qbsdw6 | sdw6 | 41000 |
28 | 10 | m | m | r | d | 50000 | qbsdw7 | sdw7 | 51000 |
13 | 11 | p | p | c | u | 40001 | qbsdw6 | sdw6 | 41001 |
29 | 11 | m | m | r | d | 50001 | qbsdw7 | sdw7 | 51001 |
31 | 13 | p | m | c | u | 50001 | qbsdw8 | sdw8 | 51001 |
15 | 13 | m | p | r | d | 40001 | qbsdw7 | sdw7 | 41001 |
30 | 12 | p | m | c | u | 50000 | qbsdw8 | sdw8 | 51000 |
14 | 12 | m | p | r | d | 40000 | qbsdw7 | sdw7 | 41000 |
(8 rows)
// 查看GP segment
[gpadmin@mdw1 ~]$ gpstate -c
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:-Starting gpstate with args: -c
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:-local Greenplum Version: 'postgres (Greenplum Database) 4.3.8.1 build 1'
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:-master Greenplum Version: 'PostgreSQL 8.2.15 (Greenplum Database 4.3.8.1 build 1) on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.4.2 compiled on Apr 20 2016 08:08:56'
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:-Obtaining Segment details from master...
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:--------------------------------------------------------------
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:--Current GPDB mirror list and status
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:--Type = Group
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:--------------------------------------------------------------
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Status Data State Primary Datadir Port Mirror Datadir Port
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw1 /greenplum/primary1/gpseg0 40000 sdw2 /greenplum/mirror1/gpseg0 50000
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw1 /greenplum/primary2/gpseg1 40001 sdw2 /greenplum/mirror2/gpseg1 50001
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw2 /greenplum/primary1/gpseg2 40000 sdw3 /greenplum/mirror1/gpseg2 50000
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw2 /greenplum/primary2/gpseg3 40001 sdw3 /greenplum/mirror2/gpseg3 50001
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw3 /greenplum/primary1/gpseg4 40000 sdw4 /greenplum/mirror1/gpseg4 50000
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw3 /greenplum/primary2/gpseg5 40001 sdw4 /greenplum/mirror2/gpseg5 50001
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw4 /greenplum/primary1/gpseg6 40000 sdw5 /greenplum/mirror1/gpseg6 50000
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw4 /greenplum/primary2/gpseg7 40001 sdw5 /greenplum/mirror2/gpseg7 50001
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw5 /greenplum/primary1/gpseg8 40000 sdw6 /greenplum/mirror1/gpseg8 50000
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw5 /greenplum/primary2/gpseg9 40001 sdw6 /greenplum/mirror2/gpseg9 50001
// 存在问题
// 1）Primary Active, Mirror Failed 主segment正常，镜像失败
// 2）Mirror Active, Primary Failed 主segment失败，镜像激活有效
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[WARNING]:-Primary Active, Mirror Failed Change Tracking sdw6 /greenplum/primary1/gpseg10 40000 sdw7 /greenplum/mirror1/gpseg10 50000 <<<<<<<<
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[WARNING]:-Primary Active, Mirror Failed Change Tracking sdw6 /greenplum/primary2/gpseg11 40001 sdw7 /greenplum/mirror2/gpseg11 50001 <<<<<<<<
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[WARNING]:-Mirror Active, Primary Failed Change Tracking sdw7 /greenplum/primary1/gpseg12 40000 sdw8 /greenplum/mirror1/gpseg12 50000 <<<<<<<<
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[WARNING]:-Mirror Active, Primary Failed Change Tracking sdw7 /greenplum/primary2/gpseg13 40001 sdw8 /greenplum/mirror2/gpseg13 50001 <<<<<<<<
20190925:16:40:31:007376 gpstate:mdw1:gpadmin-[INFO]:- Primary Active, Mirror Available Synchronized sdw8 /greenplum/primary1/gpseg14 40000 sdw1 /greenplum/mirror1/gpseg14 50000
// 1）主要sdw7服务器节点内容segment10、segment11 镜像复本down掉，数据无法从sdw6节点
// 同步数据;
// 2）sdw7节点服务器上segment12、segment13 的主本down掉，由在sdw8节点相应的镜像复本
// 升级主本;
// 3）针对sdw7网络测试pring sdw7(172段万兆网，10.142段千兆网)，存在分片组合超时异常
// 其它服务器上执行：ping sdw7 -s 6550
// 4）查看网卡ifconfig eth0，存在RX error,frame等错信息
// 5）查看节点sdw7、sdw6、sdw8节点I/O,CPU等情况（将数据同步、预处理关闭），
// 执行iostat -d -x -k 3，磁盘读写很少，也不存在I/O等待
// 6）执行GP同步程序gprecoverseg（增量同步，加-F参数为全量同步）后，通过gpstate -e
// 查看同步进度，待同步数据8G，同步进基本只0.04%左右
// 查看待同步mirror节点下的gp_log文件，存在gp_segment_connection_timeout或者EOF
// 错误信息
节点sdw7 segment 10 副本同步失败,掉线; primary节点sdw6
sdw7 mirror down not syncing----> sdw6 primary primary change tracking
节点sdw7 segment 11 副本同步失败,掉线; primary节点sdw6
sdw7 mirror down not syncing-----> sdw6 primary primary change tracking
节点sdw7 segment 12 主本下线---> 节点 sdw8 副本启动
sdw7 primary down not syncing ----> sdw8 m-->p up change tracking
节点sdw7 segment 13 主本下线---->节点 sdw8 副本启动
sdw7 primary down not syncing ----> sdw8 m-->p up change tracking
//===========================================================
GP error:
2019-09-26 08:35:30.489490 CST,"hdfs","jcbk",p17854,th-1279940832,"[local]",,2019-09-26 08:35:04 CST,43223421,con12979,cmd60,seg-1,,dx31936,x43223421,sx1,"ERROR","22M01","no partition for partitioning key",,,,,"COPY hn_veh_passrec, line 749: ""431500100380,1,2019-09-26 08:25:54,2010-08-17 16:09:44,430000201117507245,1,02,湘F996Z8,2,0,62,,,K3...""","COPY hn_veh_passrec ( kkbh,cdh,rksj,gcsj,gcxh,fxlx,hpzl,hphm,hpys,cwkc,clsd,csys,clpp,cllx,fzhpzl,fzhphm,fzhpys,tplj,tp1,tp2,tp3,byzd,tztp,drtp1,drtp2,fsbz,clwx,xszt,wfbj,clxs,cwhphm,cwhpys,hpyz,cdlx,yrksj ) FROM '/greenplum/import/data/ydb_export/20190926/ydb_t_vs_tracks_20190926083501896_f315ed71-7f3e-4758-bcd0-8610bdae238f/part-r-00059-a83cf281-38ad-49b1-85ff-95c9f166dc2e' WITH CSV DELIMITER E',' ;",0,,"execMain.c",4070,
$>nc -v sdw7 51001
// ==============集群恢复============
// 1）因segment 掉线，执行gprecoverseg同步失败导致集群启动不了，
// 其它情况需要分析具体日志错误
$>su - gpadmin
// 只启动维护模式
$>gpstart -m
// 登录GP
$>PGOPTIONS='-c gp_session_role=utility' psql -d postgres
// 配置表操作模式
$>set allow_system_table_mods='dml';
// 配置segment原状态，绕过GP启动检查（当有Segment被标记为’d’后，Master将不会对其
// 做处理，GP实例的启动（重启）也会将其忽略）
// 对比gpstate -s 与 gp_segment_configuration状态是否一致
// 执行gprecoverseg前，提前备份表gp_segment_configuration
#psql>update gp_segment_configuration set mode='c' where dbid=31;
#psql>update gp_segment_configuration set status='d' where dbid=15;
//===================常见问题解决==========================
问题一：启动时提示，GP segment 启动成功，但是数据库无法启动
1）执行gpstate -s 查看各个segment状态，如下所示
gpstate:mdw-:gpadmin-[INFO]:- Segment Info
gpstate:mdw-:gpadmin-[INFO]:- Hostname = sdw-
gpstate:mdw-:gpadmin-[INFO]:- Address = sdw-
gpstate:mdw-:gpadmin-[INFO]:- Datadir = /gpadmin/data/primary/gpseg0
gpstate:mdw-:gpadmin-[INFO]:- Port =
gpstate:mdw-:gpadmin-[INFO]:- Mirroring Info
gpstate:mdw-:gpadmin-[INFO]:- Current role = Mirror
gpstate:mdw-:gpadmin-[INFO]:- Preferred role = Primary
gpstate:mdw-:gpadmin-[INFO]:- Mirror status = Resynchronizing
gpstate:mdw-:gpadmin-[INFO]:- Status
gpstate:mdw-:gpadmin-[INFO]:- PID =
//gp_segment_configuration配置此segment 状态为 up;
//segment status= Down
gpstate:mdw-:gpadmin-[INFO]:- Configuration reports status as = Up
gpstate:mdw-:gpadmin-[WARNING]:- Segment status = Down
2）停止gp,执行gpstart -m 只启动维护模式
连接数据库:
$>PGOPTIONS='-c gp_session_role=utility' psql -d postgres
$>set allow_system_table_mods='dml';
修改相应表gp_segment_configuration表中相应segment 的配置状态，上述修改为 Down即可启动
3）重新启动gp集群
问题2：执行recoverseg -r 前需要保证所有segment都是正常，才能生效
问题3：执行recoverseg mirror<->primary 同步数据期间经常断
1）检查网络是否正常
2）检查磁盘是否满或者写入性能
3）检查相应segment所有服务器日志
提示gp_segment_connect_timeout,同时存在警告../base/12323 文件或者目录不存在
分析可以存在上一次数据同步期间，文件丢失
4）执行recoverseg -F只能针对存在问题segment 执行全量同步
//===================日常巡检==========================
巡检频率：每天
巡检过程：1）查看GP console 控制台是否存在segment掉线
2）查看每个节点磁盘空间（数据盘、系统盘），达到90%以上时，及时的馈
3）如果存在segment掉线，检查掉线服务器网络
执行ping <主机名> -s 6550，如ping sdw7 -s 6550(必须是172段)
//===================GP 目录==========================
gp 数据目录中最重要有3个目录：
1）base：数据（包括基础元数据）
2）pg_xlog：事务日志
3) pg_log: 日志
//===================gpstate -s 参数说明=============
[备注]primary所在的segment才有database status
//====================================================
// h表示heap 行存储表
//c表示append only column 存储表
//a表示表示append only 行存储表
select relname, relkind, relstorage from pg_class where relkind='r';
// 资源
http://mysql.taobao.org/monthly/2016/04/03/
相关推荐
很完整，做项目的时候就是看的这个很完整，做项目的时候就是看的这个
Greenplum两阶段事务源码分析，本ppt主要讲述了整个greenplum的两阶段事务的状态切换、调用流程和日志类型。
7、支持内存处理数据导入greenplum,导入失败生成csv格式文件，方便排错 8、支持生成csv格式文件导入greenplum。 9、传递不同配置文件，多次执行达到并行处理（注意内存溢出） 例： 执行脚本 生成日志目录 配置文件 ...
基于Greenplum的城轨信号系统车载日志大数据分析平台.pdf
在项目过程中,总结的一些关于gp程序的开发相关的内容,包括gp的特性,详细的gp语法,格式,开发规范,注释,日志等等.并有一些实际的例子.
Bireme使用DELETE + COPY将数据源的修改记录同步到Greenplum / HashData。 此模式比INSERT + UPDATE + DELETE更快更好。 功能和限制： 使用小批量加载来增强数据同步的性能。 默认的加载延迟时间是10秒。 所有表...
PostgreSQL -> PostgreSQL/Greenplum pgsql2gp功能：基于 PostgreSQL 逻辑日志的增量数据同步状态：未开发完成4. MySQL -> PostgreSQL/Greenplum mysql2pgsql功能：以表为单位的多线程全量数据迁移状态：已开源 ...
HBase 案例分析 MapReduce 高阶实现 MapReduce 多语言编程 Chukwa 集群监控系统 Greenplum 架构 Flume 日志收集系统 视频教程 应有尽有
HBase 案例分析 MapReduce 高阶实现 MapReduce 多语言编程 Chukwa 集群监控系统 Greenplum 架构 Flume 日志收集系统 视频教程 应有尽有
王硕－瀚高软件－PostgreSQL WAL日志解析与应用.pdf 德哥－阿里云－PostgreSQL前世今生.pdf 叶金荣－知数堂－抽丝剥茧之MySQL疑难杂症排查.pdf 德哥－阿里云－sharding单元化（based on postgres_fdw)最佳实践.pdf ...
逻辑架构 实现技术 对称多处理器(SMP) 基本所有商业数据库都支持 Sharing Nothing架构(多分区数据库) DB2 DPF 、TeraData、Greenplum、Netezza Share Disk架构(共享磁盘) DB2 pureScale、Oracle RAC Sharing ...
1 序 2 思想篇 2 CAP 2 最终一致性 2 变体 2 BASE 2 其他 2 I/O的五分钟法则 2 不要删除数据 ...5 使用 Map/Reduce 处理汇聚 5 基于磁盘的和内存中的实现 5 仅仅是炒作? 6 附 6 感谢 6 版本志 6 引用
大数据系统上的TPC-H 1. TPC- H 主要目的是评价特定查询的决策支持能力，强调服务器在数据挖掘、分析处理方面的能力。...（3）执行查询(Q1-Q22,有现成的案例，如在上的，spark上的)，这里可以使用脚本，将日志保
比如使用hadoop做日志存储和挖掘，可以参考百度上面的配置。如果是作为HBase的底层存储，并且有大量的随机查询，那么使用SAS硬盘，甚至SSD都是可以的。不同的业务需要不同类型的配置。即使同一个业务，也可能需要...
Flume 数据采集工具 Sqoop 数据ETL工具 ElasticSearch 搜索系统 Logstash 日志采集工具 Kibana 数据展现工具 Ranger 集中安全管理工具 Atlas 数据治理和元数据管理框架 kettle ETL工具 mongodb Key-value数据库 ...