Lorsque la séparation lecture/écriture achemine les instructions SELECT vers des nœuds en lecture seule, ces derniers peuvent accuser un retard par rapport au nœud primaire en raison de la réplication asynchrone. PolarDB for PostgreSQL propose deux niveaux de cohérence — la cohérence à terme et la cohérence de session (aussi appelée cohérence de lecture au niveau transaction) — pour maîtriser la gestion de ce décalage de réplication par votre application.
Fonctionnement
PolarDB repose sur une architecture en cluster. Chaque cluster comprend un nœud primaire ainsi qu'un ou plusieurs nœuds en lecture seule. Connectez-vous au cluster via deux types d'endpoints :
Cluster endpoint (recommandé) : répartit le trafic sur l'ensemble des nœuds et active automatiquement la séparation lecture/écriture.
Primary endpoint : dirige tout le trafic exclusivement vers le nœud primaire.
La couche proxy intégrée assure la séparation lecture/écriture. Elle analyse chaque instruction SQL pour router les opérations d'écriture (INSERT, UPDATE, DELETE, CREATE) vers le nœud primaire et les opérations de lecture (SELECT) vers les nœuds en lecture seule.
La réplication des données du nœud primaire vers les nœuds en lecture seule repose sur une réplication physique asynchrone fondée sur le journal WAL (Write-Ahead Logging). Sous une charge normale, cette réplication s'achève en quelques millisecondes. Lorsque la charge est faible, la latence de synchronisation peut descendre sous les cinq secondes. En revanche, lors de charges importantes — comme des opérations DDL sur de grandes tables ou des insertions massives — cette latence risque d'augmenter considérablement.
Du fait de la nature asynchrone de la réplication, une requête SELECT dirigée vers un nœud en lecture seule est susceptible de renvoyer des données qui n'intègrent pas encore les dernières écritures du nœud primaire. Les deux niveaux de cohérence définissent la stratégie adoptée par PolarDB face à ce décalage.
Niveaux de cohérence
| Eventual consistency | Session consistency | |
|---|---|---|
| Comportement en lecture | Toute requête SELECT est immédiatement routée vers un nœud en lecture seule disponible, sans attendre la fin de la réplication. | La requête SELECT est transmise uniquement à un nœud en lecture seule ayant déjà répliqué les écritures de la session en cours. |
| Lectures obsolètes | Risque présent : le nœud peut ne pas disposer des données les plus récentes. | Impossible au sein d'une même session : les lectures reflètent systématiquement les écritures de cette session. |
| Performances | Débit légèrement supérieur grâce à l'absence de temps d'attente. | Surcharge négligeable pour la plupart des charges de travail. |
| Cas d'usage privilégiés | Analyses, rapports et charges dominées par les lectures, où un léger retard de réplication reste tolérable. | Charges transactionnelles nécessitant que les lectures intègrent les écritures récentes de la session. |
Cohérence à terme
En mode de cohérence à terme, le proxy dirige chaque requête SELECT vers n'importe quel nœud en lecture seule disponible, sans vérifier si celui-ci détient les données les plus récentes. Le nœud concerné retourne alors les résultats sans délai.
Par conséquent, une lecture suivant une écriture dans la même session risque de retourner des données périmées :
INSERT INTO t1(id, price) VALUES(111, 96);
UPDATE t1 SET price = 100 WHERE id=111;
SELECT price FROM t1;
-- May return 96 or NULL if the read-only node hasn't replicated the write yetPrivilégiez la cohérence à terme pour les charges de travail acceptant un court délai de réplication, telles que les tâches planifiées, les requêtes analytiques, les rapports agrégés ou encore l'accès en lecture seule par des utilisateurs n'effectuant aucune écriture.
Cohérence de session
Avec la cohérence de session, le proxy garantit qu'après une écriture au sein d'une session, toutes les lectures suivantes de cette même session sont dirigées uniquement vers des nœuds en lecture seule ayant déjà appliqué ces modifications. La requête SELECT est ainsi envoyée à un nœud conforme, assurant le retour de résultats actualisés.
Le même exemple produit alors un résultat prévisible :
INSERT INTO t1(id, price) VALUES(111, 96);
UPDATE t1 SET price = 100 WHERE id=111;
SELECT price FROM t1;
-- Returns 100, guaranteedLa cohérence de session engendre une surcharge minime pour la majorité des charges de travail et répond à l'essentiel des besoins transactionnels. Adoptez-la par défaut pour les applications où les utilisateurs doivent relire leurs propres écritures récentes.
Mécanisme de la cohérence de session
Le proxy suit la progression du journal redo sur chaque nœud au moyen d'un numéro de séquence de journal (LSN). Lorsqu'une écriture est validée sur le nœud primaire, le proxy enregistre le LSN correspondant en tant que LSN de session.
À la réception de la prochaine lecture de cette même session, le proxy compare le LSN de session avec celui de chaque nœud en lecture seule. Il transmet ensuite la requête à un nœud dont le LSN est supérieur ou égal au LSN de session, garantissant ainsi que l'écriture a bien été appliquée. Pendant que le nœud sélectionné renvoie les résultats au client, les autres nœuds poursuivent leur réplication en arrière-plan.
Ce mécanisme assure simultanément la cohérence de session, la séparation lecture/écriture et l'équilibrage de charge.
Bonnes pratiques
Adoptez la cohérence de session pour la plupart des charges de travail. Son impact sur les performances du cluster reste limité et elle gère efficacement le cas fréquent où une application relit des données qu'elle vient d'écrire.
Pour les requêtes exigeant la lecture des données absolument les plus récentes — indépendamment des limites de session — redirigez-les vers le nœud primaire à l'aide du hint FORCE_MASTER :
/*FORCE_MASTER*/ select * from user;Réservez l'usage de FORCE_MASTER à des requêtes spécifiques plutôt que de l'employer de manière systématique. Router toutes les lectures vers le nœud primaire annule les avantages de la séparation lecture/écriture et accroît la charge pesant sur ce nœud.