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.
- Other maintenance activities.
A major DBMS version update is not part of maintenance. For more information about major version changes, see PostgreSQL version update.
Maintenance window
You can set your preferred maintenance start time using the Yandex Cloud interfaces (management console
- 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 when the maintenance will be performed. For example, you can choose a time when the cluster is least loaded.
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 a maintenance session from
00:00to01:00, enter1; from04:00to05:00,5.
Note
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.
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.
- Make your cluster completely unavailable for a while due to a reboot.
- Cause master host failover in the cluster, making the database read-only for a while.