Maintenance in Managed Service for PostgreSQL
Maintenance in Managed Service for PostgreSQL includes:
- Installing minor updates and security fixes for the DBMS and/or connection pooler.
- Updating the host OS and other underlying software.
- Scheduled automatic storage expansion.
- Forced DBMS version upgrade.
- Other maintenance activities.
For more information on self-managed major version upgrades, see PostgreSQL version update.
Maintenance window
You can set your preferred maintenance start time using the Yandex Cloud interfaces (management console, CLI, Terraform, and API) when creating or updating a cluster:
- The At any time option (default) allows performing maintenance at any time.
- The By schedule option allows you to select the day of the week and UTC time interval for the maintenance. For example, you can choose the cluster's least busy time. Both active and stopped clusters are subject to maintenance operations. Maintenance operations may include DBMS updates, patches, etc.
In the management console, you select the maintenance start time as an hour interval. In other interfaces, you specify this interval by its sequence number, from 1 to 24.
For example, to start maintenance in the interval from
00:00to01:00, put1; from04:00to05:00,5.
Managed Service for PostgreSQL sends email notifications for upcoming maintenance. We recommend setting up monitoring of incoming messages from Yandex Cloud. You can always reschedule maintenance to a more convenient time, if required.
To view maintenance task information, you need the managed-postgresql.maintenanceTask.viewer role or higher.
To manage maintenance tasks, you need the managed-postgresql.maintenanceTask.editor role or higher.
Maintenance workflow
In Managed Service for PostgreSQL single-host clusters, a master host undergoes maintenance. Therefore, it may become unavailable in case it is restarted.
In multi-host clusters, the maintenance is run as follows:
-
Replica hosts undergo maintenance one by one. The replicas are queued randomly. If a replica needs to be restarted during maintenance, it will become unavailable.
-
Master host undergoes maintenance and gets updated. If the master host needs to restart and becomes unavailable, one of the replicas will assume its role.
If you access a cluster using the FQDN of the master host, the cluster may become unavailable. To ensure uninterrupted operation of your application, list all the hosts and specify
target_session_attrswhen connecting to the cluster. Read more.
More information on operations during maintenance:
| Operation | Trigger | Process | Impact on application |
|---|---|---|---|
| Restart | PostgreSQL minor updates, system library updates | Each cluster node stops and starts in turn. The PostgreSQL process restarts on each node. | There is a brief connection drop on each host while the PostgreSQL process stops and restarts. It may last from a few seconds to several minutes depending on the load. To minimize downtime, a checkpoint runs right before the restart. Incomplete write operations will be aborted. |
| Master switchover | Updates that require a server reboot | Each cluster node stops and reboots in turn. If the current master reboots, a replica is promoted to the new master. | Connections are terminated. Switchover is faster than a full server reboot. Your application must be able to handle a brief read-only state and search for a master. |
| Forced version upgrade | Major upgrades of clusters on unsupported versions | The master stops, updates, and stays offline. Replicas are switched off and updated one by one. Updated replicas restart in read-only mode. The master turns back on after all replicas update. | Connections are terminated during the installation of updates. We recommend that you plan a manual cluster version upgrade before it reaches end-of-life. |
How maintenance impacts a cluster
Depending on its type, maintenance can impact your cluster as follows:
- Show little to no impact on database users.
- Break database connections in place, forcing clients to re-establish their connections.
- Make your cluster read-only for a while.
- Restart the master and trigger master failover to one of the replicas.
- Cause master host failover in the cluster, making the database read-only for a while.
Maintenance tasks have an estimated duration and completion date. These time frames are calculated based on historical data from similar operations. The actual completion times may vary depending on your cluster.