PolarDB:Global Database Network (GDN)

Introduction

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. Below is an example where data is synchronized across all clusters over low-latency links, forming a single logical database:

Use cases

Active geo-redundancy (multi-region deployment) You can deploy your services across multiple regions. GDN's features, such as low-latency cross-region synchronization, cross-region read/write splitting, and nearest access, ensure that applications in each region achieve database access latency of less than 2 seconds. Typical industries: Gaming, cross-border e-commerce, local services (food delivery), and new retail (outlets). Business architecture: Applications in each region directly read from and write to the local database for optimal performance. 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 endpoint of the nearest cluster based on your application's region to access the database. The specifications of the secondary clusters in Beijing and Shenzhen must be greater than or equal to those of the primary cluster in Hangzhou. For best results, use the same specifications.

Geo-disaster recovery You can achieve cross-region high availability with GDN to improve data security and system availability. If the data center where the primary cluster is located fails, you can quickly restore your services by manually switching to a secondary cluster. GDN supports various architectures, such as a two-region three-data-center architecture. Typical industries: Banking, securities, and insurance. Business architecture (example: two-region three-data-center architecture): The Beijing region is the primary region and uses a dual-zone deployment, covering AZ1 and AZ2. The Shanghai region is the disaster recovery region and uses a single-zone deployment. By default, the application performs local reads and writes on the database in AZ1 of the 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 is typically completed in less than 5 minutes, but can take up to 10 minutes. During the switchover, a transient connection interruption 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: Extend from a single-city deployment to a multi-region deployment without changing your application code.

• Cross-region read/write splitting and nearest access: Read requests within the GDN are sent directly to the secondary cluster in the current region. 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 keep the cross-region replication delay between the primary and secondary clusters to less than 2 seconds. This significantly reduces read latency for applications that access data from non-central regions.

Scope

Pricing

When you use a GDN, you are charged for the clusters and any inter-region data transfer fees. Data transfer fees vary based on whether the transfer is cross-border.

• Non-cross-border data transfer (Free)

  • Scenario: The primary and secondary clusters are both deployed in regions outside the Chinese mainland, or both are deployed in regions within the Chinese mainland.

  • Billing rule: Free.

• Cross-border data transfer (Billable)

  Important

  Cross-border data transfer fees will be charged starting from 00:00 on January 1, 2026 (Singapore time). Before this date, this service is free.

  • Scenario: One of your clusters (primary or secondary) is deployed in a region outside the Chinese mainland, and the other is deployed in a region in the Chinese mainland.

  • Billing rule: 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-border secondary cluster within one hour. You can estimate this traffic fee by querying the physical position converted from the log sequence number (LSN).

    Click to view a billing example

    Example

    For example, at 09:00, you query the physical write position of the log and 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 648142342 bytes.

    Therefore, the total amount written = 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 × 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 domain name. This feature not only enables nearest access but also ensures the domain name remains unchanged after a primary cluster switchover.