High availability (HA) is achieved by increasing redundancy and resilience. To increase redundancy, parts of the system are replicated, so that they are on standby in the event of a failure. To increase resilience, recovery processes switch between these standby resources as quickly as possible.
Enable high availability in one click
Timescale Cloud simplifies the process of configuring and maintaining high availability for your databases. You can create replicas with a single click and enjoy automatic recovery and fail-over for all your replicated instances (including multiple availability zones). Learn more about HA replicas on Timescale Cloud.
For some systems, recovering from backup alone can be a suitable availability strategy.
For more information about backups in self-hosted TimescaleDB, see the backup and restore section in the TimescaleDB documentation.
For more information about backups in Timescale Cloud, see the backup and restore section in the Cloud documentation.
Storage redundancy refers to having multiple copies of a database's data files. If the storage currently attached to a PostgreSQL instance corrupts or otherwise becomes unavailable, the system can replace its current storage with one of the copies.
Instance redundancy refers to having replicas of your database running simultaneously. In the case of a database failure, a replica is an up-to-date, running database that can take over immediately.
While the public cloud is highly reliable, entire portions of the cloud can be unavailable at times. Timescale Cloud does not protect against Availability Zone failures unless the user is using HA replicas. We do not currently offer multi-cloud solutions or protection from an AWS Regional failure.
For more information about HA replicas in Timescale Cloud, see the high availability section in the Cloud documentation.
TimescaleDB supports replication using PostgreSQL's built-in streaming replication. Using logical replication with TimescaleDB is not recommended, as it requires schema synchronization between the primary and replica nodes and replicating partition root tables, which are not currently supported.
PostgreSQL achieves streaming replication by having replicas continuously stream the WAL from the primary database. See the official replication documentation for details. For more information about how PostgreSQL implements Write-Ahead Logging, see their WAL Documentation.
PostgreSQL offers failover functionality where a replica is promoted to primary
in the event of a failure on the primary. This is done using
pg_ctl or the
trigger_file, but it does not provide
out-of-the-box support for automatic failover. Read more in the PostgreSQL
failover documentation. Patroni offers a
configurable high availability solution with automatic failover functionality.
Found an issue on this page?Report an issue!