A global database network (GDN) consists of multiple PolarDB for MySQL 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. GDN is 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.
    Note A 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 60 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.
3

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 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.
Note 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.

Advantages

  • 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 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 for MySQL clusters in the GDN. For more information about the pricing rules of PolarDB for MySQL clusters, see Billable items.

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 use one of the following versions:
    • A PolarDB for MySQL 8.0.2 cluster
    • A PolarDB for MySQL 8.0.1 cluster
    • A PolarDB for MySQL 5.7 cluster whose revision version is 5.7.1.0.13 or later
    • A PolarDB for MySQL 5.6 cluster whose revision version is 5.6.1.0.27 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.

Region mappings between the primary and secondary clusters

GDNs cannot communicate across countries. You can add only secondary clusters that are in the same country as the primary cluster. The following table lists the region mappings between the primary and secondary clusters in a GDN.

Region of primary clusterRegion of secondary cluster
All regions in Chinese mainlandAny region in Chinese mainland.

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

China (Hong Kong)China (Hong Kong)
Japan (Tokyo)Japan (Tokyo)
South Korea (Seoul)South Korea (Seoul)
SingaporeSingapore
Australia (Sydney)Australia (Sydney)
Malaysia (Kuala Lumpur)Malaysia (Kuala Lumpur)
Indonesia (Jakarta)Indonesia (Jakarta)
Philippines (Manila)Philippines (Manila)
India (Mumbai)India (Mumbai)
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 and release a GDN.

Related videos

GDN

References