0Pricing
PostgreSQL Performance & Query Optimization · レッスン

Hot Standbyと負荷分散による読み取りスケーリング

ストリーミングレプリカのスタンバイに読み取りトラフィックを分散し、レプリケーション遅延を理解し、水平読み取りスケーリングのためにプライマリとレプリカ間でクエリを振り分ける方法を学びます。

「Hot Standbyと負荷分散による読み取りスケーリング」はCoddyKit上の無料PostgreSQL Performance & Query Optimizationレッスンです。 これはレッスン4/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはPostgreSQL Performance & Query Optimization学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 PostgreSQL Performance & Query Optimizationコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

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

よくある質問

「Hot Standbyと負荷分散による読み取りスケーリング」レッスンは無料ですか？

はい。「Hot Standbyと負荷分散による読み取りスケーリング」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、PostgreSQL Performance & Query Optimizationコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 PostgreSQL Performance & Query Optimizationコースには全4レッスンが含まれています。

「Hot Standbyと負荷分散による読み取りスケーリング」で何を学びますか？

ストリーミングレプリカのスタンバイに読み取りトラフィックを分散し、レプリケーション遅延を理解し、水平読み取りスケーリングのためにプライマリとレプリカ間でクエリを振り分ける方法を学びます。 ブラウザで直接実行するハンズオンコードでPostgreSQL Performance & Query Optimizationを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

PostgreSQL Performance & Query Optimizationを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのPostgreSQL Performance & Query Optimizationは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン4/4です。

「Hot Standbyと負荷分散による読み取りスケーリング」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このPostgreSQL Performance & Query Optimizationレッスンでコードを書いて実行できますか？

はい。すべてのPostgreSQL Performance & Query Optimizationレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. PgBouncer によるコネクションプーリング
  2. レプリケーション戦略（ストリーミング、論理）
  3. シャーディングと分散 PostgreSQL
  4. Hot Standbyと負荷分散による読み取りスケーリング
← PostgreSQL Performance & Query Optimizationに戻る