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.
Data replication is implemented based on redo logs.
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.
Clusters:
Database Edition: Enterprise Edition.
Edition: Cluster Edition.
Database Engine:
PolarDB for MySQL 8.0.2.
PolarDB for MySQL 8.0.1 with revision version 8.0.1.1.17 or later.
PolarDB for MySQL 5.7 with revision version 5.7.1.0.21 or later.
PolarDB for MySQL 5.6 with revision version 5.6.1.0.32 or later.
Other limits:
The primary cluster and secondary clusters must use the same database engine version. Supported versions are MySQL 8.0, MySQL 5.7, and MySQL 5.6.
A GDN consists of one primary cluster and up to four secondary clusters.
NoteTo add more secondary clusters, go to Quota Center. Find the quota based on the
polardb_mysql_gdn_regionquota ID, and then click Apply in the Actions column.
Each cluster can belong to only one GDN.
Clusters in a GDN can be serverless clusters or serverless-enabled clusters with defined specifications. When the database engine of the primary cluster meets the following conditions, all clusters in the GDN must have at least one read-only node.
PolarDB for MySQL 8.0.1 with revision version 8.0.1.1.42 or later.
PolarDB for MySQL 8.0.2 with revision version 8.0.2.2.23 or later.
For non-serverless secondary clusters in a GDN, the compute nodes must have at least 4 CPU cores.
Clusters in a GDN do not support the database and table restoration feature.
Clusters in a GDN support the in-memory column index (IMCI) feature. However, before you add column store nodes to a cluster, you must contact us to enable GDN support for IMCI by adding the feature to whitelists.
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. Note If you want to deploy the secondary cluster in other regions, contact us for assistance. |
Regions outside 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). |
Usage notes
You must sign the PolarDB Cross-border Data Transfer Compliance Commitment if you plan to create a secondary cluster in a region outside the Chinese mainland for a GDN.
Get started with GDNs
For more information, see Create a GDN.