Postgres-XC 1.2.1 Documentation | ||||
---|---|---|---|---|
Prev | Fast Backward | Chapter 13. Concurrency Control | Fast Forward | Next |
Note: XCONLY: The following description applies only to Postgres-XC.
The above sections described Postgres-XC's concurrency control and MVCC common to PostgreSQL. This section describes how Postgres-XC implements global concurrency control and MVCC among multiple Coordinators and Datanodes.
In conventional replication clusters, you can run read transactions in parallel in multiple standby, or slave servers. Replication servers provide read scalability. However, you cannot issue write transactions to standby servers because they don't have means to propagate changes safely. They cannot maintain consistent view of database to applications for write operations, unless you issue write transactions to single master server.
Postgres-XC is different.
As described in Section , Postgres-XC is composed of GTM (Global Transaction Manager), Coordinators and Datanodes.
In Postgres-XC, any Coordinator can accept any transaction, regardless whether it is read only or read/write. Transaction integrity is enforced by GTM (global transaction manager). Because we have multiple Coordinators, each of them can handle incoming transactions and statements in parallel.
Analyzed statements are converted into internal plans, which include SQL statements targeted to Datanodes. They're proxied to each target Datanode, handled and the result will be sent back to originating Coordinator where all the results from target Datanodes will be combined into the result to be sent back to the application.
Each table can be distributed or replicated as described in Section . If you design each table's distribution carefully, most of the statements may need to target to just one Datanode. In this way, Coordinators and Datanodes runs transactions in parallel which scales out both read and write operations.
More detailed internals about Postgres-XC's transaction management will be found in Chapter 45.