【转载】PGXC关键组件

参考自：

https://postgres-x2.github.io/reference/1.0/html/intro-whatis.html

Ultimate goal of Postgres-XC is to provide synchronous multi-master PostgreSQL cluster with read/write scalability. That is, Postgres-XC should provide the following features:

• Postgres-XC should provide multiple servers to accept transactions and statements from applications, which is known as "master" server in general. In Postgres-XC, this is called "Coordinator".

• Postgres-XC should provide more than one masters.

• Any "master" should provide consistent database view to applications. Any updates from any master must be visible in real time manner as if such updates are done in single PostgreSQL server.

• Tables should be able to be stored in the database in replicated or distributed way (known as fragment or partition). Replication and distribution should be transparent to applications, that is, such replicated and distributed table are seen as single table and location or number of copies of each record/tuple is managed by Postgres-XC and is not visible to applications.

• Postgres-XC provides compatible PostgreSQL API to applications.

• Postgres-XC should provide single and unified view of underlying PostgreSQL database servers so that SQL statements does not depend on how tables are stored in distributed way.

Postgres-XC key component:

In this section, we will show main components of Postgres-XC.

Postgres-XC is composed of three major components, called GTM (Global Transaction Manager), Coordinator and Datanode. Their features are given in the following sections.

GTM:

GTM is a key component of Postgres-XC to provide consistent transaction management and tuple visibility control.

As described later in this manual, PostgreSQL's transaction management is based upon MVCC (Multi-Version Concurrency Control) technology. Postgres-XC extracts this technology into separate component as GTM so that any Postgres-XC component's transaction management is based upon single global status. Details will be described in Chapter 43.

Coordinator：

Coordinator is an interface to applications. It acts like conventional PostgreSQL backend process. However, Coordinator does not store any actual data. Actual data is stored by Datanode as described below. Coordinator receives SQL statements, get Global Transaction Id and Global Snapshot as needed, determine which Datanode is involved and ask them to execute (a part of) statement. When issuing statement to Datanodes, it is associated with GXID and Global Snapshot so that Datanode is not confused if it receives another statement from another transaction originated by another Coordinator.

Datanode:

Datanode actually stores your data. Tables may be distributed among Datanodes, or replicated to all the Datanodes. Datanode does not have global view of the whole database, it just takes care of locally stored data. Incoming statement is examined by the Coordinator as described next, and rebuilt to execute at each Datanode involved. It is then transferred to each Datanodes involved together with GXID and Global Snapshot as needed. Datanode may receive request from various Coordinators. However, because each the transaction is identified uniquely and associated with consistent (global) snapshot, data node doesn't have to worry what Coordinator each transaction or statement came from.