11. Streaming Replication
Although Point-in-Time Recovery (PITR), introduced in 2005, enabled rapid database restoration after a failure, users still required a replication feature to minimize system downtime.
Until 2008, the PostgreSQL core team was reluctant to introduce a built-in replication feature. Users therefore relied on external middleware, such as pgpool-II and Slony-I, to build replication systems.
This situation changed when several developers presented a prototype implementation of Streaming Replication. The prototype achieved unexpectedly high performance with low WAL processing and transfer overhead, which had been major concerns in implementing replication. Consequently, the core team changed its stance1 and decided to incorporate Streaming Replication into PostgreSQL.
PostgreSQL 9.0 (2010) introduced asynchronous Streaming Replication. PostgreSQL 9.1 (2011) significantly enhanced this feature through a major refactoring and added synchronous Streaming Replication.
Streaming Replication in PostgreSQL uses a single-primary-multiple-standbys architecture. The primary server continuously sends WAL data to the standby servers, which immediately replay the received data. This process relies on log shipping, a general replication technique.
This chapter focuses on the internal mechanisms of Streaming Replication and covers the following topics:
- How Streaming Replication starts up.
- How data is transferred between the primary and standby servers.
- How the primary server manages multiple standby servers.
- The functionality of Replication Slots introduced in version 9.4.