一、介绍
GreenPlum是Coodinator/Segment架构,集群通常由一个Coodinator节点和一个standby coodinator节点以及多个segment节点组成,其中数据放置在segment节点上。Coodinator是整个数据库的入口,客户端只会连接到Coodinator上并执行相关查询操作,Standby节点为Coordinator提供高可用支持,Mirror为primary的备。
数据默认使用hash分布。
二、插入时数据是如何分布分发到哪个segment?
1、插入操作时值的由来
我们看下insert语句的执行计划:
它没有Motion节点,仅1个slice,即root slice。Result节点是将insert的值物化以构建TupleTableSlot进行插入。也就是先物化然后insert。
这里主要关注物化的值从哪来。Result节点的执行堆栈为:
ExecutorRun->standard_ExecutorRun->ExecutePlan-> ExecProcNode->ExecProcNodeFirst->ExecProcNodeGPDB-> ExecResult-> ExecProject->ExecEvalExprSwitchContext->ExecInterpExprStillvalid ->ExecInterpExpr
ExecInterpExpr计算物化值步骤:EEOP_CONST;EEOP_ASSIGN_TMP。也就是得到个常量值放到resultslot中。
通过gdb跟踪每个segment进程,可以了解到这里的常量值就是INSERT语句中VALUES的值。
此时就可以了解到,SQL语句中VALUES值是直接发送到对于的segment的。
那么,具体是如何发送的呢?
2、值的发送
发送函数由cdbdisp_dispatchX完成。我们来跟踪这个函数,看下是如何分发到指定的segment的。
了解GP原理的话,我们知道发送前需要先在master和segment之间建立一个连接,然后将执行计划通过这个连接发送过去。建立连接就是创建Gang,由函数AssignGangs完成。
AssignGangs AssignWriterGangFirst(ds, sliceTable, rootIdx); slice->primaryGang = AllocateGang(ds, slice->gangType, slice->segments); newGang = cdbgang_createGang(segments, segmentType); cdbgang_createGang_async
最终创建Gang建立连接会调用函数cdbgang_createGang_async。下面我们看下这个函数是如何建立连接的。
堆栈:
size = list_length(segments); newGangDefinition = buildGangDefinition(segments, segmentType); segdbDesc = newGangDefinition->db_descriptors[i]; ret = build_gpqeid_param(gpqeid, sizeof(gpqeid), segdbDesc->isWriter, segdbDesc->identifier, segdbDesc->segment_database_info->hostSegs, totalSegs * 2); cdbconn_doConnectStart(segdbDesc, gpqeid, options, diff_options);//建立连接
cdbconn_doConnectStart连接时,SegmentDatabaseDescriptor segdbDesc中的segment_database_info::GpSegConfigEntry存有segment的端口及IP等信息,即gp_segment_configuration系统表中内容。基于此信息,可以建立连接。
那么segdbDesc内容从何而来?
从上述堆栈,segdbDesc是Gang中的db_descriptors[i],也就是buildGangDefinition函数生成:
buildGangDefinition(List *segments, SegmentType segmentType) foreach_with_count (lc, segments , i){ contentId = lfirst_int(lc); newGangDefinition->db_descriptors[i] = cdbcomponent_allocateIdleQE(contentId, segmentType); }
SliceTable.slices[0].segments为入参segments链表,存储着执行该slice的所有segment的content id。segdbDesc是根据content id从系统表gp_segment_config来获取。
到这里可以知道,通过SliceTable中的segment链表得到该slice的segment的content。Insert仅一个slice,insert分发到执行该insert的segment,content就是该segment的content id。通过该content id从gp_segment_configuration系统表中得到相关port、IP等信息,从而据此在master和segment之间建立连接。构建链接后,insert语句通过此链接发送到对应的segment。
那么content id又是如何与分布键联系起来呢?
经过分析,由函数DirectDispatchUpdateContentIdsForInsert来完成映射:
constvalue为分布键的key值,然后通过cdbhash函数通过系统hash函数将key值进行hash,最终得到hashcode,该值即为content id,放到contentIds链表中。
三、基础知识
1、gp_segment_configuration
dbid |
唯一标识segment。Master为1,然后primary节点按照content递增;接着是mirror按照content递增;最后是standby master |
content |
数据库节点的标识ID,segment的primary和mirror相同。Master节点为-1,数据节点:0-N |
role |
节点当前的角色,primary或者mirror。p:表示primary,m:表示mirror |
preferred_role |
节点被定义的角色,primary或者mirror |
mode |
主备同步状态。s:表示已同步;n:表示不同步 Master总是n,standby master segment总是s,但并不表示他们之间的同步状态,使用gp_stat_replication来看他们之间是否同步 |
status |
u:表示正常,d:表示节点失败 |
port |
子节点的端口 |
hostname |
子节点所在机器的hostname |
address |
子节点所在机器的IP |
datadir |
实例的data目录 |
2、Gang、slice与QueryDesc之间关系