This topic describes the architecture of a global database network (GDN).
Figure 1. GDN architecture 
Cross-region deployment
A GDN consists of one primary cluster and one or more secondary clusters. Data is synchronized among the clusters within the GDN.
NoteBy default, a GDN contains one primary cluster and up to four secondary clusters. To add more secondary clusters, go to Quota Center. Click Apply in the Actions column corresponding to GDN cluster upper limit adjustment.
By default, each cluster in a GDN contains two nodes. You can add up to 16 nodes to a cluster. For information about how to add nodes, see the "Add a read-only node" section of the Add or remove read-only nodes topic.
Low-latency synchronization across regions
A GDN replicates data across regions in an asynchronous manner. By using technologies such as physical logging and parallel processing, the GDN can reduce the latency of cross-region replication between primary and secondary clusters. In a GDN, data is synchronized across all clusters at a latency of no more than 2 seconds. This significantly lowers the read latency for applications that access data from geographically dispersed regions. A secondary cluster established in a remote region for data synchronization does not negatively impact the stability or performance of the primary cluster.
Cross-region read/write splitting
Characteristics
In most cases, read requests are forwarded to the secondary cluster in the current region, and write requests are forwarded to the primary cluster.
NoteThe primary node in the secondary cluster is mainly used to asynchronously replicate data from the primary cluster. By default, read requests are sent to the read-only nodes of the secondary cluster in the same region to reduce the latency of physical replication across regions.
You do not need to modify application code to enable read/write splitting.
Implementation methods
The cross-region read/write splitting feature of a GDN must be implemented based on the cluster endpoints of PolarDB clusters. For information about how to manage a cluster endpoint for a GDN, see Connect to a GDN.
Logic for forwarding requests
Destination node
Forwarded request
Only the primary node
Requests that are sent to perform DML operations such as INSERT, UPDATE, DELETE, and SELECT FOR UPDATE.
Requests that are sent to perform DDL operations, such as creating databases or tables, deleting databases or tables, and modifying table schemas or permissions.
Requests that are encapsulated in transactions.
Requests that are used to call user-defined functions.
Requests that are used to run stored procedures.
Requests that are used to execute EXECUTE statements.
Requests that are used to run multi-statement queries. For more information, see Multi-statement.
Requests that involve temporary tables.
Requests that are used to execute SELECT last_insert_id() statements.
Requests that are used to query or reconfigure user variables.
Requests that are used to execute SHOW PROCESSLIST statements.
Requests that are used to execute KILL statements in SQL. These statements are different from the KILL commands in Linux.
The primary node or read-only nodes
NoteRequests are sent to the primary node only if you set the Primary Node Accepts Read Requests parameter to Yes.
Read requests that are not encapsulated in transactions.
Requests that are used to execute COM_STMT_EXECUTE statements.
All nodes
Requests that are used to modify system variables.
Requests that are used to execute USE statements.
Requests that are used to execute COM_STMT_PREPARE statements.
Requests that are used to execute COM_CHANGE_USER, COM_QUIT, and COM_SET_OPTION statements.
NoteThe primary node in the secondary cluster is mainly used to asynchronously replicate data from the primary cluster, and does not process read and write requests. Therefore, the primary node in the table refers to the primary node in the primary cluster, and read-only nodes refer to the read-only nodes in the secondary cluster.