Feature Overview of Crunchy PostgreSQL for PCF

This topic describes the features of Crunchy PostgreSQL for Pivotal Cloud Foundry (PCF).

Plans

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.

Plan Sizes

The plans that are included are as follows:

  • Small
  • Medium
  • Large
  • XLarge

Recommendations

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.

Plan vCPU Memory Disk
Small 4 32GB 64GB
Medium 8 64GB 128GB
Large 16 128GB 256GB
XLarge 32 256GB 512GB

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.

Cluster Configurations

The following table provides information about the out-of-the-box cluster configurations:

Plan Replica Connections
Small 1 100
Medium 2 100
Large 2 200
XLarge 2 500

The current limitations for these cluster configurations are as follows:

  • The number of replicas and connections are not yet configurable.

  • All replicas use async replication. sync replication is not yet configurable.

Automated Backups

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:

Day Backup Type Time
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.

Load Balancing

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.

HA Model

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 consul-template. 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.

Auto Failover

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. An hourly cron job attempts to repair fenced servers and add them to the replica pool.

Model

Tools

Crunchy PostgreSQL for PCF offers two tools to help developers manage their system:

  • cf-pgadmin4
  • cf-pgloader
Create a pull request or raise an issue on the source for this page in GitHub