GDN for Multi-write - PolarDB - Centre de documentation Alibaba Cloud

Dans l'édition de base d'un Global Database Network (GDN), un cluster secondaire transfère les requêtes d'écriture au cluster principal. Ce processus peut entraîner une latence d'écriture importante lorsque les clusters sont géographiquement éloignés. Le GDN pour l'écriture multiple offre une solution d'écriture multiple au niveau des tables qui permet à chaque sous-cluster d'écrire localement dans les tables dont il détient les droits d'écriture. Cette conception facilite l'accès de proximité en lecture comme en écriture et réduit efficacement la latence d'écriture interrégionale.

Remarque

Le GDN PolarDB pour l'écriture multiple est actuellement en préversion publique. Pour utiliser cette fonctionnalité, rejoignez notre groupe DingTalk afin de demander l'accès.

Numéro du groupe DingTalk : 30245017864

Fonctionnement

Le GDN pour l'écriture multiple utilise la technologie de réplication physique de PolarDB pour offrir des capacités d'écriture multiple au niveau des tables dans les déploiements interrégionaux. Les mécanismes principaux sont les suivants :

Propriété des droits d'écriture au niveau de la table : Chaque table est strictement attribuée à un seul sous-cluster pour l'écriture. Ainsi, un unique sous-cluster peut écrire dans la table à tout moment.
Écritures locales : Chaque sous-cluster écrit localement dans les tables dont il détient les droits d'écriture. Cela garantit des mises à jour de données à faible latence et à haut débit.
Synchronisation globale des données : Toutes les modifications de données se synchronisent en temps réel avec les autres sous-clusters via une liaison de réplication physique haute performance, assurant ainsi la cohérence des données à l'échelle mondiale.
Lisibilité complète des données : Tous les sous-clusters lisent directement les données les plus récentes de toutes les tables, ce qui prend en charge l'accès en lecture locale dans des scénarios interrégionaux.

Prenons l'exemple de trois sous-clusters situés en Chine (Hong Kong), à Singapour et en Allemagne (Francfort) :

Vous créez la Table A dans le sous-cluster Chine (Hong Kong). Par défaut, les droits d'écriture sur cette table appartiennent au sous-cluster Chine (Hong Kong).
Vous créez la Table B dans le sous-cluster Singapour. Les droits d'écriture sur cette table reviennent au sous-cluster Singapour.
Vous créez la Table C dans le sous-cluster Allemagne (Francfort). Ce dernier détient alors les droits d'écriture sur cette table.

Toutes les opérations d'écriture sur la Table A dans le sous-cluster Chine (Hong Kong) s'appliquent directement aux données locales. Parallèlement, ce sous-cluster reçoit les modifications de données concernant la Table B et la Table C en temps réel depuis les sous-clusters Singapour et Allemagne (Francfort) par réplication physique. Par conséquent, le sous-cluster Chine (Hong Kong) peut non seulement écrire efficacement en local (Table A), mais aussi lire directement les données les plus récentes de toutes les tables (Table A, Table B et Table C). La même logique s'applique aux sous-clusters Singapour et Allemagne (Francfort).

Prérequis

Votre cluster PolarDB doit exécuter la version MySQL 8.0.2.

Créer un GDN pour l'écriture multiple

Demandez l'accès : Le GDN PolarDB pour l'écriture multiple est actuellement en préversion publique. Pour utiliser cette fonctionnalité, rejoignez notre groupe DingTalk afin de demander l'accès. Numéro du groupe DingTalk : 30245017864
Créer et gérer un Global Database Network : Sélectionnez un cluster répondant aux prérequis pour servir de cluster principal au Global Database Network (GDN).

Important
Lors de la création d'un GDN pour l'écriture multiple, le cluster principal redémarre une fois.
Ajouter et gérer un cluster secondaire : Accédez à la page d'achat PolarDB pour ajouter des clusters secondaires au GDN.
Se connecter à un Global Database Network : Dans un GDN, chaque sous-cluster (clusters principal et secondaires) fournit un endpoint de cluster indépendant. Connectez-vous à l'endpoint de cluster le plus proche selon la région de votre application. De plus, le GDN fournit un nom de domaine global qui permet non seulement un accès basé sur la proximité, mais reste également inchangé après un basculement du cluster principal.
Selon vos besoins métier, créez les tables nécessaires dans le sous-cluster d'une région spécifique. Chaque sous-cluster pourra ainsi écrire localement dans les tables dont il détient les droits d'écriture, permettant un accès de proximité pour les lectures et les écritures et réduisant efficacement la latence d'écriture interrégionale.

Gérer les droits d'écriture des tables

Lorsque vous créez une table sur un sous-cluster, celui-ci détient par défaut les droits d'écriture sur cette table. Un seul sous-cluster à la fois possède ces droits, tandis que tous les autres sous-clusters y ont uniquement un accès en lecture par défaut.

Transférer les droits d'écriture

Utilisez les instructions DDL suivantes pour transférer dynamiquement les droits d'écriture d'une table entre les sous-clusters :

Instruction

Description

ALTER TABLE <table_name> GDN_RELEASE;

Libère les droits d'écriture de la table du sous-cluster actuel. Après exécution, la table devient accessible en lecture seule sur le sous-cluster actuel.

ALTER TABLE <table_name> GDN_FETCH;

Acquiert les droits d'écriture de la table sur le sous-cluster actuel. Avant d'exécuter cette instruction, libérez les droits d'écriture du cluster d'origine.

Consulter la propriété des droits d'écriture

Examinez la sortie de l'instruction SHOW CREATE TABLE pour déterminer si le sous-cluster actuel détient les droits d'écriture sur une table :

Si la sortie contient le tag /* GDN_REMOTE */, les droits d'écriture de la table appartiennent à un autre sous-cluster et le sous-cluster actuel dispose uniquement d'un accès en lecture.
Si la sortie ne contient pas le tag /* GDN_REMOTE */, le sous-cluster actuel détient les droits d'écriture sur la table.

Exemple

L'exemple suivant montre comment transférer les droits d'écriture de la table t_A, initialement créée dans le sous-cluster Chine (Hong Kong), vers le sous-cluster Singapour.

Créez une table dans le sous-cluster Chine (Hong Kong) et confirmez la propriété de ses droits d'écriture.

-- 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

Libérez les droits d'écriture de la table dans le sous-cluster Chine (Hong Kong).

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

Acquérez les droits d'écriture de la table dans le sous-cluster Singapour.

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

Dans le sous-cluster Allemagne (Francfort), vérifiez la table pour confirmer qu'elle est toujours en lecture seule.

-- 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