参考自:
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.