GDN for Multi-write - PolarDB - Alibaba Cloud Documentation Center

In the basic edition of a Global Database Network (GDN), a secondary cluster forwards write requests to the primary cluster. This process can result in significant write latency when the clusters are physically distant. GDN for Multi-write provides a table-level multi-write solution that allows each sub-cluster to write locally to tables for which it has write permission. This design enables proximity-based access for both reads and writes, effectively reducing cross-region write latency.

Note

PolarDB GDN for Multi-write is currently in public preview. To use this feature, join our DingTalk group to request access.

DingTalk group number: 30245017864

How it works

GDN for Multi-write uses PolarDB's physical replication technology to provide table-level multi-write capabilities for cross-region deployments. The core mechanisms are as follows:

Table-level write permission ownership: The write permission for each table is strictly assigned to a single sub-cluster. This ensures that only one sub-cluster can write to the table at any given time.
Local writes: Each sub-cluster can write locally to tables for which it holds the write permission. This enables low-latency, high-throughput data updates.
Global data synchronization: All data changes are synchronized in real time with other sub-clusters through a high-performance physical replication link, which ensures global data consistency.
Full data readability: All sub-clusters can directly read the latest data from all tables, supporting local read access in cross-region scenarios.

Consider an example with three sub-clusters in China (Hong Kong), Singapore, and Germany (Frankfurt):

You create Table A in the China (Hong Kong) sub-cluster. The write permission for this table belongs to the China (Hong Kong) sub-cluster by default.
You create Table B in the Singapore sub-cluster. The write permission for this table belongs to the Singapore sub-cluster.
You create Table C in the Germany (Frankfurt) sub-cluster. The write permission for this table belongs to the Germany (Frankfurt) sub-cluster.

All write operations on Table A in the China (Hong Kong) sub-cluster are applied directly to local data. At the same time, this sub-cluster receives data changes for Table B and Table C in real time from the Singapore and Germany (Frankfurt) sub-clusters through physical replication. Therefore, the China (Hong Kong) sub-cluster can not only efficiently write locally (Table A) but also directly read the latest data from all tables (Table A, Table B, and Table C). The same principle applies to the Singapore and Germany (Frankfurt) sub-clusters.

Prerequisites

Your PolarDB cluster must be running MySQL 8.0.2.

Create a GDN for Multi-write

Request access: PolarDB GDN for Multi-write is currently in public preview. To use this feature, join our DingTalk group to request access. DingTalk group number: 30245017864
Create and manage a Global Database Network: Select a cluster that meets the prerequisites to be the primary cluster of the Global Database Network (GDN).
Important
When you create a GDN for Multi-write, the primary cluster restarts once.
Add and manage a secondary cluster: Go to the PolarDB purchase page to add secondary clusters to the GDN.
Connect to a Global Database Network: In a GDN, each sub-cluster (primary and secondary clusters) provides an independent cluster endpoint. You can connect to the nearest cluster endpoint based on your application's region. In addition, the GDN provides a global domain name, which not only enables proximity-based access but also remains unchanged after a primary cluster switchover.
Based on your business requirements, create the necessary tables in the sub-cluster of a specific region. This allows each sub-cluster to write locally to tables for which it holds the write permission, enabling proximity-based access for reads and writes and effectively reducing cross-region write latency.

Manage table write permissions

When you create a table on a sub-cluster, that sub-cluster holds the write permission for the table by default. The write permission for each table is held by only one sub-cluster at a time, while all other sub-clusters have read-only access to it by default.

Transfer write permissions

Use the following DDL statements to dynamically transfer the write permission for a table between sub-clusters:

Statement	Description
`ALTER TABLE <table_name> GDN_RELEASE;`	Releases the write permission for the table from the current sub-cluster. After execution, the table becomes read-only on the current sub-cluster.
`ALTER TABLE <table_name> GDN_FETCH;`	Acquires the write permission for the table on the current sub-cluster. Before you run this statement, you must release the write permission from the original cluster.

View write permission ownership

You can check the output of the SHOW CREATE TABLE statement to determine whether the current sub-cluster holds the write permission for a table:

If the output contains the /* GDN_REMOTE */ tag, the write permission for the table belongs to another sub-cluster, and the current sub-cluster has only read-only access.
If the output does not contain the /* GDN_REMOTE */ tag, the current sub-cluster holds the write permission for the table.

Example

The following example demonstrates how to transfer the write permission for table t_A, which was created in the China (Hong Kong) sub-cluster, to the Singapore sub-cluster.

Create a table in the China (Hong Kong) sub-cluster and confirm its write permission ownership.

-- Create a table in the China (Hong Kong) sub-cluster.
CREATE TABLE t_A (id INT PRIMARY KEY);

-- Check the table schema. The output does not contain the GDN_REMOTE tag, which indicates that the write permission is held by the current sub-cluster.
SHOW CREATE TABLE t_A\G
Create Table: CREATE TABLE `t_A` (
  `id` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

Release the write permission for the table in the China (Hong Kong) sub-cluster.

ALTER TABLE t_A GDN_RELEASE;

-- Check again. The output contains the GDN_REMOTE tag, which indicates that the write permission has been released.
SHOW CREATE TABLE t_A\G
Create Table: CREATE TABLE `t_A` (
  `id` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) /* GDN_REMOTE */ ENGINE=InnoDB DEFAULT CHARSET=utf8

Acquire the write permission for the table in the Singapore sub-cluster.

ALTER TABLE t_A GDN_FETCH;

-- Check the table schema. The output does not contain the GDN_REMOTE tag, which indicates that the write permission has been transferred to the current sub-cluster.
SHOW CREATE TABLE t_A\G
Create Table: CREATE TABLE `t_A` (
  `id` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

In the Germany (Frankfurt) sub-cluster, check the table to confirm that it is still read-only.

-- The output contains the GDN_REMOTE tag, which indicates that the write permission is not held by the current sub-cluster.
SHOW CREATE TABLE t_A\G
Create Table: CREATE TABLE `t_A` (
  `id` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) /* GDN_REMOTE */ ENGINE=InnoDB DEFAULT CHARSET=utf8