A global database network (GDN) consists of multiple PolarDB clusters that are deployed in multiple regions within a country. This topic describes GDNs.
Data is synchronized across all clusters in a GDN, which enables geo-disaster recovery. All clusters handle read requests while write requests are handled only by the primary cluster. GDNs are ideal for the following scenarios:
Active geo-redundancy
If you deploy applications in multiple regions but deploy databases only in the primary region, applications that are not deployed in the primary region must communicate with the databases that may be located in a geographically distant region. This results in high latency and poor performance. GDN replicates data across regions at low latencies and provides cross-region read/write splitting. GDN allows applications to read data from a database local to the region. This allows databases to be accessed within 2 seconds.
Geo-disaster recovery
GDN supports geo-disaster recovery regardless of whether your applications are deployed in the same region. If a fault occurs in the region where the primary cluster is deployed, you need only to manually switch your service over to a secondary cluster.
NoteA typical failover can be completed in 10 minutes. In most cases, failovers can be completed within 5 minutes. During the failover, services may be interrupted for up to 160 seconds. We recommend that you perform the switchover during off-peak hours and make sure that your applications are configured to automatically reconnect to the database service.
Request routing
The read and write requests on each cluster in a GDN are routed based on the cluster endpoint configuration. For example, assume that you have three GDN clusters. Cluster 1 is the primary cluster and Cluster 2 and Cluster 3 are secondary clusters. If the endpoint of Cluster 2 can handle read and write requests but is configured to allow read requests to be routed to the primary node of the primary cluster, the request latency may be high. If the endpoint of Cluster 3 is configured to handle only read requests, read requests are routed only to the read-only nodes of the secondary clusters, not to the primary nodes of the primary or secondary clusters. For more information about how to configure the endpoint of a cluster, see Configure PolarProxy.
If the endpoint of a secondary cluster is configured to handle both read and write requests, write requests and other broadcast requests (such as SET statements) are routed to the primary node of the primary cluster. If session consistency is enabled for the secondary cluster, read requests on the cluster may be routed to the primary node of the primary cluster.
Benefits
Zero code modification for deployment: If an application is deployed in one region, you can deploy it in multiple regions without the need to modify code. For more information, see Cross-region deployment.
Cross-region read/write splitting: GDN clusters can handle both read and write requests. Read requests are sent to the cluster in the same region while write requests are forwarded to the primary cluster. For more information, see Cross-region read/write splitting.
Flexible configuration: The primary and secondary clusters can be configured separately. The configuration of a cluster includes cluster specifications, whitelists, and parameter values. For more information, see Create and release a GDN.
Low-latency data synchronization across regions. Physical replication is performed over multiple channels, which allows data to be replicated across all nodes at a latency of less than 2 seconds even under heavy loads. For more information, see Low-latency synchronization across regions.
Pricing
You are not charged for the traffic that is generated during cross-region data transmission within a GDN. You are charged only for the use of PolarDB clusters in the GDN. For more information about the pricing rules of PolarDB clusters, see Billable items overview.
Supported regions and clusters
Regions: GDN is available in more than 10 regions, including regions inside the Chinese mainland, the China (Hong Kong) region, and regions outside China. For more information, see Region mappings between the primary and secondary clusters.
A cluster in a GDN must be of Enterprise Edition and meet the following requirements:
A PolarDB for MySQL 8.0.2 cluster
A PolarDB for MySQL 8.0.1 cluster whose revision version is 8.0.1.1.17 or later.
A PolarDB for MySQL 5.7 cluster whose revision version is 5.7.1.0.21 or later.
A PolarDB for MySQL 5.6 cluster whose revision version is 5.6.1.0.32 or later.
The primary cluster and secondary clusters must have the same database engine version, which can be MySQL 8.0, MySQL 5.7, or MySQL 5.6.
A GDN consists of one primary cluster and up to four secondary clusters. For more information about limits on their regions, see Region mappings between the primary and secondary clusters.
NoteTo add more secondary clusters, go to Quota Center. Click Apply in the Actions column corresponding to GDN cluster upper limit adjustment.
A cluster belongs to only one GDN.
A secondary cluster in the GDN must have at least 4 cores.
Clusters in the GDN do not support the database and table restoration feature.
Clusters in the GDN do not support the In-Memory Column Index (IMCI) feature.
Region mappings between the primary and secondary clusters
GDNs can communicate across regions. The following table lists the region mappings between the primary and secondary clusters in a GDN.
Region of primary cluster | Region of secondary cluster |
All regions in Chinese mainland | In the same region as the primary cluster or in a region in Chinese mainland other than the region where the primary cluster is deployed. For example, if the primary cluster is in the China (Hangzhou) region, secondary clusters can be in the China (Hangzhou) region or another region in Chinese mainland. |
China (Hong Kong) | China (Hong Kong) |
Japan (Tokyo) | Japan (Tokyo) |
South Korea (Seoul) | South Korea (Seoul) |
Singapore | Singapore |
Australia (Sydney) | Australia (Sydney) |
Malaysia (Kuala Lumpur) | Malaysia (Kuala Lumpur) |
Indonesia (Jakarta) | Indonesia (Jakarta) |
Philippines (Manila) | Philippines (Manila) |
Germany (Frankfurt) | Germany (Frankfurt) |
UK (London) | UK (London) |
US (Silicon Valley) | US (Silicon Valley) and US (Virginia) |
US (Virginia) | US (Silicon Valley) and US (Virginia) |
Philippines (Manila) | Philippines (Manila) |
Thailand (Bangkok) | Thailand (Bangkok) |
Get started with GDNs
For more information, see Create a GDN.