![]() ![]() archive_mode : This parameter must be set to 'ON' to enable archiving.It may be set to the public or a private IP interface or through everything using (*).ĪLTER SYSTEM SET listen_addresses TO '*' listen_addresses : This parameter determines the IP interfaces through which the connections are allowed.So, this parameter need not be modified unless we set up more than 5 standby to a master.ĪLTER SYSTEM SET max_wal_senders TO '10' max_wal_senders generally defaults to 10 on all distributions. pg_basebackup may use one or 2 Wal senders which will be discussed later in a separate blog post. max_wal_senders : Number of WAL sender processes that can be started on the master.Please Note : Some of these parameters are not mandatory for streaming replication but only for a good setup. Step 4 : Following are the list of configuration parameters that enable us to perform a robust replication setup for production databases. (Step to be executed on the master) $ psql -c "select pg_reload_conf()" Step 3 : Perform a reload to get the changes into effect. Replace 192.169.12.1 with the IP address of the standby that should be allowed to make replication connections to the master. (Step to be executed on the master) $ vi /var/lib/pgsql/13/data/pg_hba.conf > Add entry host replication replicator 192.169.12.1/32 md5 See this documentation on pg_hba.conf more details. Step 2 : Allow the standby's replication user to connect to the Primary. (Step to be executed on the master) $ psql -p 5432 -c "CREATE USER replicator WITH REPLICATION ENCRYPTED PASSWORD 'secret'" Step 1 : Create a replication user who has a replication role. ![]() Steps to setup streaming replication in PostgreSQL Let us now see the detailed steps involved in setting up streaming replication. ![]() More internals on Streaming Replication protocol can be seen here. Similarly, a background process called WAL receiver is started on the standby, that receives and applies these changes. This process accepts requests from a standby and streams the WAL records continuously to its standby. When we setup streaming replication, a new background process called WAL sender is started on the master. Dirty buffers or dirty blocks are the modified buffers due to the changes to the tuples (or records) in that block.Īs seen in the Streaming Replication Architecture diagram above, A WAL segment contains WAL records that include the changes done to data blocks (in the form of DML or DDL). In the following Streaming Replication Architecture diagram, we see an example of how some blocks/buffers have become dirty blocks because of an UPDATE statement. Of course, this default behavior can always be altered. What this means is that a transaction is said to be successful only when it is written to a WAL segment on the disk. The backend may also flush the WAL buffers to WAL segments. In general, anything in memory (or RAM) can be lost upon a crash but not anything on the disk.Ĭonsidering this fact, there exists a background utility process in PostgreSQL called WAL Writer that continuously writes the WAL records from memory to WAL (Write-Ahead logs) segments on the disk. Durability is said to be achieved when a relational database ensures that a committed transaction is never lost, even upon a crash. To understand the internals of how streaming replication works, we need to start from ACID properties. It may be called a replica in some of the database technologies. Whereas, a standby replicates changes from a master and accepts only reads. It can be compared with a primary database in some of the database technologies. A master is a server that accepts writes and streams changes to a standby. One would generally hear the terms master and standby in postgres. Streaming replication may also be referred to as physical replication.
0 Comments
Leave a Reply. |