Building a replicated cluster

Replication on the administrator's side: a standby by streaming replication, synchronous or asynchronous mode, lag monitoring, failover, split brain, quorum, witness and replication slots.

  • 25 cards
  • 7 topics
  • Free

The outline, topic by topic

Each topic is weighted the way the exam weighs it.

  1. Concepts
  2. Questions
  3. Sort and link
  4. The numbers
  5. On the diagram
  6. Scenarios
  7. Understand

A few cards from the deck

  • Standby server: what is it?

    Show the answer

    A copy of a primary that continuously receives its WAL, replays it and can answer reads, ready to take the primary's place.

    A standby.signal file in the data directory and a primary_conninfo pointing to the primary are enough to start it as a standby.

  • Here is pg_stat_replication on the primary. Which server can be promoted without losing a committed write?

    ```text
    application_name | state | sync_state | replay_lag
    -----------------+-----------+------------+----------------
    secours1 | streaming | sync | 00:00:00.000412
    secours2 | streaming | async | 00:00:03.2
    secours3 | catchup | async | 00:12:41
    `

    • secours1
    • secours2
    • secours3
    • any of the three
    Show the answer

    secours1

    Only secours1 is synchronous: every COMMIT completed only after it received the log. secours2 may miss a few seconds of writes, secours3 is twelve minutes behind.

  • Streaming replication sends the primary's … to the standby, which … it to stay up to date.

    Show the answer

    Streaming replication sends the primary's WAL to the standby, which replays it to stay up to date.

    The standby does not rerun the SQL queries: it applies the physical changes described in the WAL, which makes it byte-for-byte identical.