Skip Navigation
Show nav
Heroku Dev Center
  • Get Started
  • Documentation
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
  • Documentation
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
View categories

Categories

  • Heroku Architecture
    • Dynos (app containers)
    • Stacks (operating system images)
    • Networking & DNS
    • Platform Policies
    • Platform Principles
  • Command Line
  • Deployment
    • Deploying with Git
    • Deploying with Docker
    • Deployment Integrations
  • Continuous Delivery
    • Continuous Integration
  • Language Support
    • Node.js
    • Ruby
      • Working with Bundler
      • Rails Support
    • Python
      • Background Jobs in Python
      • Working with Django
    • Java
      • Working with Maven
      • Java Database Operations
      • Working with the Play Framework
      • Working with Spring Boot
      • Java Advanced Topics
    • PHP
    • Go
      • Go Dependency Management
    • Scala
    • Clojure
  • Databases & Data Management
    • Heroku Postgres
      • Postgres Basics
      • Postgres Performance
      • Postgres Data Transfer & Preservation
      • Postgres Availability
      • Postgres Special Topics
    • Heroku Redis
    • Apache Kafka on Heroku
    • Other Data Stores
  • Monitoring & Metrics
    • Logging
  • App Performance
  • Add-ons
    • All Add-ons
  • Collaboration
  • Security
    • App Security
    • Identities & Authentication
    • Compliance
  • Heroku Enterprise
    • Private Spaces
      • Infrastructure Networking
    • Enterprise Accounts
    • Enterprise Teams
    • Heroku Connect (Salesforce sync)
    • Single Sign-on (SSO)
  • Patterns & Best Practices
  • Extending Heroku
    • Platform API
    • App Webhooks
    • Heroku Labs
    • Building Add-ons
      • Add-on Development Tasks
      • Add-on APIs
      • Add-on Guidelines & Requirements
    • Building CLI Plugins
    • Developing Buildpacks
    • Dev Center
  • Accounts & Billing
  • Troubleshooting & Support
  • Databases & Data Management
  • Heroku Postgres
  • Postgres Availability
  • High Availability on Heroku Postgres

High Availability on Heroku Postgres

English — 日本語に切り替える

Last updated January 25, 2021

Table of Contents

  • Failover conditions
  • After failover
  • HA Status

All Premium, Private and Shield tier plans come with the High Availability (HA) feature, which involves a database cluster and management system designed to increase database availability in the face of hardware or software failure that would otherwise lead to longer downtime. When a primary database with this feature fails, it is automatically replaced with another replica database called a standby.

Like followers, HA standbys are physically located in a different availability zone (AZ) to protect against AZ-wide failures.

The database instance that exhibited failure is consequently destroyed and the standby is reconstructed.

When this happens, it is possible for a small, but bounded, amount of recently committed data to be lost.

The values of your DATABASE_URL and HEROKU_POSTGRES_*_URL config vars may change when a failover event happens (the names do not change). If you are connecting to this database from outside of Heroku, make sure you are setting your credentials correctly.

The standby node is hidden from your application. If you need followers for horizontal read scaling or reporting, create a new Standard Tier follower database of your primary.

Failover conditions

In order to prevent problems commonly seen with hair-trigger failover systems, we run a suite of checks to ensure that failover is the appropriate response. These checks are run every few seconds and consist of establishing connections to the underlying host using the SSH protocol. However, when only the PostgreSQL process becomes unavailable for any reason, a failover is unnecessary and the process is simply booted back into availability instead, ensuring an even shorter downtime period whenever possible.

After our systems initially detect a problem, we confirm that the database is truly unavailable by running several checks for two minutes across multiple network locations. This prevents transient problems from triggering a failover.

Like followers, standbys are kept up to date asynchronously. This means that it is possible for data to be committed on the primary database but not yet on the standby. In order to minimize data loss we take two very important steps:

  1. We do not attempt the failover if the standby is more than 10 segments behind. This means the maximum possible loss is 160MB or 10 minutes, whichever is less.
  2. If any of the 10 segments were successfully archived through continuous protection, but not applied during the two minute confirmation period, we make sure they are applied before bringing the standby out of read-only mode.

Typically there is little loss to committed data.

Out of memory conditions and exhausting concurrent connections are not treated as failover conditions. These conditions are caused by application behaviour, and would be likely to persist across failovers.

After failover

After a successful failover, there are a few things to keep in mind:

  • The URL for the database will have changed, and your app will automatically restart with the new credentials.
  • The new database’s cache will be cold, so your application’s performance may be degraded for a short period of time. This will fix itself through normal usage.
  • A new standby is automatically created, and HA procedures cannot be performed until it becomes available and meets our failover conditions.
  • Any Postgres sequences being used, such as those for integer primary keys, may see a gap after a failover event due to the way sequences are replicated in Postgres itself.

If there are standard followers of your primary database, they will be destroyed and recreated when the failover event happens.

HA Status

You can check the status of HA for your database by running heroku pg:info. In normal situations it will show HA Status: Available. After unfollowing or after a failover event, it will show HA Status: Temporarily Unavailable while the standby is being rebuilt. It can also show ‘Temporarily Unavailable’ when the standby is more than 10 segments behind, as failover will not be attempted at that time.

Keep reading

  • Postgres Availability

Feedback

Log in to submit feedback.

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Podcasts
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing

Subscribe to our monthly newsletter

Your email address:

  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Heroku Podcasts
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Facebook
  • Instagram
  • Github
  • LinkedIn
  • YouTube
Heroku is acompany

 © Salesforce.com

  • heroku.com
  • Terms of Service
  • Privacy
  • Cookies