PolarDB:Consistency levels

Applicabilité

Le cluster doit contenir au moins un nœud en lecture seule (RO) pour que vous puissiez configurer les niveaux de cohérence dans la console. Si le cluster ne dispose d'aucun nœud en lecture seule, les paramètres de niveau de cohérence ne s'affichent pas dans la configuration du point de terminaison du cluster de la console.

Problèmes et solutions

Le proxy de répartition lecture/écriture de MySQL émule un serveur MySQL pour établir des connexions avec les applications. Le proxy analyse chaque instruction SQL reçue. Les opérations d'écriture telles que UPDATE, DELETE, INSERT et CREATE sont transférées vers le nœud principal, tandis que les instructions SELECT sont envoyées aux nœuds en lecture seule. Cela permet de mettre en œuvre la répartition lecture/écriture. Toutefois, lorsque la charge de la base de données est élevée, par exemple lors de l'exécution d'instructions DDL telles que l'ajout de colonnes sur de grandes tables ou l'insertion de grands volumes de données, des retards importants peuvent survenir, empêchant les nœuds en lecture seule de renvoyer les dernières données. Le proxy de répartition lecture/écriture de MySQL ne peut pas résoudre les incohérences de requête causées par les retards de réplication.

PolarDB utilise la réplication physique asynchrone pour synchroniser les données entre le nœud principal et les nœuds en lecture seule. Après la mise à jour des données sur le nœud principal, les modifications sont appliquées aux nœuds en lecture seule. Le délai de réplication dépend de la charge d'écriture et se situe généralement à l'échelle de la milliseconde. La réplication asynchrone garantit une cohérence à terme entre le nœud principal et les nœuds en lecture seule. PolarDB propose les quatre niveaux de cohérence suivants pour répondre à vos besoins dans différents scénarios :

• Cohérence à terme

• Cohérence de session

• Cohérence globale

• Cohérence globale (mode haute performance)

Cohérence à terme

• Présentation

  PolarDB utilise une architecture de répartition lecture/écriture. La répartition lecture/écriture traditionnelle offre uniquement une cohérence à terme. Les retards de réplication entre le nœud principal et les nœuds en lecture seule peuvent entraîner des résultats de requête différents selon les nœuds. Par exemple, si vous exécutez les requêtes suivantes consécutivement au sein d'une même session, le résultat final de l'instruction SELECT peut différer. Le résultat réel dépend du délai de réplication.

  INSERT INTO t1(id, price) VALUES(111, 96);
  UPDATE t1 SET price = 100 WHERE id=111;
  SELECT price FROM t1;

• Scénarios applicables

  Pour réduire la charge sur le nœud principal et acheminer autant de requêtes de lecture que possible vers les nœuds en lecture seule, optez pour la cohérence à terme.

Cohérence de session

• Présentation

  Pour résoudre le problème des résultats de requête incohérents causés par la cohérence à terme, vous devez généralement segmenter vos charges de travail : acheminez les requêtes nécessitant une forte cohérence directement vers le nœud principal, et dirigez celles qui tolèrent la cohérence à terme vers les nœuds en lecture seule via la répartition lecture/écriture. Cette approche augmente la charge sur le nœud principal, réduit l'efficacité de la répartition lecture/écriture et ajoute de la complexité au développement des applications.

  Pour remédier à cette situation, PolarDB propose la cohérence de session, également appelée cohérence causale. La cohérence de session garantit qu'au sein d'une même session, une requête de lecture renvoie toujours les données qui ont été mises à jour avant l'exécution de la lecture, assurant ainsi la monotonie des données.

  Bien que PolarDB effectue la répartition lecture/écriture au niveau du proxy, ce dernier suit les positions des journaux Redo appliquées sur chaque nœud, connues sous le nom de Log Sequence Number (LSN). À chaque mise à jour des données, PolarDB enregistre la position de mise à jour en tant que LSN de session. Lorsqu'une nouvelle requête arrive, PolarDB compare le LSN de session avec le LSN actuel de chaque nœud. Si le LSN d'un nœud en lecture seule ne satisfait pas l'exigence, le proxy attend que le nœud en lecture seule se synchronise avec les dernières données selon le délai d'attente configuré, et n'envoie la requête qu'aux nœuds dont le LSN est supérieur ou égal au LSN de session. Cela garantit la cohérence de session. Bien que cette approche puisse sembler augmenter la charge sur le nœud principal, PolarDB utilise la réplication physique, qui est extrêmement rapide.

  

  Dans le scénario précédent, après la finalisation d'une mise à jour et le renvoi du résultat au client, la réplication est déjà en cours. Lorsque la prochaine requête de lecture arrive, la réplication entre le nœud principal et les nœuds en lecture seule est très probablement déjà terminée. La plupart des scénarios d'application sont intensifs en lecture avec peu d'écritures. Les tests montrent que ce mécanisme assure à la fois la cohérence de session et un équilibrage de charge efficace pour la répartition lecture/écriture.

