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: