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 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 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.

Cross-region read/write splitting

  • Characteristics
    • 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
    NodeForwarded 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