New Getting Hot and Streamy with Postgres - PGCon · 2020. 1. 4. · Streaming Replication II WAL kept in sync o wal_sender reads from WAL on disk (usually cached) o wal_receiver
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
o We do full stack development including databaseso We build large siteso Our website - http://omniti.como Surge - http://omniti.com/surge/2012o We're hiring - http://omniti.com/is/hiring
Contact meo [email protected] @PhilSorbero Blog - http://philsorber.blogspot.com
It's just another block in the WAL
Write Ahead Logo roll-forward recovery aka REDOo flushed to disk to guarantee commit durabilityo sequential writeso lower cost than flushing page cache
Allows us to do cool thingso Crash recoveryo Binary backupso Replication!
Introduced in 8.2 (technically possible since 8.0)Used for
o Failovero On-line Backup (not officially supported)
Config Option (Slave) - restore_command (RR)Tools
o omnipitr-syncho pg_basebackup (9.1)o omnipitr-restoreo pg_standby (8.3)o omnipitr-backup-slave
Warm Standby
Warm Standby (Log Shipping) cont.
Streaming Replication
Introduced in 9.0Used for
o Near real-time replication
Benefits over Log Shippingo Less hassle in setting up archive and restore commandso Less lag due to low activity (archive_timeout)
Disadvantageso Master does not keep WAL segments indefinitelyo More potential load on the master
Streaming Warm Standby
Streaming Replication cont.
Streaming Replication II
WAL kept in synco wal_sender reads from WAL on disk (usually cached)o wal_receiver writes to WAL on disk
Hybrid Modeo Streaming Replication & Log Shippingo Lets the slaves sustain more down timeo Less IO on master used for finding "old" WALo Still have to deal with the hassle of log shipping