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