Being DevOps requires you to have an expertise as a Database Administrator (DBA). For that reason I started a project where I had to implement Postgres database replication. It has proven to be not as easy as I anticipated. Postgres documentation has indepth info about bits and pieces of Postgres administration, however there was no straight forward guide that explained how to do a certain thin from the beginning to the end.
For this task I used a ready-made vagrant box for python development that already has a plenty of databases installed inside. The repo:
I made two identical vagrant repos with only difference being the hostnames and folder names. They are bridged to my home 192.168.1.0/24 LAN which they use to replicate the database one to another.
The database is located in regular folder with distinct permissions, that is only postgres user has access to it and a root. Config files describe the database handling for postgres.
Write ahead log (WAL) is the mechanism for database replication in postgres. Before changes are applied to the database, they are logged ahead, hence the name. This config manipulates the WAL. In this instance I configured master to have the max of 8 connections.
Here I configure the whitelist for database connections. From another hosts, that be slaves.
There are three modes for database replication, hot-standby, replica, streaming. From stack overflow: "Hot Standby" is the state the replica is in and means it is available for read-only queries. A replica can also "just" be a standby, but then it does not allow queries, it just sits there and waits to take over. A replica needs to have exactly the same data as the master and the way the data is sent from the master to the replica is what "streaming replication" refers to. A hot standby can also be setup using log shipping (sometimes also referred to as "continuous WAL archiving") or even streaming replication together with log shipping. n standby mode, the server continuously applies WAL received from the master server. The standby server can read WAL from a WAL archive or directly from the master over a TCP connection (streaming replication).
It wasn't particularly easy to figure replication for postgres. I used a lot of references.
Here's the full list of references: