0Pricing
PostgreSQL Performance & Query Optimization · Lezione

Scalare le letture con Hot Standby e bilanciamento del carico

Impari a scaricare il traffico di lettura sulle repliche streaming in standby, comprendere il ritardo di replica e instradare le query tra primary e repliche per scalare orizzontalmente le letture.

Scalare le letture con Hot Standby e bilanciamento del carico è una lezione PostgreSQL Performance & Query Optimization gratuita su CoddyKit. Questa è la lezione 4 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento PostgreSQL Performance & Query Optimization, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso PostgreSQL Performance & Query Optimization include 4 lezioni in totale.

Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.

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

Domande Frequenti

La lezione «Scalare le letture con Hot Standby e bilanciamento del carico» è gratuita?

Sì — il testo completo di «Scalare le letture con Hot Standby e bilanciamento del carico» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso PostgreSQL Performance & Query Optimization, passa a CoddyKit PRO. Il corso PostgreSQL Performance & Query Optimization include 4 lezioni in totale.

Cosa imparerò in «Scalare le letture con Hot Standby e bilanciamento del carico»?

Impari a scaricare il traffico di lettura sulle repliche streaming in standby, comprendere il ritardo di replica e instradare le query tra primary e repliche per scalare orizzontalmente le letture. Eserciti PostgreSQL Performance & Query Optimization con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare PostgreSQL Performance & Query Optimization?

Non è richiesta alcuna esperienza precedente. PostgreSQL Performance & Query Optimization su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 4 di 4.

Quanto tempo richiede la lezione «Scalare le letture con Hot Standby e bilanciamento del carico»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione PostgreSQL Performance & Query Optimization?

Sì. Ogni lezione PostgreSQL Performance & Query Optimization include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Connection pooling con PgBouncer
  2. Strategie di replica (streaming, logica)
  3. Sharding e PostgreSQL distribuito
  4. Scalare le letture con Hot Standby e bilanciamento del carico
← Torna a PostgreSQL Performance & Query Optimization