PolarDB:Global Database Network (GDN)

Overview

Basic Edition

Multi-write Edition

A Global Database Network (GDN) consists of one primary cluster and multiple secondary clusters. The primary cluster handles write requests, while the secondary clusters are distributed across different regions to handle local read requests. Data is synchronized across all clusters over low-latency links, forming a single logical database.

In the Basic Edition architecture, secondary clusters forward write requests to the primary cluster through cross-region routing. When clusters are separated by large physical distances, write latency on the secondary clusters increases significantly. The GDN Multi-write Edition provides a table-level multi-write solution, allowing each cluster to write locally to tables where it has write permissions. This significantly reduces cross-region write latency. For more information, see GDN Multi-write Edition User Guide. Note The PolarDB GDN Multi-write Edition is currently in phased release. To use this feature, you can join our DingTalk group by searching for the group number. DingTalk group number: 30245017864

Use cases

Active-active geo-redundancy (multi-region deployment) Deploy your services across multiple regions. GDN features, such as low-latency cross-region synchronization, cross-region read/write splitting, and local reads, ensure that applications in each region achieve database access latency of less than 2 seconds. Typical industries: Gaming, cross-border e-commerce, local services (such as food delivery), and new retail (such as physical stores). Business architecture: For optimal performance, applications in each region can directly read from and write to their local database. Write requests are forwarded to the primary cluster for processing. In a GDN, each cluster provides an independent endpoint. You can connect to the endpoint of the nearest cluster based on your application's region. The specifications of the secondary clusters in China (Beijing) and China (Shenzhen) must be greater than or equal to those of the primary cluster in China (Hangzhou). For best results, we recommend using the same specifications.

Geo-disaster recovery Use GDN to achieve cross-region high availability, improving data security and system availability. When the data center that hosts the primary cluster fails, you can quickly restore your services by manually failing over to a secondary cluster. GDN supports various architectures, such as two-region three-data-center, two-region four-data-center, and three-region six-data-center. Typical industries: Banking, securities, and insurance. Business architecture (example: two-region three-data-center architecture): The primary region is China (Beijing), which uses a dual-availability-zone deployment covering AZ1 and AZ2. The disaster recovery region is China (Shanghai), which uses a single-availability-zone deployment. By default, the application reads from and writes to the database in AZ1 of the Beijing region. If AZ1 fails, the system fails over to AZ2 in Beijing. If both AZ1 and AZ2 fail, the system fails over to AZ3 in Shanghai. Note A primary/secondary switchover in a GDN is typically completed in less than 5 minutes, but can take up to 10 minutes. During the switchover, a transient disconnection of up to 160 seconds may occur. We recommend that you perform the switchover during off-peak hours and make sure that your application has a reconnection mechanism.

Benefits

• Cross-region deployment: Seamlessly expand from a single-region to a multi-region architecture without application code changes.

• Cross-region read/write splitting and local reads: In a GDN, read requests are routed to the local secondary cluster, while write requests are forwarded to the primary cluster.

• Flexible configuration: The primary and secondary clusters have independent configurations, including cluster specifications, whitelists, and parameter values.

• Low-latency cross-region synchronization: GDN uses asynchronous physical replication (based on Redo Log) and parallel replay technologies to reduce cross-region replication latency. Data is synchronized across all clusters with a replication latency of less than 2 seconds, which significantly reduces read latency for applications in non-central regions.

Applicability

Pricing

When you use a GDN, you are charged for the clusters and for inter-region data transfers. The detailed billing rules are as follows:

• Free scenarios:

  Your primary and secondary clusters are both deployed in regions within the Chinese mainland, or both are deployed in the China (Hong Kong) region or other overseas regions. Examples:

  • Both the primary and secondary clusters are in the Chinese mainland. For example, the primary cluster is in the China (Chengdu) region, and the secondary cluster is in the China (Hangzhou) or China (Shenzhen) region.

  • Both the primary and secondary clusters are in the China (Hong Kong) region or other overseas regions. For example, the primary cluster is in the Singapore region, and the secondary cluster is in the Philippines (Manila) region.

• Billable scenarios:

  One of your clusters (primary or secondary) is deployed in a region in the Chinese mainland, and the other is deployed in the China (Hong Kong) region or another overseas region. Examples:

  • The primary cluster is in the Chinese mainland, and the secondary cluster is outside the Chinese mainland. For example, the primary cluster is in the China (Chengdu) region, and the secondary cluster is in the China (Hong Kong) or Singapore region.

  • The primary cluster is outside the Chinese mainland, and the secondary cluster is in the Chinese mainland. For example, the primary cluster is in the Singapore region, and the secondary cluster is in the China (Hangzhou) or China (Shenzhen) region.

• Billing rules: USD 0.80 per GB, billed hourly. The fee is calculated based on the amount of Redo Log data that is physically replicated from the primary cluster to a cross-region secondary cluster within one hour. You can estimate this traffic fee by querying the physical position converted from the log sequence number (LSN).

  Billing example

  Example

  At 09:00, you query the physical write position of the log and find it is ib_logfile1/648143676. At 10:00, the position is updated to ib_logfile3/648142342. This indicates that the amount of data written in this hour is the difference between the two positions.

  1. Amount written to the start file (ib_logfile1):
     Subtract the start offset from the total file size. Each log file is 1 GB (1,073,741,824 bytes). The amount written is 1073741824 - 648143676 = 425598148 bytes.
     
     
     
     
     
     
     
     

  2. Amount written to the intermediate file (ib_logfile2):
     After ib_logfile1 is full, the system completely writes ib_logfile2. This amount is 1,073,741,824 bytes (1 GB).
     
     
     
     
     
     
     
     

  3. Amount written to the end file (ib_logfile3):
     This is the offset at the end, which is 648,142,342 bytes.
     
     
     
     
     
     
     
     

  Therefore, the total amount written = 425598148 + 1073741824 + 648142342 = 2147482314 bytes, which is 2147482314 / 1024 / 1024 / 1024 = 1.999998 GB (rounded down to six decimal places). The cross-region data transfer fee for this hour is approximately 1.999998 GB * USD 0.80/GB = USD 1.5999984.

  Query the log write progress and physical file offset

  -- Query the current write progress of the log system.
  SHOW STATUS LIKE 'Innodb_log_write_lsn'; 
  +----------------------+------------+
  | Variable_name        | Value      |
  +----------------------+------------+
  | Innodb_log_write_lsn | 1721889596 |
  +----------------------+------------+
  
  -- Query the physical file offset in bytes.
  SELECT lsn_to_pos(1721889596); 
  +------------------------+
  | lsn_to_pos(1721889596) |
  +------------------------+
  | ib_logfile1/648143676  |
  +------------------------+

Get started

1. Create and manage a Global Database Network: Select a cluster that meets the requirements as the primary cluster of the GDN.

2. Add a secondary cluster: Go to the PolarDB buy page to add a secondary cluster to the GDN that you created.

3. Connect to a Global Database Network: In a GDN, each cluster (primary and secondary) provides an independent cluster endpoint. You can connect to the endpoint of the nearest cluster based on your application's region. GDN also provides a global endpoint. This feature enables local access. It also ensures the domain name remains unchanged after a primary cluster failover.