• Scénarios applicables

  Plus le niveau de cohérence de PolarDB est élevé, plus la charge sur le nœud principal est importante et plus les performances du cluster sont faibles. Nous vous recommandons d'utiliser la cohérence de session, qui a un impact minimal sur les performances et répond aux exigences de la plupart des scénarios d'application.

Cohérence globale

• Présentation

  Dans certains scénarios d'application, des dépendances existent non seulement au sein d'une session, mais aussi entre les sessions. Par exemple, lorsqu'un pool de connexions est utilisé, les requêtes provenant du même thread peuvent être envoyées via différentes connexions. Pour la base de données, ces requêtes appartiennent à des sessions différentes, mais elles présentent des dépendances séquentielles dans la logique métier. Dans ce cas, la cohérence de session ne peut pas garantir la cohérence des requêtes. Par conséquent, PolarDB propose la cohérence globale pour résoudre ce problème.

  

  Lorsque chaque requête de lecture atteint le proxy PolarDB, celui-ci vérifie d'abord le dernier LSN sur le nœud principal, supposé être LSN0. Pour réduire la surcharge liée à la récupération du dernier LSN depuis le nœud principal pour chaque requête de lecture, une optimisation interne par lots est utilisée. Le proxy attend ensuite qu'au moins un nœud en lecture seule mette à jour son LSN vers LSN0, et achemine la requête de lecture vers ce nœud en lecture seule. Cela garantit que la requête de lecture peut lire toutes les données qui ont été mises à jour jusqu'au moment où la requête a été initiée.

  La cohérence globale propose les deux paramètres de configuration suivants :

  Paramètre	Description
  ConsistTimeout	Global Consistency Timeout : durée maximale pendant laquelle une requête de lecture attend qu'un nœud en lecture seule synchronise son LSN. Si ce délai est dépassé, le proxy PolarDB effectue l'opération spécifiée par le paramètre ConsistTimeoutAction. Valeurs valides : 0 à 60000. Valeur par défaut : 20. Unité : millisecondes.
  ConsistTimeoutAction	Global Consistency Timeout Policy : si le LSN du nœud en lecture seule n'est pas mis à jour vers le dernier LSN du nœud principal dans le délai spécifié par le paramètre ConsistTimeout, le proxy PolarDB effectue l'opération spécifiée par le paramètre ConsistTimeoutAction. Valeurs valides : 0 (par défaut) : Envoie la requête de lecture au nœud principal. 1 : Le proxy renvoie un message d'erreur wait replication complete timeout, please retry à l'application.

  Remarque

  Pour savoir comment modifier Global Consistency Timeout et Global Consistency Timeout Policy, consultez Configurer le proxy de base de données.

