The fifth chapter of PostgreSQL replication set up synchronous replication (3)

5.3 Redundancy and stop replication

When it comes to synchronous replication, there is a phenomenon that must not be missed. Imagine that we have a two-node cluster with synchronous replication. What happens if a slave failure occurs? The answer is that master cannot easily divide the region into slow slave and fault slave, so it will start waiting for slave to come back.

At first glance, this looks like crap, but if you think about it in depth. You will understand that it is actually the only right thing. If someone uses synchronous replication, the data in the system must be valuable, so it must not be risky. Rejecting data and giving feedback to end users is better than keeping data stored at risk and silently ignoring high durability requirements.

If you decide to use synchronous replication, you must consider using at least three nodes in your cluster. Otherwise there will be a significant risk that you cannot lose a single node without the risk of experiencing significant downtime or loss of data.

5.4 Summary

In this chapter, we present the basic concepts of synchronous replication and have shown how data is replicated synchronously. We also described how to change the durability requirements by modifying the operating parameters of PostgreSQL. PostgreSQL gives the user the choice of how to replicate the transaction, and the level of durability required for a particular transactional replication.

In the next chapter, we'll drill down and see how you can see if your replicated settings work as expected. We'll introduce some tricks that make it easy for him to see if your cluster works as expected.

The fifth chapter of PostgreSQL replication set up synchronous replication (3)