This topic describes the technical architecture of global database networks (GDNs) and how it works.

Figure 1. GDN architecture
1

Cross-region deployment

  • A GDN consists of one primary cluster and one or more secondary clusters. Data is synchronized among PolarDB clusters in each GDN.
    Note A GDN can contain one primary cluster and up to four secondary clusters. To add more secondary clusters, submit a ticket.
  • By default, each cluster in a GDN contains two nodes. You can add up to 16 nodes for a single cluster. For more information, see Add a read-only node

Low-latency synchronization across regions

GDNs replicate data across regions in an asynchronous manner. GDNs also reduce the latency of cross-region replication between the primary and secondary clusters by using technologies like physical logs and parallel processing. Data is synchronized across clusters at latencies shorter than 2 seconds. This way, read requests from applications in regions other than the region of the primary cluster can be processed at minimum latencies. If you create cross-region secondary clusters and synchronize data, the stability and performance of the current primary cluster are not affected.

Note When you create a secondary cluster, we recommend that you select the same node specification as the primary cluster. This ensures low-latency synchronization. For information about how to create a secondary cluster, see Add a secondary cluster.

The following table describes the test results of the low-latency synchronization from the US (Silicon Valley) region to the China (Zhangjiakou) region in a GDN. These regions are used in the example.

Specification and topology of the tested clusters SysBench script Peak QPS/TPS Synchronization latency from a secondary cluster in the US (Silicon Valley) region to the primary cluster in the China (Zhangjiakou) region
GDN that covers the China (Zhangjiakou) region and the US (Silicon Valley) region

16 cores and 128 GB of memory

OLTP_INSERT 82655/82655 Less than 1 second
OLTP_WRITE_ONLY 157953/26325 Less than 1 second
OLTP_READ_WRITE 136758/6837 Less than 1 second

Cross-region read/write splitting

  • Characteristic
    • In most cases, read requests are forwarded to the secondary cluster in the same region, while write requests are forwarded to the primary cluster.
      Note The primary node in the secondary cluster is used to asynchronously replicate data from the primary cluster. By default, read requests are sent to the read-only nodes in the same region to reduce the latency of physical replication across regions.
    • You do not need to modify the code of your applications 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 more information about how to manage a cluster endpoint for a GDN, see Connect to a GDN.

  • Logic for forwarding requests
    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
    Note Requests are sent to the primary node only if the Primary Node Accepts Read Requests feature is enabled.
    • 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.
    • COM_CHANGE_USER, COM_QUIT, and COM_SET_OPTION.
    Note The primary node in the secondary cluster is 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.

References