在我们继续之前，你应该先了解下PostgreSQL的基本架构。了解PostgreSQL各个部分的作用将使本章更加清晰。

简而言之，Postgres-XL是由多个PostgreSQL数据库集群组成的，但看起来是单个数据库集群一样。根据你的设计，每个表都可以在各个数据库之间进行复制或分发。

为了实现这一目标，Postgres-XL是由GTM，Coordinator和Datanode三部分组成。 GTM负责支持事务的ACID。 Datanode存储数据并处理SQL操作（只能操作自己存储的数据）。Coordinator分析来自应用程序的SQL操作，确定哪个Datanode包含数据，并将指令发送到正确的Datanode。

通常情况下，GTM应该安装在单独的服务器上，因为GTM要处理所有Coordinator和Datanode的事务需求。你可以配置GTM-Proxy（GTM代理）来分组同一服务器上运行的Coordinator和Datanode的请求和响应， GTM-Proxy减少了与GTM的交互次数和数据量。 GTM代理还还可以处理GTM故障。

在同一台服务器上同时部署Coordinator和Datanode通常是很好的做法，这样我们就不必担心两者之间的负载平衡，如果是复制表的话，不需要发送额外的网络请求就可以从本地拿到数据。你可以部署任意数量的服务器（Coordinator和Datanode同时运行）。Coordinator和Datanode都是PostgreSQL实例，你可能需要做些配置使它们避免资源冲突。例如为它们分配不同的工作目录和端口号是非常重要的。

Postgres-XL允许多个Coordinator单独从应用程序接受SQL指令，而不是集中的方式。写操作可以通过任何一个Coordinator来完成，没有任何区别。他们看起来就像是单一的数据库。Coordinator的职责是接受和分销SQL指令，查找哪些Datanodes存储相应的数据，可能需要将查询计划发送到适当的Datanodes，然后收集结果并将其返回给应用程序。

Coordinator不存储用户数据。它仅存储目录数据，用来确定如何处理SQL语句以及查找目标Datanodes等等。你不必过分担心Coordinator失败，当一个Coordinator失败时，你可以切换到另一个。

GTM可能发生单点故障（SPOF）。为了防止这种情况，你可以运行另一个GTM（GTM-Standby）来备份主GTM的状态。当主GTM失败时，GTM-Proxy可以随时切换到备用。这些将在高可用性部分中详细描述。

如上所述，Postgres-XL的Coordinator和Datanodes都是是PostgreSQL数据库。在数据库范畴，PostgreSQL使用客户端/服务器模型。 PostgreSQL会话包含如下两个服务：

• server，服务端进程，管理数据库文件、接受客户端应用程序的连接，为client执行数据库操作。该进程称为postgres。

• client，客户端，需要执行数据库操作。客户端应用程序多种多样：可以是文本工具，图形应用程序，访问数据库以显示网页的Web服务器或专门的数据库维护工具。一些客户端应用程序随PostgreSQL发行版提供;大多数是由用户开发的。

在典型的客户端/服务器应用程序中，客户端和服务器部署在不同的主机上。它们通过TCP / IP网络连接进行通信。需要注意的是，有些文件在客户端上可以访问，在数据库服务器上却不行（可能只是文件名不同）。

PostgreSQL服务器可以处理来自客户端的多个并发连接。为此，它为每个连接启动一个新进程。连接一旦建立，原始的postgres进程不会干预客户端和新的服务器进程之间的通信。主服务进程是始终运行的，等待客户端的连接，期间，有很多连接产生或消亡。 （当然，这一切对用户都是不可见的，为了完成性我们这里简单的提一下。）