La fonctionnalité PolarDB for MySQL Multi-master Cluster (Limitless) fait évoluer l'architecture d'un cluster, passant d'un modèle à écriture unique et lecture multiple à un modèle à écritures multiples et lectures multiples. Elle permet des écritures de données concurrentes vers différentes bases de données ou objets de données sur différents nœuds de calcul. Elle prend également en charge la planification dynamique des bases de données et des objets de données entre les nœuds, avec des basculements effectués en quelques secondes, ce qui améliore considérablement la capacité globale de lecture et d'écriture concurrente du cluster. Les objets de données incluent les tables, les vues, les déclencheurs, les événements, les procédures stockées et les fonctions. Cette rubrique décrit comment utiliser un Multi-master Cluster (Limitless).
Prérequis
Vous avez acheté un cluster Multi-master Cluster (Limitless). Pour plus d'informations, consultez les rubriques Achat personnalisé et Acheter un cluster par abonnement.
Vous avez créé un compte privilégié. Pour plus d'informations, consultez la rubrique Créer un compte privilégié.
Vous vous êtes connecté au cluster de base de données. Pour plus d'informations, consultez la rubrique Se connecter à un cluster de base de données.
La version du noyau PolarDB for MySQL 8,0 ou ultérieure prend en charge Multi-master Cluster (Limitless).
Limitations
Les données de chaque base de données ou objet de données ne peuvent être écrites que via un seul nœud principal. Les nœuds auxquels aucune base de données ou objet de données n'est assigné ne peuvent pas lire ni écrire des données. Par défaut, les opérations s'effectuent au niveau de la base de données. Pour opérer au niveau de l'objet de données, vous devez utiliser une syntaxe spécifique pour changer de mode.
Les requêtes transversales entre plusieurs nœuds principaux ne sont pas prises en charge. Si une requête implique des bases de données ou des objets de données résidant sur différents nœuds principaux, le système renvoie une erreur. Nous vous recommandons de déplacer les endpoints de toutes les bases de données ou objets de données concernés vers un seul nœud principal avant d'exécuter la requête.
Seuls les endpoints de cluster, sont fournis. Les endpoints principaux ne sont pas pris en charge.
-
Le changement d'endpoint est soumis aux conditions suivantes :
Si vous utilisez le niveau d'isolation de la base de données, vous devez changer l'endpoint de la base de données.
Si vous utilisez le niveau d'isolation de l'objet de données, vous devez changer l'endpoint de l'objet de données.
-
Les opérations DDL transversales entre plusieurs nœuds principaux ne sont pas prises en charge. Si vous exécutez une instruction DDL sur une base de données ou un objet de données alors que la connexion actuelle est établie sur un nœud principal qui n'est pas le propriétaire de cette base de données ou de cet objet de données, le système renvoie l'erreur
Failed to get global lock for table 'xxx' on master N. Pour résoudre ce problème, procédez comme suit :-
Exécutez la commande suivante pour identifier le nœud principal propriétaire de la table cible :
SELECT * FROM INFORMATION_SCHEMA.INNODB_CC_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';Repérez le champ
master_idcorrespondant à la table cible dans le résultat de la requête. -
Exécutez la commande suivante pour basculer la session actuelle vers le nœud principal propriétaire de la table cible :
ALTER SESSION POLARDB_WRITE_NODE <master_id>;Remplacez
<master_id>par le numéro réel du nœud principal obtenu à l'étape précédente. Une fois le basculement terminé, réexécutez l'instruction DDL.
-
Spécifier un nœud principal pour une base de données
Créez une base de données sur un nœud principal spécifié. La syntaxe est la suivante :
CREATE DATABASE name [POLARDB_WRITE_NODE master_id];Lorsque vous utilisez le niveau d'isolation de la base de données, les données de chaque base de données ne peuvent être écrites que via un seul nœud principal.
Si vous omettez
[POLARDB_WRITE_NODE master_id]dans la syntaxe, le système utilise la valeur du paramètre loose_innodb_mm_default_master_id pour spécifier le nœud principal lors de la création de la base de données. Lorsque la valeur du paramètre loose_innodb_mm_default_master_id est 0, le système sélectionne aléatoirement un nœud principal pour créer la base de données. Accédez à la console PolarDB et accédez à la page pour afficher et modifier les paramètres du cluster ou des nœuds.Pour afficher la distribution des bases de données sur les nœuds, consultez la section Interroger la distribution des bases de données.
Exemple : Créez une base de données nommée db1 sur le nœud principal 1.
CREATE DATABASE db1 POLARDB_WRITE_NODE 1;Pour créer la base de données db1 sur le nœud principal 2, remplacez 1 par 2 dans l'instruction précédente.
Supprimer une base de données
Pour supprimer une base de données créée sur un nœud principal spécifié, utilisez la syntaxe suivante :
DROP DATABASE name;Exemple : Supprimez la base de données db1 qui a été créée sur le nœud principal 1.
DROP DATABASE db1;Il n'est pas nécessaire de spécifier le nœud principal lors de la suppression d'une base de données.
Changer l'endpoint d'une base de données
Pour changer l'endpoint de la base de données vers un autre nœud principal, utilisez la syntaxe suivante :
ALTER DATABASE name POLARDB_WRITE_NODE master_id;Exemple : Changez l'endpoint de la base de données db1 vers le nœud principal 2.
ALTER DATABASE db1 POLARDB_WRITE_NODE 2;Le changement d'endpoint peut être une opération longue. Le temps d'exécution dépend des facteurs suivants :
Plus la base de données contient de tables, plus le basculement est lent.
Plus la charge de travail DML sur la base de données est importante pendant le basculement, plus l'opération est lente.
Basculer vers l'isolation par objet de données
Par défaut, le niveau d'isolation d'un cluster multi-principal est au niveau de la base de données. Cela signifie que tous les objets de données d'une même base de données ne sont accessibles que sur un seul nœud principal. Si vous souhaitez que tous les objets de données d'une même base de données soient accessibles via plusieurs nœuds principaux, vous devez passer du niveau d'isolation de la base de données au niveau d'isolation de l'objet de données. La syntaxe est la suivante :
ALTER DATABASE name TO TABLE_LOCK POLARDB_WRITE_NODE master_id;Dans cette instruction, name spécifie le nom de la base de données et master_id spécifie l'endpoint de l'objet de données.
Exemple : Modifiez le niveau d'isolation de la base de données db1 pour passer au niveau d'isolation par objet de données et définissez son endpoint sur le nœud principal 2.
ALTER DATABASE db1 TO TABLE_LOCK POLARDB_WRITE_NODE 2;Le changement de niveau d'isolation peut être une opération longue. Le temps d'exécution dépend des facteurs suivants :
Plus la base de données contient d'objets, plus le basculement est lent.
Plus la charge de travail DML sur la base de données est importante pendant le basculement, plus l'opération est lente.
Basculer vers l'isolation par base de données
Si une base de données est configurée avec le niveau d'isolation par objet de données, vous pouvez revenir au niveau d'isolation par base de données pour faciliter la gestion. Utilisez l'instruction suivante :
ALTER DATABASE name TO DB_LOCK POLARDB_WRITE_NODE master_id;Dans cette instruction, name spécifie le nom de la base de données et master_id spécifie l'endpoint de la base de données.
Exemple : Remettez le niveau d'isolation de la base de données db1 au niveau d'isolation par base de données et définissez son endpoint sur le nœud principal 1.
ALTER DATABASE db1 TO DB_LOCK POLARDB_WRITE_NODE 1;Le changement de niveau d'isolation peut être une opération longue. Le temps d'exécution dépend des facteurs suivants :
Plus la base de données contient d'objets, plus le basculement est lent.
Plus la charge de travail DML sur la base de données est importante pendant le basculement, plus l'opération est lente.
Changer l'endpoint d'un objet de données
Lorsqu'un cluster est au niveau d'isolation par objet de données, une base de données peut contenir divers types d'objets, notamment des tables, des vues, des déclencheurs, des fonctions, des procédures stockées et des événements. Pour changer l'endpoint de ces objets, utilisez la syntaxe suivante :
ALTER obj_type name POLARDB_WRITE_NODE master_id;Dans cette instruction, obj_type peut être TABLE, VIEW, TRIGGER, FUNCTION, PROCEDURE ou EVENT. name est le nom de l'objet de données.
Exemple 1 : Changez l'endpoint de la table t1 dans la base de données db1 vers le nœud principal 3.
ALTER TABLE db1.t1 POLARDB_WRITE_NODE 3;Exemple 2 : Changez l'endpoint de la vue t2 dans la base de données actuelle vers le nœud principal 2.
ALTER VIEW t2 POLARDB_WRITE_NODE 2;Exemple 3 : Changez l'endpoint des fonctions f1 et f2 dans la base de données db2 vers le nœud principal 1.
ALTER FUNCTION db2.f1, db2.f2 POLARDB_WRITE_NODE 1;Le changement d'endpoint peut être une opération longue. Le temps d'exécution dépend des facteurs suivants :
Plus la charge de travail DML sur l'objet de données est importante pendant le basculement, plus l'opération est lente.
-
Les objets ayant des dépendances peuvent devenir invalides s'ils ne se trouvent pas sur le même nœud principal.
Par exemple, une vue nommée
VIEW1dépend d'une table nomméet1. Si l'endpoint deVIEW1se trouve sur le nœud principal 1 et celui det1sur le nœud principal 2, une erreur se produit lorsque vous interrogezVIEW1sur le nœud principal 1. De même, les appels à une fonction, une procédure stockée ou un événement échouent si les objets qu'ils référencent se trouvent sur différents nœuds principaux. Un déclencheur échoue également à modifier une table si leurs endpoints se trouvent sur des nœuds différents. Si une contrainte de clé étrangère existe entre deux tables, telles que
t1ett2, la modification de l'endpoint d'une table modifie automatiquement l'endpoint de l'autre.
Spécifier un nœud principal pour SQL
Cette fonctionnalité s'applique uniquement aux requêtes de métadonnées, telles que les requêtes sur information_schema ou les variables d'état. Si vous devez interroger des données, par exemple en exécutant SELECT * FROM table1, il n'est pas nécessaire de spécifier un nœud principal, car le proxy de base de données achemine automatiquement la requête vers le nœud principal correct.
Pour envoyer une instruction SQL à un nœud principal spécifique, exécutez l'instruction SQL suivante pour verrouiller la session sur ce nœud :
ALTER SESSION POLARDB_WRITE_NODE master_id;Exemple : Interrogez la valeur de la variable innodb_buffer_pool_size sur le nœud principal 1.
ALTER SESSION POLARDB_WRITE_NODE 1; # Send the SQL statement to primary node 1.
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; # Query the value of innodb_buffer_pool_size on primary node 1.Si vous ne spécifiez pas de nœud principal lors de l'exécution d'une instruction SQL, le proxy de base de données sélectionne aléatoirement un nœud principal pour exécuter l'instruction.
Exécutez la commande suivante pour déverrouiller la session du nœud principal spécifié :
RESET SESSION POLARDB_WRITE_NODE;Interroger la distribution des bases de données
Dans la console PolarDB, accédez à la page pour afficher la distribution de toutes les bases de données dans le cluster. La colonne MasterID affiche le numéro du nœud RW auquel chaque base de données appartient (par exemple, MasterID 1 indique que la base de données se trouve sur le nœud RW1, et MasterID 2 indique qu'elle se trouve sur le nœud RW2).
-
Exécutez les commandes suivantes pour interroger la distribution des bases de données sur un nœud principal spécifique :
ALTER SESSION POLARDB_WRITE_NODE master_id; SELECT * FROM INFORMATION_SCHEMA.INNODB_MASTER_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';Exemple : Interrogez la distribution des bases de données sur le nœud principal 1.
ALTER SESSION POLARDB_WRITE_NODE 1; SELECT * FROM INFORMATION_SCHEMA.INNODB_MASTER_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';Le résultat suivant est renvoyé :
SELECT * FROM INFORMATION_SCHEMA.INNODB_MASTER_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X'; +------------+---------------------+----------+--------------+-----------+----------+-------------+-------------+---------------------+-----------------+ | table_name | table_id | space_id | s_lock_count | lock_mode | object | current_lsn | hold_thread | hold_start_time | hold_total_time | +------------+---------------------+----------+--------------+-----------+----------+-------------+-------------+---------------------+-----------------+ | test3/f1 | 9149389368458135753 | 0 | 0 | SLS_X | function | 28076635 | 17 | 2024-07-10 21:35:20 | 214 | | test3/e1 | 9149389368458332874 | 0 | 0 | SLS_X | event | 28077248 | 17 | 2024-07-10 21:35:30 | 204 | | test3/v1 | 9149389368457234649 | 0 | 0 | SLS_X | view | 28075972 | 17 | 2024-07-10 21:35:08 | 226 | | sbtest | 2107518311328629409 | 0 | 0 | SLS_X | db | 28034927 | 4294967295 | 2024-07-07 23:04:41 | 254053 | | test | 7190879906290573778 | 0 | 0 | SLS_X | db | 28034927 | 4294967295 | 2024-07-10 11:20:57 | 37077 | | test2 | 3381728963524265351 | 0 | 0 | SLS_X | db | 28034927 | 4294967295 | 2024-07-10 11:13:09 | 37545 | +------------+---------------------+----------+--------------+-----------+----------+-------------+-------------+---------------------+-----------------+ 6 rows in set (0.00 sec)Bien que la colonne soit nommée
table_name, chaque ligne du résultat contient des informations sur une base de données ou un objet de données. Dans cet exemple,sbtest,testettest2utilisent le niveau d'isolation par base de données. Les objetstest3/f1,test3/e1ettest3/v1utilisent le niveau d'isolation par objet de données. Le résultat peut également contenir un objet nommé mysql/global_ddl_lock avec un type d'objet table. Cet objet est utilisé en interne et peut être ignoré. -
Exécutez la commande suivante pour interroger la distribution de toutes les bases de données dans le cluster :
RemarqueCette requête ne peut être exécutée qu'à l'aide d'un compte privilégié.
SELECT * FROM INFORMATION_SCHEMA.INNODB_CC_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';Le résultat suivant est renvoyé :
mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_CC_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X'; +-----------+------------+---------------------+-----------+-----------+-------------+---------------------+-----------------+ | master_id | table_name | table_id | lock_mode | object | current_lsn | hold_start_time | hold_total_time | +-----------+------------+---------------------+-----------+-----------+-------------+---------------------+-----------------+ | 1 | test3/v1 | 9149389368457234649 | SLS_X | view | 28075972 | 2024-07-10 21:35:08 | 754 | | 2 | test5/t1 | 9149389447232697561 | SLS_X | table | 7256175 | 2024-07-10 21:46:36 | 66 | | 1 | test2 | 3381728963524265351 | SLS_X | db | 28034927 | 2024-07-10 11:13:09 | 38073 | | 2 | test4 | 3381728963524272009 | SLS_X | db | 7255352 | 2024-07-10 21:46:27 | 75 | | 1 | test3/f1 | 9149389368458135753 | SLS_X | function | 28076635 | 2024-07-10 21:35:20 | 742 | | 1 | test3/e1 | 9149389368458332874 | SLS_X | event | 28077248 | 2024-07-10 21:35:30 | 732 | | 1 | test | 7190879906290573778 | SLS_X | db | 28034927 | 2024-07-10 11:20:57 | 37605 | | 2 | test5/p1 | 9149389447233473757 | SLS_X | procedure | 7257051 | 2024-07-10 21:46:45 | 57 | | 1 | sbtest | 2107518311328629409 | SLS_X | db | 28034927 | 2024-07-07 23:04:41 | 254581 | +-----------+------------+---------------------+-----------+-----------+-------------+---------------------+-----------------+ 9 rows in set (0.00 sec)Bien que la colonne soit nommée
table_name, chaque ligne du résultat contient des informations sur une base de données ou un objet de données et son nœud principal correspondant. Le résultat peut également contenir un objet nommé mysql/global_ddl_lock avec un type d'objet table. Cet objet est utilisé en interne et peut être ignoré.
Configurer le journal binaire
Multi-master Cluster (Limitless) est entièrement compatible avec le journal binaire MySQL. Il consolide les journaux d'opérations de tous les nœuds principaux du cluster pour générer un journal binaire globalement unifié et ordonné logiquement.
Vous pouvez utiliser loose_polar_log_bin pour activer la fonctionnalité de journal binaire pour un Multi-master Cluster (Limitless) et binlog_expire_logs_seconds pour définir la période de rétention des journaux binaires du Multi-master Cluster (Limitless). Pour plus d'informations, consultez la rubrique Activer les journaux binaires.
Multi-master Cluster (Limitless) peut être utilisé comme source et destination pour Data Transmission Service (DTS) afin d'effectuer une synchronisation de données unidirectionnelle ou bidirectionnelle.