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, distributed across different regions, handle local read requests. Data is synchronized across all clusters over low-latency links, forming a single logical database.

In the GDN Basic Edition architecture, secondary clusters forward write requests to the primary cluster via cross-region routing. When the primary and secondary clusters are deployed across different regions and are physically far apart, the write latency on the secondary clusters increases significantly. The GDN Multi-write Edition provides a table-level multi-write solution. This allows each cluster to perform local writes on tables for which it has write permissions, effectively reducing cross-region write latency. For more information, see GDN multi-write edition user guide. Note The PolarDB GDN Multi-write Edition is currently in canary release. To use this feature, search for the group number in DingTalk and join the group for inquiries. DingTalk group number: 30245017864

Use cases

Active geo-redundancy (multi-region deployment) Deploy your services across multiple regions. With features such as low-latency cross-region synchronization, cross-region read/write splitting, and local access, GDN ensures that database access latency for applications in each region is typically under 2 seconds. Typical industries: Gaming, cross-border e-commerce, local services (food delivery), and new retail (outlets). Business architecture: For optimal performance, applications in each region directly read from and write to the local database. Write requests are forwarded to the primary cluster for processing. In a GDN, each cluster, including the primary and secondary clusters, provides an independent cluster endpoint. You can connect to the nearest cluster endpoint based on where your application runs. The specifications of the secondary clusters in China (Beijing) and China (Shenzhen) must meet or exceed those of the primary cluster in China (Hangzhou). We recommend that you use the same specifications for optimal performance.

Geo-disaster recovery Use GDN to achieve cross-region high availability and improve data security and system availability. If the primary cluster's data center fails, you can restore service 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) and uses a dual-availability zone deployment, covering AZ1 and AZ2. The disaster recovery region is China (Shanghai) and uses a single-availability zone deployment. By default, the application performs local reads and writes on the database in AZ1 of the China (Beijing) region. If AZ1 fails, the system first switches over to AZ2 in Beijing. If both AZ1 and AZ2 fail, the system switches over to AZ3 in Shanghai. Note A primary/secondary switchover in a GDN can be completed within 10 minutes (tests show it takes less than 5 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 your application has a reconnection mechanism.

Benefits

• Cross-region deployment: Extend from a single-region deployment to a multi-region deployment without changing your application code.

• Cross-region read/write splitting and local access: 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: Asynchronous physical replication, based on redo log, and parallel replay technologies reduce the cross-region replication latency between the primary and secondary clusters. This ensures that data remains synchronized across all clusters with a replication latency of typically under two seconds, significantly reducing read latency for applications in remote regions.

Requirements and limitations

Pricing

Charges for a Global Database Network (GDN) consist of the cluster costs and any applicable cross-border data replication fees. The 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 China (Chengdu) and the secondary clusters are in regions such as China (Hangzhou) or China (Shenzhen).

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

• Billable scenarios:

  Cross-border fees apply when a GDN spans the Chinese mainland border—for example, if one cluster is in the Chinese mainland and another is in China (Hong Kong) or an 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 China (Chengdu) and the secondary cluster is in a region such as China (Hong Kong) or Singapore.

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

• Billing rule: CNY 5.6 per GB, billed hourly. The fee is calculated hourly based on the volume of redo log data physically replicated from the primary cluster to a cross-border secondary cluster. This traffic fee can be estimated 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. 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 648142342 bytes.
     
     
     
     

  Therefore, the total amount written is 425598148 + 1073741824 + 648142342 = 2147482314 bytes. This is 2147482314 / 1024 / 1024 / 1024 = 1.999998 GB (rounded down to six decimal places). The cross-border data transfer fee for this hour is approximately 1.999998 GB × CNY 5.6/GB = CNY 11.1999888.

  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 to serve 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 domain name. This feature provides local access and a stable endpoint that persists through a primary cluster switchover.

Contact us

If you have any questions about the Global Database Network (GDN) feature, join our DingTalk group by searching for the group number. In the group, you can directly ask questions or tag experts using @. The PolarDB intelligent assistant is also available 24/7 in the group to answer your questions.

DingTalk group number: 30245017864

Related videos

GDN