9 High availability bad practices

 

In this chapter

  • Neglecting proper backup hygiene
  • Forgoing PostgreSQL recovery features
  • Being unprepared for database failure
  • Using the wrong tools for the job

Another thing for which PostgreSQL has gained a reputation in the industry is its famed resilience. However, this resilience is predicated upon following best practices and using the proper tools. Dangerous situations can arise if complacency takes hold due to “Postgres being a resilient database” and high availability (HA) is relegated to an afterthought. Instead, HA should be central to the deployment plan of any production database cluster.

When I refer to high availability in this chapter, I am encompassing the techniques and methods that can keep your database accessible to its users throughout failure scenarios, from minor to catastrophic, and allow it to recover from these failures. The goal of HA is to guarantee the minimum amount of downtime or data loss, being fully aware that the requirements and acceptable limits can differ for each organization.

9.1 Not taking backups

9.2 No Point-in-Time Recovery

9.3 Backing up manually

9.4 Not testing backups

9.5 Not having redundancy

9.6 Using no HA tool

Summary