• Scénarios applicables

  Lorsque le délai de réplication entre le nœud principal et les nœuds en lecture seule est élevé, l'utilisation de la cohérence globale peut entraîner l'acheminement d'un plus grand nombre de requêtes vers le nœud principal, augmentant ainsi la charge sur ce dernier et potentiellement la latence métier. Par conséquent, nous vous recommandons de choisir la cohérence globale dans les scénarios intensifs en lecture avec peu d'écritures.

Cohérence globale (mode haute performance)

PolarDB for MySQL propose le service de cohérence globale (mode haute performance). La cohérence globale (mode haute performance) offre une cohérence forte plus stricte que la cohérence globale.

Le système de transaction PolarTrans utilise Commit Timestamp Store (CTS) et les réseaux RDMA pour fournir des lectures à cohérence forte sur les nœuds RO au niveau du noyau. Cela garantit que les lectures renvoient toujours les dernières données des nœuds RW et RO, offrant ainsi des capacités de lecture à cohérence forte au niveau du cluster. Les requêtes de lecture envoyées à n'importe quel réplica du cluster renvoient des résultats fortement cohérents.

Pour plus de détails sur la cohérence globale (mode haute performance), tels que les limites d'utilisation, les principes techniques, la procédure d'activation et les données de performance, consultez Cohérence globale (mode haute performance).

Comment choisir un niveau de cohérence

• Plus le niveau de cohérence de PolarDB est élevé, plus les performances du cluster sont faibles.

  Nous recommandons la cohérence de session, qui a un impact minimal sur les performances et répond aux exigences de la plupart des scénarios d'application.

• Si vous avez des exigences élevées en matière de cohérence entre différentes sessions, choisissez l'une des options suivantes :

  • Choisissez la cohérence globale (mode haute performance) ou la cohérence globale.

    Remarque

    • Pour PolarDB for MySQL 5.7, 8.0.1 et 8.0.2, si vous avez besoin d'une cohérence forte stricte, la cohérence globale (mode haute performance) est recommandée.

    • Pour PolarDB for MySQL 5,6, si vous avez besoin d'une cohérence forte stricte, choisissez la cohérence globale car le mode haute performance n'est pas pris en charge dans cette version.

  • Utilisez un HINT pour forcer une requête spécifique vers le nœud principal.

    /*FORCE_MASTER*/ select * from user;

    Remarque

    • Si vous devez exécuter l'instruction hint précédente via le client en ligne de commande MySQL, ajoutez le paramètre -c. Sinon, le hint risque d'être filtré par le client en ligne de commande MySQL, ce qui entraînerait l'échec du hint. Pour plus d'informations, consultez Client en ligne de commande MySQL.

    • Les hints ont la priorité de routage la plus élevée et ne sont pas soumis aux contraintes de niveau de cohérence ou de fractionnement des transactions. Évaluez l'impact avant d'utiliser les hints.

    • N'incluez pas d'instructions modifiant les variables d'environnement dans les instructions hint, telles que /*FORCE_SLAVE*/ set names utf8;. De telles instructions peuvent provoquer des erreurs lors des opérations suivantes.

Comment définir le niveau de cohérence

• Pour définir le niveau de cohérence sur la cohérence globale (mode haute performance), consultez Activer SCC.

• Pour définir le niveau de cohérence sur la cohérence à terme, la cohérence de session ou la cohérence globale, consultez Configurer le proxy de base de données.

FAQ

Pourquoi ne puis-je pas voir les paramètres de cohérence dans la console ?

Les paramètres de cohérence s'affichent uniquement lorsque le cluster contient au moins un nœud en lecture seule (RO). Si votre cluster ne dispose d'aucun nœud en lecture seule, les paramètres de cohérence ne s'affichent pas dans la configuration du point de terminaison du cluster de la console. Ajoutez d'abord au moins un nœud en lecture seule au cluster. Ensuite, vous pourrez voir les paramètres de cohérence dans la configuration du point de terminaison du cluster. Pour savoir comment ajouter un nœud en lecture seule, consultez Ajouter ou supprimer des nœuds.