A global database network (GDN) consists of multiple PolarDB-X instances that are deployed in multiple regions within a country. This topic describes GDNs.
Data is synchronized across all PolarDB-X instances in a GDN, which enables geo-disaster recovery. All instances handle read requests. 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. GDNs replicate data across regions at low latencies and provide cross-region read/write splitting. GDNs allow applications to read data from the nearest database. This allows databases to be accessed within seconds.
Geo-disaster recovery
GDNs support geo-disaster recovery regardless of whether applications are deployed in the same region. If a fault occurs in the region where the primary instance is deployed, you need only to manually switch over the service to a secondary instance.
NoteA failover can be completed within 120 seconds.
Instance migration
Switching over the service from the primary instance to a secondary instance is suitable for both disaster recovery scenarios and common instance migration scenarios. For example, you can use a GDN to implement cross-region migration of a PolarDB-X instance and upgrade an PolarDB-X instance to a later version.
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.
Cross-region read/write splitting: Read requests are sent to the instance in the same region while write requests are forwarded to the primary instance.
Flexible configuration: The primary and secondary instances can be configured separately. The configuration of an instance includes instance specifications, whitelists, and parameter values.
Low-latency data synchronization across regions: The single-stream binary log replication mode is used in low-workload scenarios and the multi-stream binary log replication mode is used in high-workload scenarios to implement global synchronization latency within seconds.
Billing
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-X instances in the GDN. For more information about the pricing rules of PolarDB-X instances, see Billing.
Supported regions and instances
Regions: GDN is available in multiple regions, including regions in the Chinese mainland, the China (Hong Kong) region, and regions outside the Chinese mainland. For more information, see Region mappings between the primary and secondary instances.
A PolarDB-X instance in a GDN must meet the following requirements:
The instance must be of 5.4.19 or later.
Instance edition: Enterprise Edition.
The primary and secondary instances must have the same database engine version, which can be MySQL 8.0 or MySQL 5.7.
A GDN consists of one primary instance and up to four secondary instance. For more information about limits on their regions, see Region mappings between the primary and secondary instances.
A PolarDB-X instance can belong to only one GDN.
We recommend that secondary instances in a GDN use the same specifications as those in the primary instance.
Region mappings between the primary and secondary instances
Instances in a GDN can communicate across regions. The following table lists the region mappings between the primary and secondary instances in a GDN.
Region of primary instance | Region of secondary instance |
All regions in the Chinese mainland where PolarDB-X instances can be deployed | All regions in the Chinese mainland where PolarDB-X instances can be deployed. For example, if the primary instance is deployed in China (Hangzhou), a secondary instance can be deployed in China (Hangzhou) or another region in the Chinese mainland where PolarDB-X instances can be deployed. |
China (Hong Kong) | China (Hong Kong) |
Singapore | Singapore |
Indonesia (Jakarta) | Indonesia (Jakarta) |
Germany (Frankfurt) | Germany (Frankfurt) |
US (Silicon Valley) | US (Silicon Valley) and US (Virginia) |
US (Virginia) | US (Silicon Valley) and US (Virginia) |