Book Image

PostgreSQL 13 Cookbook

By : Vallarapu Naga Avinash Kumar
Book Image

PostgreSQL 13 Cookbook

By: Vallarapu Naga Avinash Kumar

Overview of this book

PostgreSQL has become the most advanced open source database on the market. This book follows a step-by-step approach, guiding you effectively in deploying PostgreSQL in production environments. The book starts with an introduction to PostgreSQL and its architecture. You’ll cover common and not-so-common challenges faced while designing and managing the database. Next, the book focuses on backup and recovery strategies to ensure your database is steady and achieves optimal performance. Throughout the book, you’ll address key challenges such as maintaining reliability, data integrity, a fault-tolerant environment, a robust feature set, extensibility, consistency, and authentication. Moving ahead, you’ll learn how to manage a PostgreSQL cluster and explore replication features for high availability. Later chapters will assist you in building a secure PostgreSQL server, along with covering recipes for encrypting data in motion and data at rest. Finally, you’ll not only discover how to tune your database for optimal performance but also understand ways to monitor and manage maintenance activities, before learning how to perform PostgreSQL upgrades during downtime. By the end of this book, you’ll be well-versed with the essential PostgreSQL 13 features to build enterprise relational databases.
Table of Contents (14 chapters)
12
About Packt

Promoting a standby to a master

In the event of a disaster, a standby should be promoted to a master. This is to limit the amount of downtime involved when the master cannot be brought up for a longer period. While it is tricky to perform failover in some relational databases, it is very easy with PostgreSQL. We shall discuss how a standby can be promoted to a master in simple steps in this recipe.

Getting ready...

We must ensure that at least one standby has been set up for replication to perform a promotion or a failover. In the event of a failover, when the primary/master is lost, any transaction committed on the master that was not already synced/applied to the standby may be lost. Either the application should be designed to handle such situations and apply any lost transactions or we must wait until the recovery is completed, when the required WALs containing those transactions are already shipped to the standby.

Synchronous replication minimizes the possibility of losing transactions...