Physical Replication

When a database, after passing the development and testing phases, arrives in production, the first problem that the DBA must address is managing replicas. Replicas must be managed in real time and automatically updated. Replicas allow us to always have a copy of our data updated in real time on another machine. This machine can be placed in the same data center as our data or in a different one. This chapter differs from all that we have seen previously in that we will be talking about physical replication. In Postgres, starting from version 9.x, it is possible to have physical replication natively. We will talk about what physical replication means and we will see how to create a replica server and how to manage it. We will also see that there is the possibility of having synchronous or asynchronous replicas and that there can be multiple replicas of the...

Exploring basic concepts

In PostgreSQL, there are two kinds of replication techniques:

• Asynchronous replication: In asynchronous replication, the primary device (source) sends a continuous flow of data to the secondary one (target), without receiving any return code from the target. This type of copying has the advantage of speed, but it brings with it greater risks of data loss because the received data is not checked.
• Synchronous replication: In synchronous replication, a source sends the data to a target, that is, the second server; at this point, the server sends back a code to verify the correctness of the data. If the check is successful, the transfer is completed.

Both methods have advantages and disadvantages, and in the Managing streaming replication section of this chapter, we will analyze them.

WAL

Let's briefly summarize what we saw in the chapter on MVCC and WAL: in that chapter, we saw how PostgreSQL stores data on disk using WAL; as we saw in Chapter 11, Transactions...

Learning WAL archiving and PITR

In this section, we are going to look at the physical way of storing data in PostgreSQL in more detail. We will begin to process segment WAL manually and then move on to automatic modes, which make the work of the DBA much easier. Classic backups are made using the pg_dump command, and they are also called logical backups. What we want to do now is take a physical backup of the data; we want to obtain a continuous snapshot of our database. This technique offers the DBA the possibility to restore the database to any point in the past; this technique, called PITR, is widely used as a disaster recovery technique. This technique allows us to go back to our PostgreSQL cluster at an exact point in the past before a malicious event occurred (for example, a DROP of a table). This technique is often used by DBAs if we want to take a certain snapshot of a production environment back to a test environment.

PITR – the manual way

In the Chapter 14, Backup and...

Managing streaming replication

In this section, we will talk about replication. Why do we have to have replicas? The problem with PITR is that recovery often takes a long time before a server can be restored:

In a production environment, you often need to be able to restore the production environment as quickly as possible after a system crash. In order do this, we have to use the streaming replication technique. To make this possible, we need at least two servers, one master server and one slave server. The master server performs all the operations that will be requested by the application programs; the slave server will be available only for read operations and will have the data copied in real time.

Basic concept

The idea behind streaming replication is to copy the WAL files from the master server to another (slave) server. The slave server will be in a state of continuous recovery and it continuously executes the WAL that is passed by the master machine; in this way, the slave machine...

Summary

In this chapter, we introduced the concept of physical replication. We started by reviewing and deepening our knowledge of WAL segments from previous chapters. We have introduced, seen, and configured an asynchronous physical replica and a synchronous physical replica. We looked at the difference between the two modes and we saw how easy it is to switch from one mode to another. We then explored some useful tools for monitoring replicas and checking their good health.

In the next chapter, we use the concepts that we have discussed in this chapter to address the topic of logical replication.

References

• https://www.postgresql.org/docs/12/runtime-config-wal.html#GUC-WAL-LEVEL
• https://www.postgresql.org/docs/12/app-pgbasebackup.html
• https://www.postgresql.org/docs/12/monitoring-stats.html#PG-STAT-REPLICATION-VIEW
• https://www.postgresql.org/docs/12/runtime-config-replication.html
• https://www.postgresql.org/docs/12/high-availability.html