Postgres XL 集群中各节点的角色和做用

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