Mise à l’échelle des lectures avec Hot Standby et l’équilibrage de charge
Apprenez à déporter le trafic de lecture vers des répliques en attente alimentées par flux, à comprendre le retard de réplication et à répartir les requêtes entre le serveur principal et les répliques pour mettre les lectures à l’échelle horizontalement.
Mise à l’échelle des lectures avec Hot Standby et l’équilibrage de charge est une leçon PostgreSQL Performance & Query Optimization gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage PostgreSQL Performance & Query Optimization, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours PostgreSQL Performance & Query Optimization comprend 4 leçons au total.
Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.
Why Scale Reads?
A single primary can become a bottleneck when read-heavy traffic grows. By sending SELECTs to read replicas, you free the primary to handle writes and scale reads horizontally by adding more standbys.
Hot Standby Basics
A hot standby is a streaming replica that accepts read-only queries while it continuously applies changes received from the primary. It stays nearly in sync via the write-ahead log (WAL).
Enabling Read Queries on a Standby
On the standby, hot_standby must be on (the default in modern versions) so it answers queries instead of just replaying WAL silently.
SHOW hot_standby;Detecting Recovery Mode
Your application can ask any node whether it is a read-only standby. A true result means do not send writes here.
SELECT pg_is_in_recovery();Understanding Replication Lag
Standbys apply WAL slightly behind the primary, so a read may not see the very latest write. This gap is replication lag. For most read traffic it is harmless, but read-after-write flows need care.
Measuring Lag
On a standby, compare how far replay is behind the last received WAL position to estimate lag in time.
SELECT now() - pg_last_xact_replay_timestamp() AS replay_lag;Routing in the Application
The simplest pattern keeps two connection pools: one to the primary for writes, one to replicas for reads. The app chooses based on the operation.
Read-After-Write Consistency
Right after a user writes data, reading from a lagging replica may show stale results. Mitigations:
- Route that user's next reads to the primary briefly
- Wait until the replica catches up to the write's WAL position
Load Balancing Across Replicas
A pooler or proxy such as PgBouncer, Pgpool-II, or HAProxy can distribute read connections across several standbys, spreading load and providing failover if one replica goes down.
Trade-offs and Limits
Read replicas are powerful but not magic:
- They do not scale write throughput
- Lag means eventual, not immediate, consistency on replicas
- Long queries on a standby can conflict with WAL replay
Plan routing around these realities.
Watching Replication from the Primary
The primary exposes every connected standby in a stats view, including how far behind each one is. Watch this to catch a replica falling dangerously behind.
SELECT client_addr, state,
replay_lag
FROM pg_stat_replication;Quick Check
Test your read-scaling knowledge.
Recap
You learned read scaling:
- Hot standbys serve read-only queries while replaying WAL
pg_is_in_recovery()identifies a standby- Replication lag means replicas can be slightly stale
- Route writes to primary, reads to replicas; handle read-after-write
- Use a proxy to load-balance and fail over across replicas
Questions Fréquemment Posées
La leçon « Mise à l’échelle des lectures avec Hot Standby et l’équilibrage de charge » est-elle gratuite ?
Oui — le texte complet de « Mise à l’échelle des lectures avec Hot Standby et l’équilibrage de charge » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours PostgreSQL Performance & Query Optimization, passe à CoddyKit PRO. Le cours PostgreSQL Performance & Query Optimization comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Mise à l’échelle des lectures avec Hot Standby et l’équilibrage de charge » ?
Apprenez à déporter le trafic de lecture vers des répliques en attente alimentées par flux, à comprendre le retard de réplication et à répartir les requêtes entre le serveur principal et les réplique… Tu pratiques PostgreSQL Performance & Query Optimization avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer PostgreSQL Performance & Query Optimization ?
Aucune expérience préalable n'est requise. PostgreSQL Performance & Query Optimization sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.
Combien de temps prend la leçon « Mise à l’échelle des lectures avec Hot Standby et l’équilibrage de charge » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon PostgreSQL Performance & Query Optimization ?
Oui. Chaque leçon PostgreSQL Performance & Query Optimization inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Regroupement des connexions avec PgBouncer
- Stratégies de réplication (en continu, logique)
- Partitionnement horizontal et PostgreSQL distribué
- Mise à l’échelle des lectures avec Hot Standby et l’équilibrage de charge