Feature Overview of Crunchy PostgreSQL for PCF
This topic describes the features of Crunchy PostgreSQL for Pivotal Cloud Foundry (PCF) Tile.
The Crunchy PostgreSQL for Pivotal Cloud Foundry (PCF) Tile offers several out-of-the-box (configurable) plans. When deploying the service, operators have the opportunity to tune these plans for the needs of the environment.
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.
|Small||4||32 GB||64 GB|
|Medium||8||64 GB||128 GB|
|Large||16||128 GB||256 GB|
|Extra-Large||32||256 GB||512 GB|
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 and select an appropriate plan.
The following table provides information about the out-of-the-box cluster configurations:
The current limitations for these cluster configurations are as follows:
- The number of replicas and connections are not yet configurable.
- All replicas use
syncreplication is not yet configurable.
Crunchy PostgreSQL for Pivotal Cloud Foundry (PCF) Tile 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.
All archives from the database server are stored on the dedicated backup host. This means that databases can be restored to specific points in time.
Currently, individual databases cannot be restored. All databases are restored in the shared cluster.
Crunchy PostgreSQL for PCF uses HAProxy as a single point of entry to the database cluster. App developers must switch ports depending on the type of cluster they want to interact with.
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.
To query a
primary cluster, apps must use the
5432 port on the load balancer.
This ensures that writes or reads are redirected to the primary cluster.
To query a
replica, apps must use the
5433 port on the load balancer.
This ensures that reads are redirected to the replica cluster.
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 the following tools to help developers manage their system: