Feature Overview of Crunchy PostgreSQL for PCF
This topic describes the features of Crunchy PostgreSQL for Pivotal Cloud Foundry (PCF).
The Crunchy PostgreSQL for PCF offers several out-of-the-box (configurable) plans. When deploying your Crunchy PostgreSQL for PCF, operators have the opportunity to tune these plans for their environment needs.
The plans that are included are as follows:
The following table suggests recommendations for configuring plans. These recommendations do not accommodate every app. However, they provide a starting point for operators to configure their tile.
Note: Part of maintaining high availability is having room to grow the database. Therefore, operators and developers should consider the rate at which they expect to grow.
The following table provides information about the out-of-the-box cluster configurations:
Note the current limitations for these cluster configurations:
The number of replicas and connections are not yet configurable.
All replicas use
syncreplication is not yet configurable.
Crunchy PostgreSQL for PCF uses pgBackrest as a dedicated backup and archiving host. The tile comes pre-configured with nightly physical backups of the database server:
|Sunday||Full||1 am UTC|
|Monday||Incremental||1 am UTC|
|Tuesday||Incremental||1 am UTC|
|Wednesday||Incremental||1 am UTC|
|Thursday||Incremental||1 am UTC|
|Friday||Incremental||1 am UTC|
|Saturday||Incremental||1 am UTC|
Although backups only happen once a day, PostgreSQL is continuously shipping the Write-Ahead-Logs (WAL) to the pgBackrest server. This means that point-in-time recovery is possible, regardless of the schedule.
These backups not only offer peace of mind, but are used frequently by the tile. Crunchy PostgreSQL for PCF uses backups to create replicas in the stack. By using backups in operations, we can ensure that backups and restores work.
Crunchy PostgreSQL for PCF uses
HAProxy as the single point of entry to the database cluster.
App developers must switch ports depending on the type of cluster they want to interact with.
Reads and Writes
To query a
replica, apps must use the
5433 port on the load balancer.
This ensures that reads are redirected to the replica cluster.
To use the
primary cluster, apps must use the
5432 port on the load balancer.
This ensures that writes or reads are redirected to the primary cluster.
By using port switching, apps have the ability to manage the types of database interactions their app needs. When used correctly, this strategy allows apps to be more performant.
Crunchy PostgreSQL for PCF provisions a cluster of PostgreSQL servers and self-configures their roles (primary and many replicas). This allows the servers to change their roles when failures are detected.
Crunchy PostgreSQL for PCF configuration files are managed by
Each of these templates watch different parts of the stack.
When changes are detected, configuration files automatically are rendered with the latest state.
This allows the system to be dynamic and change depending on state of services.
For example, the PostgreSQL load balancer automatically detects when replicas are added or removed, and reconfigures its pool to reflect the current state.
Crunchy Cluster Manager runs on each of the Consul Servers within the Crunchy PostgreSQL for PCF. The job of CCM is to detect failures of the PostgreSQL servers and to determine who is the best candidate to replace a failed primary. CCM measures replication lag to determine the best candidate to elect for the primary role.
Once a new primary role is elected, CCM updates the Consul Service Catalog to reflect the new state. The newly elected primary reconfigures itself (trigger a failover) and all other services detect the new primary.
Failed former primaries are put into a fenced state.
This tells the rest of the stack to no longer communicate with the failed service.
cron job attempts to repair fenced servers and add them to the replica pool.
Crunchy PostgreSQL for PCF offers two tools to help developers manage their system: