Postgres XL包含3个主要的组件:GTM, Coordinator和Datanode.
GTM负责提供事务的ACID特性。
Datanode在本地存储表数据,和处理SQL语句。
Coordinator处理从Applications来的每个SQL语句,决定到哪个datanode去执行,并且发送执行计划到对应的datanode。
通常GTM需要运行在一个独立的server,因为GTM需要处理从所有的coordinator和datanode来的事务请求。为了减少数据交互,将来自同一个server的coordinator和datanode的请求和响应分到同一个组,可以通过配置GTM-proxy来实现,GTM-proxy实际上是一个代理,coordinator和datanode本来是直接连接GTM的,可以将多个Coordinator分组,每组一个GTM-proxy,coordinator与GTM-proxy相连,GTM-proxy通过批量发送请求(类似于聚合请求,减少请求次数)减少了到GTM的交互次数和数据量。GTM-proxy也帮助处理GTM节点失效的情况。
GTM一旦故障,整个集群立刻无法访问,此时可以切换到GTM Standby节点上。如果部署了GTM Standby节点,就应该同时部署GTM Proxy,一般和Coordinator、Datanode部署在同一台服务器上。GTM Proxy的作用代理Coordinator和Datanode对GTM的访问,起到减轻GTM负载的作用,另外一个重要的作用是帮助完成GTM的故障切换,当GTM节点发生故障后,GTM Standby成为新的GTM,此时Coordinator和Datanode节点并不需要重新指定GTM地址,只需要GTM Proxy重新连接到新的GTM地址即可。
比较好的做法就是将datanode和coordinator组件跑在同一个server上面,这样就不用担心二者间的负载均衡的问题,可以从本地的复制表来获取数据,不用发送请求到网络上。可以在多个server上运行datanode和coordinator组件组,datanode和coordinator组件本质上都是PostgresSQL实例,配置时需要配置不同的工作目录和端口以避免冲突。
coordinator不存储用户数据,它仅存储catalog数据,用来决定如何处理statements, 去那个datanode执行,并为每个datanode产生本地的SQL statements。故不需担心coordinator组件失效,直接切换到另外一个就可以。coordinator接收数据访问请求的节点,本质上是由PG后台进程组成。接收的一条查询后,Coordinator节点执行查询计划,然后会根据查询数据涉及的数据节点将查询分发给相关的数据节点。写入数据时,也会根据不同的数据分布策略将数据写入相关的节点。可以说Coordinator节点上保存着集群的全局数据位置。Coordinator节点可以任意扩展,各个节点之间除了访问地址不同以外是完全对等的,通过一个节点更新的数据可以在另一个节点上立刻看到。每个Coordinator节点可以配置一个对应的standby节点,避免单点故障。
Datanode是实际存取数据的节点,接收Coordinator的请求并执行SQL语句存取数据,节点之间也会互相通信。一般的,一个节点上的数据并不是全局的,数据节点不直接对外提供数据访问。一个表的数据在数据节点上的分布存在两种模式:复制模式和分片模式,复制模式下,一个表的数据在指定的节点上存在多个副本;分片模式下,一个表的数据按照一定的规则分布在多个数据节点上,这些节点共同保存一份完整的数据。这两种模式的选择是在创建表的时候执行CREATE TABLE语句指定的,具体语法如下:
CREATE TABLE table_name(...)
DISTRIBUTE BY
HASH(col)|MODULO(col)|ROUNDROBIN|REPLICATION
TO NODE(nodename1,nodename2...)
可以看到,如果DISTRIBUTE BY 后面是REPLICATION,则是复制模式,其余则是分片模式,HASH指的是按照指定列的哈希值分布数据,MODULO指的是按照指定列的取摩运算分布数据,ROUNDROBIN指的是按照轮询的方式分布数据。TO NODE指定了数据分布的节点范围,如果没有指定则默认所有数据节点参与数据分布。如果没有指定分布模式,即使用普通的CREATE TABLE语句,PGXL会默认采用分片模式将数据分布到所有数据节点。
GTM是一个失效单点所在,可以通过配置GTM-slave来备份GTM的状态,当GTM失效时,GTM-proxy可以切换到slave节点。
整个集群由GTM、GTM-Proxy、Coordinator、Datanode组成。
GTM(Gloable Transaction Manager)负责提供事务的ACID属性;
Datanode负责存储表的数据和本地执行由Coordinator派发的SQL任务;
Coordinator负责处理每个来自Application的SQL任务,并且决定由哪个Datanode执行,然后将任务计划派发给相应的Datanode,根据需要收集结果返还给Application;
GTM通常由一台独立的服务器承担,GTM需要处理来自所有GTM-Proxy或者Coordinator和Datanode的事务请求。
每台机器最好同时配置一个Coordinator、一个Datanode与GTM-Proxy。
每台机器同时配置一个Coordinator和一个Datanode,可以负载均衡,同时降低网络流量。GTM-Proxy会减少GTM的负载,将Coordinator和Datanode上进程的请求和响应聚集到一台机器上,同时会帮助处理GTM失效的情况。
GTM可能会发生单点故障,可以配置一个GTM-Standby节点作为GTM的备用节点。
2.1协调器(Coordinator)
处理客户端连接。
分析查询语句,生成执行计划,并将计划传递给数据节点实际执行。
对数据节点返回的查询中间结果集执行最后处理。
管理事务两阶段提交(2PC)。
存储全局目录(GlobalCatalog)信息。
2.2数据节点(DataNode)
实际存储表和索引数据,数据自动打散分布(或者复制)到集群中各数据节点。
只有协调器连接到数据节点才能可读写。
执行协调器下传的查询,一个查询在所有相关节点上并行查询。
两个数据节点间可建立一对一通讯连接,交换分布式表关联查询的相关信息。
2.3全局事务管理器(GTM)
全局事务管理器(GTM:Global Transaction Manager)
全集群只有一个GTM节点,会有单点故障问题,可以配置StranBy热备节点保证高可用。
通过部署GTM Proxy,解决GTM性能瓶颈。
提供事务间一致性视图。
处理必须的MVCC任务:
transaction IDs 事务ID。
snapshots 数据快照,MVCC使用。
管理全局性数据值:
timestamps 时间戳。
sequences 序列对象。
2.4GTM Proxy
Ø 与协调器(Coordinator)和数据节点(DataNode)在一起运行。
Ø 协调器、数据节点直接与GTM Proxy交互替代GTM,它做为后端与GTM间的中间人。
Ø 将对GTM的请求分组归集,多个请求一次提交给GTM。
Ø 获取transaction ids(XIDs)范围。
Ø 获取数据快照。
2.5数据分布
数据分布有两种模式: 复制表(Replicated Table)与分布表(Distributed Table)
复制表(Replicated Table):每行记录复制到集群中所有的数据节点,每节点一份。
分布表(DistributedTable):记录分片存在不同节点,可用的分片策略方式Hash、Round Robin、Modulo。
2.6高可用性
全局事务管理器采用热备方式。
多个协调器间负载均衡。
数据节点使用流复制,复制数据到备节点。
Reference:
https://www.postgres-xl.org/documentation/tutorial-arch.html
https://www.linuxidc.com/Linux/2016-11/137238.htm