Postgres Streaming Replication
When I first got involved in managing a Postgres database, I was quickly introduced to the need for replication. My first project was to get our databases up on Slony, which was the hot new replication technology, replacing our clunky DRBD setup and allowing near-realtime read-only copies of the database. Of course, with time and scale, Slony had a hard time keeping up with the write traffic, especially since it ultimately suffered from write amplification (each write ultimately becomes two or more writes to the database, because of all the under-the-hood work involved). When Postgres Streaming Replication came out in v. 9.0, everyone felt like they struck gold. Streaming Replication was fast, and it took advantage of an already-existing feature in Postgres: the WAL Stream.
Improvements to Streaming Replication
Many years have passed since v. 9.0 (we’re coming up on v. 12 very soon). More features have been added, like Hot Standby, Logical Replication, and some two-way Master-Master replication extensions have been created. This has been quite a path of growth, especially since I remember someone saying that Postgres’ roadmap would not include replication at a BOF at PGCon, circa 2010.
With all the improvements to Streaming Replication over the years, I think one of the most misunderstood features is
hot_standby_feedback, and I hope to clarify that here.
Every #TechTuesday, EnterpriseDB shares a how-to post authored by a Postgres contributor and expert for Postgres Gems, the PostgresRocks community forum. PostgresRocks is a community to discuss all things Postgres. Join us at PostgresRocks and be part of the conversation.