PolarDB Global Database Network (GDN)-PolarDB(PolarDB)-阿里云帮助中心

Overview

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

Data synchronization

GDN synchronizes data across regions through asynchronous physical replication with parallel physical log replay. Replication delay stays below 2 seconds without affecting primary cluster performance or stability, ensuring eventual consistency across all regions.

Request routing

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

Write requests (INSERT, UPDATE, DELETE) and in-transaction requests route to the primary node of the primary cluster.
Read requests route to read-only nodes of the local secondary cluster by default. With enabled, some reads may 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 regions with GDN's low-latency synchronization, read/write splitting, and local reads — database access latency stays below 2 seconds per region.

Typical industries: Gaming, cross-border e-commerce, local services, and new retail.
Business architecture:
- Applications connect to their local cluster. Reads are handled locally; writes forward to the primary cluster.
- Each cluster has an independent endpoint. Applications connect to the nearest one.
- Secondary cluster specifications in Beijing and Shenzhen must match or exceed the primary cluster in Hangzhou.

Geo-disaster recovery

GDN provides cross-region high availability for data security and system uptime. If the primary cluster's data center fails, manually fail over to a secondary cluster. Supported architectures: 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 (AZ1 and AZ2).
- Shanghai is the disaster recovery region with a single-zone deployment.
- Applications connect to AZ1 in Beijing by default. If AZ1 fails, traffic switches to AZ2. If both fail, the application fails over to the Shanghai disaster recovery cluster.

Note

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

Benefits

Cross-region deployment: Extend from a single city to multiple regions without code changes.
Cross-region read/write splitting and local reads: Local secondary clusters handle reads; writes forward to the primary cluster.
Flexible configuration: Primary and secondary clusters have independent specifications, whitelists, and parameters.
Low-latency cross-region synchronization: Asynchronous physical replication with parallel replay keeps cross-region 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 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

Any region in the Chinese mainland, including the primary cluster's region.

Example: If the primary cluster is in China (Hangzhou), secondary clusters can be in any Chinese mainland region, including Hangzhou.

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 supports one primary cluster and up to four secondary clusters.
Primary and secondary clusters must have the same database engine version: .
Secondary cluster specifications must match or exceed the primary cluster's.
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

: Select an cluster as the GDN's primary cluster.
: 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.
: Each cluster has an independent endpoint. Connect to the nearest one based on your application's region.