A global database network (GDN) connects PolarDB for MySQL clusters across regions into a single replication topology. Use a GDN when you need cross-region disaster recovery or active geo-redundancy — where a regional outage should not interrupt database availability.
If you only need read scaling within a single region, a read-only cluster is sufficient. A GDN is the right choice when your RPO (recovery point objective) and RTO (recovery time objective) require cross-region data redundancy.
Prerequisites
Before you begin, make sure your primary cluster meets the following requirements:
An Enterprise Edition cluster in the Cluster Edition series
At least one read-only node
One of the following engine versions:
MySQL 8.0.2
MySQL 8.0.1 with minor engine version 8.0.1.1.17 or later
MySQL 5.7 with minor engine version 5.7.1.0.21 or later
MySQL 5.6 with minor engine version 5.6.1.0.32 or later
Supported regions
GDN supports the following regions: all regions in 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).
Cross-border secondary cluster deployment requires a separate request. For details, see Add a secondary cluster.
Limits
Cluster and node limits
| Item | Primary cluster | Secondary cluster |
|---|---|---|
| Clusters per GDN | 1 | Up to 4 |
| Nodes per cluster (default) | 2 | 2 |
| Nodes per cluster (maximum) | 16 | 16 |
| Minimum CPU cores per compute node | — | 4 cores (non-serverless only) |
Additional constraints:
Each cluster can belong to only one GDN.
Only newly created clusters can be added as secondary clusters. Existing clusters cannot be converted to secondary clusters.
The primary and secondary clusters must run the same engine version: MySQL 8.0, MySQL 5.7, or MySQL 5.6.
The default quota allows up to four secondary clusters. To add more, go to Quota Center, find the quota item polardb_mysql_gdn_region, and click Apply.Feature limits
In-Memory Column Index (IMCI): IMCI is supported in GDN clusters, but you must enable the
loose_polar_enable_imci_with_standbyparameter before adding a read-only column store node. The primary cluster must also meet one of the following version requirements:MySQL 8.0.1 with revision version 8.0.1.1.48 or later
MySQL 8.0.2 with revision version 8.0.2.2.27 or later
Serverless: GDN clusters support serverless clusters and defined-specification clusters with the serverless feature enabled. If the primary cluster's minor engine version is earlier than 8.0.1.1.42 (MySQL 8.0.1) or 8.0.2.2.23 (MySQL 8.0.2), all clusters in the GDN must include at least one read-only node.
Database and table restoration: Not supported for clusters in a GDN.
Billing
You are charged for the clusters themselves and for inter-region data transfer. Transfer fees depend on whether data crosses the Chinese mainland border.
| Transfer type | Scenario | Fee |
|---|---|---|
| Non-cross-border | Both clusters in the Chinese mainland, or both outside the Chinese mainland | Free |
| Cross-border | One cluster in the Chinese mainland, the other outside | USD 0.80 per GB, billed hourly |
Cross-border data transfer fees apply starting 00:00 on January 1, 2026 (Singapore time). Before this date, cross-border transfer is free.
Cross-border fees are calculated based on the Redo Log data physically replicated from the primary cluster to the cross-border secondary cluster each hour. Estimate this volume by querying the log sequence number (LSN) position.
Example: At 09:00, the LSN maps to ib_logfile1/648143676. At 10:00, it maps to ib_logfile3/648142342. Each log file is 1 GB (1,073,741,824 bytes).
Written to
ib_logfile1:1,073,741,824 − 648,143,676 = 425,598,148bytesWritten to
ib_logfile2(full file):1,073,741,824bytesWritten to
ib_logfile3:648,142,342bytesTotal:
2,147,482,314bytes =2,147,482,314 / 1,073,741,824 = 1.999998GB — Fee:1.999998 GB × USD 0.80/GB = USD 1.5999984
Query the LSN position:
-- Query the current log write progress
SHOW STATUS LIKE 'Innodb_log_write_lsn';
+----------------------+------------+
| Variable_name | Value |
+----------------------+------------+
| Innodb_log_write_lsn | 1721889596 |
+----------------------+------------+
-- Convert LSN to physical file offset
SELECT lsn_to_pos(1721889596);
+------------------------+
| lsn_to_pos(1721889596) |
+------------------------+
| ib_logfile1/648143676 |
+------------------------+Enabling the global domain name feature incurs additional fees for internal DNS resolution and inter-region data transfer. See Global domain name pricing.
Create a GDN
Log on to the PolarDB console. In the left navigation pane, click Global Database Network.
On the GDN page, click Create GDN.
In the Create GDN dialog box, configure the following parameters.
Parameter Description Compatibility Select MySQL. Version Fixed at Active-passive. Name Enter a name for the GDN. The name does not need to be unique. Primary Region Select the region where the primary cluster is located. Decide which cluster to designate as primary before selecting the region. Primary Cluster Select the existing cluster to use as the primary cluster. Global Domain Name Choose whether to enable the global domain name feature. A global domain name provides a unified endpoint for the GDN, enables nearest access, and remains unchanged after a primary cluster switchover. Click OK.
The GDN appears on the GDN page. From there, add a secondary cluster to the GDN.
View GDN information
Log on to the PolarDB console, then click a GDN ID on the GDN page to open the details page.
View basic information
The details page shows the GDN's ID, Version, Compatible Database, GDN Name, and Created At.

View the cluster list
The cluster list shows all primary and secondary clusters across all regions in the GDN.

View the topology
The Network Topology section displays clusters on a world map, showing their geographic distribution.
View replication latency
In the Network Topology section, click View Replication Latency. In the dialog box, filter by time period to view the replication latency.

Delete a GDN
A GDN can only be deleted when it contains only the primary cluster. Because a GDN cannot be restored after deletion and applications connected to it immediately lose database access, remove all secondary clusters before proceeding.
Deleting a GDN is irreversible. Applications connected to it can no longer access the database after deletion.
When you release the primary cluster, the GDN is automatically deleted — no separate deletion is required.
Console
Log on to the PolarDB console. In the left navigation pane, click Global Database Network.
On the GDN page, find the target GDN and click Delete in the Actions column.
If Delete is grayed out, the GDN still has secondary clusters. Delete all secondary clusters first.
Review the information in the dialog box and click OK to confirm.
API
Use the DeleteGlobalDatabaseNetwork API operation to delete a GDN programmatically. Before calling this operation, remove all secondary clusters from the GDN.
FAQ
How many GDNs can I create per Alibaba Cloud account?
There is no limit on the number of GDNs per account.
Can I change the primary cluster of an existing GDN?
Yes. Switch over the primary cluster in the PolarDB console. We recommend that you always use the default non-forced switchover mode. The forced switchover mode has the following limitations: you cannot specify the new primary cluster, and the original primary cluster is detached from the GDN after the switchover. Therefore, the forced switchover mode is not suitable for scenarios where you need to replace the primary cluster in a GDN.
API reference
| API | Description |
|---|---|
| CreateGlobalDatabaseNetwork | Creates a GDN. |
| DeleteGlobalDatabaseNetwork | Deletes a GDN. |
| DescribeGlobalDatabaseNetwork | Queries details of a specified GDN. |
| DescribeGlobalDatabaseNetworks | Queries details of all GDNs. |
| ModifyGlobalDatabaseNetwork | Modifies GDN settings. |