5 Questions to ask when Designing High-Availability Databases

High-availability databases are critical for organizations that rely on 24/7 access, whether internal or customer-facing. Every second of downtime can translate to revenue loss, and worse. Read this article to learn 5 questions you should be asking when designing and developing a high-availability database.

Table of contents

What kinds of hardware, network and software considerations affect a high availability database?
What level of “missioncritical” do you need?
What is the budget for my high availability solution?
What options exist beyond Oracle?
What are the best practices for implementing high availability in Postgres?

High availability databases are essential to organizations depending on mission-critical, 24/7 access. The use cases of a highly available database may vary between a financial services organization or a telecommunications provider, but the desired result is the same: an incredibly reliable database that minimizes downtime. Organizations often strive for availability down to the decimal point as a percentage of uptime in a given year, such as four nines (99.99% availability). Every second of downtime can translate to lost revenue, or worse.

With an estimated average downtime cost of $5,600 per minute, a highly available database can help ensure a power outage or system failure doesn’t result in thousands upon thousands of dollars of losses. But before your database can deliver high availability with minimal downtime, it’s crucial to understand the underlying needs and requirements of your database operations. Without the proper infrastructure in place, delivering high availability can become incredibly difficult and expensive.

If you’re tasked with designing a highly available database, we detail five questions you need to consider before taking action.

What kinds of hardware, network and software considerations affect a high availability database?

The weakest link in your chain has the greatest impact, and the availability of your overall solution can be determined by the availability of each component. For your database to be available at four nines, all of the underlying hardware like networks, power supplies, disks and controllers needs to be more available than four nines. For a mission-critical system, that means running dual networks with dual power supplies, dual cards and highly redundant striped disks.

For example, if a company wants to get as close as possible to five nines availability (99.999% uptime or less than 6 minutes downtime per year) with the minimum potential for data loss, they need redundant hardware to handle their availability as well as backup data that gets spooled offsite continuously, requiring distributive disks and a distributive storage area network.

What level of “missioncritical” do you need?

A lack of understanding of the infrastructure requirements is one of the biggest issues organizations face. When determining which capabilities are “mission-critical,” it’s important for organizations to make distinctions based on their particular needs. For instance, losing business because you’re not able to take a customer’s order is a different problem than having to expedite a shipment because of a system failure that ends up cutting into your margin. While both tasks rely on a high availability database, unplanned downtime may stem from different problems. It’s crucial to outline the specific functionality that must remain available at all times to assemble the right hardware, network and software solutions.

Any range of availability — from 99.9 percent to 99.999 percent — requires a different investment in hardware and software. For example, if an organization wants high availability, they need an offsite replica that can be brought online quickly in the event of catastrophic data loss. Planning for this sort of infrastructure requirement requires a fundamental understanding of your database needs to achieve the desired amount of uptime.

What is the budget for my high availability solution?

A common barrier to implementing high availability is budget. Assembling the right network infrastructure to prevent catastrophic data loss requires a significant investment in hardware, software, and manpower. Organizations that don’t have sufficient resources to build the infrastructure they need, place their entire business operations at risk.

When an organization is willing to take that risk, they gamble meeting their business’ needs. Not having a highly available database in place for mission-critical applications means when an application fails, the business fails to operate, grinding business and revenue generation to a halt.

What options exist beyond Oracle?

EDB Postgres Enterprise Failover Manager (EFM) offers database high availability functionality at a fraction of the cost of Oracle. For instance, Oracle’s RAC can likely deliver high availability, but their prohibitively expensive solutions are often only applicable to a very small percentage of high-end needs. For a large percentage of applications, EDB Postgres can perform failover capabilities similar to Oracle, for everything but a very small percentage of applications that require the full capabilities of Oracle RAC. However, the vast majority of use cases will never truly need to use Oracle RAC.

What are the best practices for implementing high availability in Postgres?

Implementing replication is a key best practice for any highly available database. In EDB Postgres, this is easy to implement with native log-based replication, maintaining high availability through the right number of replicas that have low latency, reliable connections, and have close physical proximity.

One of the greatest benefits of an EDB Postgres subscription is that together with the database, users get tools for high availability and disaster recovery at no extra cost.

Source: EDB