Feature Overview of Crunchy PostgreSQL for PCF

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

Plans

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.

Plan Sizes

The plans that are included are as follows:

  • small
  • medium
  • large
  • extra-large

Suggested Plan Configuration

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

Default 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
Extra-Large 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 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:

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.

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.

Load Balancing

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.

Selectively Accessing Clusters

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.

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.

Automatic 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 the following tools to help developers manage their system:

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