We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Scaling WAL apply performance on Followers

Formal Metadata

Title
Scaling WAL apply performance on Followers
Subtitle
Eliminate replication lag and reduce startup times with pg_prefaulter
Title of Series
Number of Parts
37
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
DBAs struggling with replication lag is nothing new. A large volume of data or write IO comes into the system and the followers struggle to keep up. pg_prefaulter was written to eliminate replication lag on followers and also improves database startup times. If your database is under 24/7 write workload, has periodic replication lag that is unacceptable, or want to reduce the startup time of PostgreSQL, pg_prefaulter will help all three of these scenarios. At Joyent we use PostgreSQL as the metadata tier for our object storage system, Manta. This talk chronicles how we identified our source of replication lag and why we found it necessary to write pgprefaulter. pgprefaulter is a sidecar process for PostgreSQL written in Go that pre-fetches pages from disk and loads them into the operating system's filesystem cache before PostgreSQL requests them during the startup and application of WAL records. Additionally, this talk also discusses: the design considerations that went into writing pg_prefaulter the various forms of "replication lag" in PostgreSQL (WAL receive lag, WAL apply lag, and checkpoint lag) pathologies that came from deploying pg_prefaulter why we now consider pg_prefaulter mission critical software for our production databases tips for deploying pg_prefaulter