All Products
Search

This Product

    PolarDB:Global Database Network (GDN)

    Document Center

    PolarDB:Global Database Network (GDN)

    Last Updated:Jun 03, 2026

    A global database network (GDN) connects PolarDB clusters across multiple regions with synchronized data. Each cluster handles local reads, while writes are forwarded to the primary cluster.

    Overview

    A GDN consists of one primary cluster and multiple secondary clusters. The primary cluster handles writes; secondary clusters in different regions serve local reads. Low-latency links synchronize data across all clusters, forming a single logical database.

    image

    Data synchronization

    GDN uses asynchronous physical replication with parallel physical log replay to synchronize data across regions. Replication delay between primary and secondary clusters stays below 2 seconds without impacting primary cluster performance or stability, ensuring eventual consistency across all regions.

    Request routing

    Each cluster's determines request routing. No application changes are needed — connect to a cluster endpoint and requests route automatically:

    • Write requests (INSERT, UPDATE, DELETE) and all in-transaction requests are forwarded to the primary node of the primary cluster.

    • Read requests route by default to read-only nodes of the local secondary cluster. If is enabled, some reads may also route to the primary cluster's primary node.

    Click to view detailed forwarding logic

    Target node

    Forwarded requests

    Sent only to the primary node of the primary cluster

    • DML operations (such as INSERT, UPDATE, and DELETE)

    • DDL operations (such as creating or deleting tables or databases, or altering table schemas)

    • SHOW commands

    • Transaction-related commands such as BEGIN and COMMIT

    • LISTEN, UNLISTEN, and NOTIFY commands

    • ANALYZE command

    • Two-phase commit protocol commands

    • Requests within a transaction (behavior may vary based on the transaction splitting configuration)

    • Function definitions and calls (behavior may vary based on the user-defined function routing rule configuration)

    • Requests that use temporary tables

    • Multi-statement Multi Statements

    • PREPARE statements that contain write requests

    Sent to read-only nodes or the primary node

    • Read requests outside a transaction

    • EXPLAIN command

    • PREPARE statements that contain read requests

    Always sent to all nodes

    • USE command

    • DISCARD and DEALLOCATE commands

    Use cases

    Active geo-redundancy (multi-region deployment)

    Deploy across multiple regions with GDN's low-latency cross-region synchronization, read/write splitting, and local reads — keeping database access latency below 2 seconds per region.

    • Typical industries: Games, cross-border E-commerce, local services (food delivery), and new retail (outlets).

    • Business architecture:

      • Applications in each region connect to their local cluster. Reads are handled locally; writes are forwarded to the primary cluster.

      • Each cluster has an independent endpoint. Applications connect to the nearest endpoint based on their region.

      • Secondary cluster node specifications in Beijing and Shenzhen must be equal to or greater than the primary cluster in Hangzhou. Keep specifications consistent.

    image

    Geo-disaster recovery

    GDN enables cross-region high availability for improved data security and system uptime. If the primary cluster's data center fails, manually fail over to a secondary cluster. Supported architectures include three data centers across two regions, four across two regions, and six across three regions.

    • Typical industries: Banking, securities, and insurance.

    • Business architecture (example: three data centers across two regions):

      • Beijing is the primary region with a dual-zone deployment spanning AZ1 and AZ2.

      • Shanghai is the disaster recovery region with a single-zone deployment.

      • By default, applications connect to AZ1 in Beijing for local reads and writes. If AZ1 fails, traffic switches to AZ2 in Beijing. If both fail, the application fails over to the disaster recovery cluster in Shanghai.

    image
    Note

    GDN failovers complete within 10 minutes (under 5 minutes in tests). Applications may experience transient connection errors for up to 160 seconds during failover. Perform failovers during off-peak hours and ensure your application has a reconnection mechanism.

    Benefits

    • Cross-region deployment: Extend from a single city to multiple regions without code changes.

    • Cross-region read/write splitting and local reads: Reads are handled by the local secondary cluster; writes are forwarded to the primary cluster.

    • Flexible configuration: Primary and secondary clusters have independent node specifications, whitelists, and parameter settings.

    • Low-latency cross-region synchronization: Asynchronous physical replication and parallel replay keep cross-region replication delay below 2 seconds, reducing read latency for applications outside the primary cluster's region.

    Limits

    Cluster versions

    • Database engine:

    • Edition: Enterprise Edition

    • : Single zone (with hot standby storage cluster disabled)

    Supported regions

    GDN is available in more than 10 regions worldwide, including the Chinese mainland, China (Hong Kong), and overseas regions.

    Primary cluster region

    Secondary cluster region

    All regions in the Chinese mainland

    The same region as the primary cluster, or any other region in the Chinese mainland.

    For example, if the primary cluster is in China (Hangzhou), the secondary cluster can be in China (Hangzhou) or any other region in the Chinese mainland.

    Note

    For other region requirements, submit a ticket.

    Regions outside the Chinese mainland

    China (Hong Kong), Japan (Tokyo), South Korea (Seoul), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), Philippines (Manila), Thailand (Bangkok), Germany (Frankfurt), US (Silicon Valley), US (Virginia), and UK (London).
    Important

    For regions outside the Chinese mainland, sign the Cross-Border Data Transfer Compliance Agreement before creating a secondary cluster.

    Feature limits

    • Clusters in a GDN do not support the database and table restoration feature.

    Other limits

    • A GDN can consist of one primary cluster and up to four secondary clusters.

    • Primary and secondary clusters must have the same database engine version: .

    • Secondary cluster node specifications must be equal to or greater than the primary cluster's. Keep specifications consistent.

    • A cluster can belong to only one GDN.

    Billing

    GDN cross-region data transfer is currently free. You pay only the for each PolarDB cluster.

    Quick start

    1. : Select an cluster as the GDN's primary cluster.

    2. : Go to the PolarDB purchase page to add a secondary cluster to the GDN.

      Note

      Only new secondary clusters can be created. Existing clusters cannot be added.

    3. : Each cluster has an independent endpoint. Connect to the nearest endpoint based on your application's region.