Maintenance

Crunchy Bridge takes care of routine maintenance for your database. This includes operating system patching as well as Postgres version patching and upgrades.

We evaluate all security vulnerabilities and bug fixes that could affect your database and put you at risk. When required, we will determine the schedule in which your database will be patched in accordance with our security risk analysis policy.

Info

In general, we expect that required maintenance will be scheduled less than once per year unless necessary in order to maintain the security and stability of the platform.

You can also choose to perform maintenances or upgrades on your cluster when you choose. Read on to learn about how maintenance works on Crunchy Bridge.

How maintenance works

For specific details about each type of maintenance or upgrade, see the Cluster Management page.

Preparing a new instance

When a maintenance or upgrade operation is initiated, Crunchy Bridge must first prepare a new cluster in the background according to the desired specifications for instance size, storage size, and Postgres major version. The minor version will always be the latest available for that version of Postgres, and you'll receive the latest OS version we offer, as well.

Failing over

After the new cluster is built, it will be populated with all the data from the original cluster. It will then be kept up to date until it is time to failover and complete the operation.

Info

Failover can be delayed if clients continue to hold connections and perform writes on the source cluster. All WAL must be written and archived before a failover can complete. For faster failovers, try to run maintenances during quiet periods.

The maintenance or upgrade operation will be completed with a failover when two things are true:

the new instance is built, populated, and up to date, and
the desired failover time is reached

Crunchy Bridge evaluates the desired failover time based on either the maintenance window setting, or the parameters provided when the maintenance or upgrade was created or updated, in the following order:

The time specified with --now or --starting-from YYYY-MM-DDTHH:MM:SSZ (Note: --starting-from equates to --now if set to a time in the past)
The time indicated in the cluster's maintenance window
As soon as the instance is ready, if no time is specified and there is no maintenance window set

Info

You can update a pending maintenance or upgrade with --starting-from, --now, or --use-cluster-maintenance-window while it is still being prepared.

However, if it is too close to the previously set failover time, you will not be able to change it.

Maintenance windows

The Crunchy Bridge approach to maintenance takes care to minimize the impact. One important way we do this is through a maintenance window you can set for each cluster.

A maintenance window is a three-hour window of time during which your particular cluster will receive any maintenance that is requested or required. If you would like maintenance operations to wait until a specific time of day when it's likely to be more convenient, then you will want to set a maintenance window.

Info

A cluster has no maintenance window by default. In this case, maintenance without a --starting-from time specified will be performed as soon as requested or required. This includes self-initiated and Crunchy Bridge-initiated maintenance.

You can choose each cluster's maintenance window in a cluster's Settings section:

You can also set a cluster's maintenance window using the CLI's cb maintenance set or the Update Cluster API endpoint.

If a cluster does have a maintenance window set, maintenance initiated by you or by Crunchy Bridge will generally be performed for that cluster during its maintenance window.

Scheduling maintenance outside the window

The CLI and API provide commands to schedule maintenance or instance upgrades (includes resizes and major version upgrades) to run outside of a cluster's maintenance window.

The cb maintenance and cb upgrade CLI commands allow you to create maintenances and upgrades with specific run times, and to change the run time of maintenances and upgrades that are still being prepared. See the next sections for more details.

Info

It is currently only possible to have a single scheduled maintenance or upgrade at any given time for a cluster.

Run maintenance as soon as possible

To run a maintenance or upgrade as soon as possible, create it or update it with the CLI using the --now flag.

`cb maintenance create` and `cb upgrade start`

To create a simple instance refresh maintenance that will failover as soon as it is ready, you can run:

cb maintenance create --cluster <cluster_EID> --now

This command would create an upgrade resulting in a standard-8 cluster with 15 GB of disk running PG 15 with an HA server using the same provider as the original cluster that would failover as soon as it is ready:

cb upgrade start --cluster <cluster_EID> --plan standard-8 --version 15 --storage 15 --ha true --now

Info

An "upgrade" does not necessarily mean the Postgres major version is going to change. Rather, it indicates that some aspect of the cluster's configuration is changing, for example the disk size or the instance size.

`cb maintenance update` and `cb upgrade update`

For simple instance refreshes created in the dashboard using the "Create Upgrade" button, you can update the maintenance run time with the CLI so that it will failover immediately once it is ready, rather than waiting for the maintenance window:

cb maintenance update --cluster <cluster_EID> --now

For resizes or upgrades, use cb upgrade update to change the run time so that the failover will occur as soon as it is ready:

cb upgrade update --cluster <cluster_EID> --now

Since only one maintenance can be scheduled or pending for a given cluster, the update command will only operate on the pending maintenance. Remember, this does not change the cluster's maintenance window.

Info

The CLI commands to manage maintenances and upgrades are under active development. The functionality and documentation may change slightly as we streamline these operations.

Running maintenance at a specific time

In addition to the --now flag, you can also use --starting-from with the cb maintenance and cb upgrade commands. This allows you to provide a timestamp that will schedule a maintenance or upgrade to run anytime in the next 72 hours. The timestamp must be formatted according to RFC3339, for example: 2023-06-14T04:15:00Z.

This command would initiate an upgrade resulting in a standard-16 cluster running PG 15 with 200 GB of disk space on the same provider as the original that will prepare itself immediately but not fail over until 2023-06-14 at 04:15:00 UTC:

cb upgrade start --cluster <cluster_EID> --plan standard-16 --version 15 --storage 200 --starting-from 2023-06-14T04:15:00Z

Note: maintenances created or updated with a --starting-from date in the past will proceed as if --now was specified!

Putting a maintenance back into the window

If you decide you want a maintenance to run in the cluster's maintenance window after all, you can update it to run in the maintenance window using the --use-cluster-maintenance-window flag.

This command will set a cluster's pending upgrade to use the maintenance window:

cb upgrade update --cluster <cluster_EID> --use-cluster-maintenance-window

Checking the status of maintenance

You can view the status of a cluster's pending maintenance or upgrade in a cluster's Settings section:

The status of a maintenance or upgrade can be checked in the CLI using cb maintenance info --cluster <cluster_EID> or cb upgrade status --cluster <cluster_EID>.

You may also notice a banner on a cluster's Overview page reminding you of pending maintenance and when it is scheduled to run: