PolarDB:Séparation lecture/écriture

Avantages

• Read Consistency

  Lorsqu'un client se connecte au backend via un endpoint de cluster, l'intergiciel de séparation lecture/écriture établit automatiquement des connexions avec le nœud principal et chaque nœud en lecture seule. Au sein d'une même connexion (session), l'intergiciel sélectionne le nœud le plus approprié en vérifiant l'état de synchronisation des données de chaque nœud de base de données. Cette approche garantit l'exactitude des résultats (les lectures après écriture renvoient les données attendues) tout en assurant l'équilibrage de charge des requêtes de lecture et d'écriture.

  

• Séparation lecture/écriture native pour de meilleures performances

  Si vous déployez votre propre couche proxy sur le cloud pour mettre en œuvre la séparation lecture/écriture, les requêtes traversent plusieurs composants pour l'analyse et le transfert SQL avant d'atteindre la base de données, ce qui augmente la latence. En revanche, la séparation lecture/écriture de PolarDB est intégrée directement dans le lien haute sécurité existant. Elle n'ajoute ni composant supplémentaire ni surcoût, réduisant ainsi la latence et améliorant le débit.

• Maintenance simplifiée

  Dans un modèle traditionnel, vous devez configurer les endpoints de connexion du nœud principal et de chaque nœud en lecture seule dans votre application. Vous devez également segmenter votre logique métier pour garantir l'envoi des requêtes d'écriture au nœud principal et des requêtes de lecture à tous les nœuds.

  PolarDB met à disposition un unique endpoint de cluster. Une fois votre application connectée à cet endpoint, elle peut lire et écrire sur les nœuds principaux et en lecture seule. Le routage des requêtes est automatique et totalement transparent, ce qui réduit les coûts de maintenance.

  Vous pouvez également augmenter la capacité de traitement en ajoutant des nœuds en lecture seule, sans modifier votre application.

• Contrôles de santé des nœuds pour une haute disponibilité

  Le module de séparation lecture/écriture vérifie automatiquement la santé de tous les nœuds du cluster. Si un nœud tombe en panne ou si sa latence dépasse un seuil spécifié, PolarDB cesse d'acheminer les requêtes de lecture vers ce nœud. Les requêtes sont alors réparties entre les nœuds sains restants. Cela garantit qu'une défaillance d'un seul nœud en lecture seule n'affecte pas votre application. Une fois le nœud rétabli, PolarDB le réintègre automatiquement dans le pool de routage.

• Gratuit, réduisant les coûts de ressources et de maintenance

  La fonctionnalité de séparation lecture/écriture est fournie sans coût supplémentaire.

Logique de routage des requêtes

En mode Read/Write, les requêtes sont routées comme suit :

• Acheminées uniquement vers le nœud principal :

  • Toutes les opérations DML (INSERT, UPDATE, DELETE et SELECT FOR UPDATE)

  • Toutes les opérations DDL (telles que la création ou la suppression de bases de données et de tables, la modification des schémas de table et la gestion des autorisations)

  • Toutes les requêtes au sein d'une transaction lorsque la division des transactions est désactivée

    Remarque

    Pour plus de détails sur le routage lorsque la division des transactions est activée, consultez la rubrique division des transactions.

  • Fonctions définies par l'utilisateur

  • Procédures stockées

  • Instructions LOCK/UNLOCK TABLES

  • Requêtes Multi-statement

  • Requêtes utilisant des tables temporaires

  • SELECT last_insert_id()

  • Toutes les requêtes et modifications de variables utilisateur

  • Requêtes binlog dump

• Acheminées vers les nœuds en lecture seule ou le nœud principal :

  Remarque

  Les requêtes sont acheminées vers le nœud principal uniquement si l'option Primary Node Accepts Read Requests est définie sur Yes.

  • Requêtes de lecture en dehors d'une transaction

  • Transactions en lecture seule (START TRANSACTION READ ONLY)

• Toujours acheminées vers tous les nœuds :

  • Toutes les modifications des variables système

  • La commande USE

  • Les commandes PREPARE et DEALLOCATE PREPARE

  • Commandes telles que COM_CHANGE_USER, COM_RESET_CONNECTION, COM_QUIT et COM_SET_OPTION

  • SHOW PROCESSLIST

    Remarque

    Lorsque vous exécutez la commande SHOW PROCESSLIST, PolarDB renvoie les informations de liste des processus de tous les nœuds.

  • KILL (l'instruction KILL en SQL, et non la commande KILL en ligne de commande)

En mode Read Only, les requêtes sont routées comme suit :

• Les opérations DDL et DML ne sont pas autorisées.

• Toutes les requêtes de lecture sont acheminées vers les nœuds en lecture seule via l'équilibrage de charge.

• Les requêtes de lecture ne sont jamais acheminées vers le nœud principal, même si celui-ci a été ajouté aux nœuds de service.

• PolarDB associe un binlog dump à un nœud en lecture seule spécifique.

Fonctionnalités