Chapter 27. Built-in High Availability (BiHA)
Table of Contents
- 27.1. Architecture
- 27.2. Setting Up a BiHA Cluster
- 27.2.1. Prerequisites and Considerations
- 27.2.2. User Authentication Configuration
- 27.2.3. Setting Up a BiHA Cluster from Scratch
- 27.2.4. Setting Up a BiHA Cluster from the Existing Cluster with Streaming Replication
- 27.2.5. Setting Up a BiHA Cluster from the Existing Database Server
- 27.2.6. Setting Up the Referee Node in the BiHA Cluster
- 27.2.7. Setting Up a BiHA Cluster with proxima
- 27.2.8. Setting Up a Geo-Distributed and Disaster-Resilient BiHA Cluster
- 27.2.9. Configuring SSL for Service Connections (Optional)
- 27.2.10. Using the Magic String (Optional)
- 27.2.2. User Authentication Configuration
- 27.2.1. Prerequisites and Considerations
- 27.3. Administration
- 27.3.1. Changing Cluster Composition
- 27.3.2. Changing Configuration Parameters
- 27.3.3. Manual Switchover
- 27.3.4. Managing SSL for Service Connections
- 27.3.5. Roles
- 27.3.6. Using the Service Mode
- 27.3.7. Automatic Cluster Synchronization after Failover
- 27.3.8. Restoring the Node from the
NODE_ERRORState- 27.3.9. The Watchdog Mechanism
- 27.3.10. Replication Configuration
- 27.3.11. Logging
- 27.3.12. Callbacks
- 27.3.13. Managing proxima
- 27.3.14. Recovering from a Backup
- 27.3.15. Migration
- 27.3.16. Disabling biha
- 27.3.17. Removing biha
- 27.3.2. Changing Configuration Parameters
- 27.3.1. Changing Cluster Composition
- 27.4. Reference for the biha Extension
- 27.5. Reference for the bihactl Utility
Built-in High Availability (BiHA) is a complex Postgres Pro Enterprise solution managed by the biha extension and the bihactl utility. Together with a set of core patches, SQL interface, and the biha-background-worker process, which coordinates the cluster nodes, BiHA turns a Postgres Pro cluster into a BiHA cluster — a cluster with physical replication and built-in failover, high availability, and automatic node failure recovery.
As compared to existing cluster solutions, i.e. a standard PostgreSQL primary-standby cluster and a cluster configured with multimaster, the BiHA cluster offers the following benefits:
Physical replication.
Dedicated leader node available for read and write transactions and read-only follower nodes.
Built-in failover including capabilities of automatic node failure detection, response, and subsequent cluster reconfiguration by means of elections.
Referee node to avoid split-brain issues.
Manual switchover.
Autorewind capabilities.
Synchronous and asynchronous node replication.
Cascading replication.
Geographical distribution and disaster resilience (experimental functionality).
Watchdog functionality to prevent hanging.
No additional external cluster software required.