AlloyDB for PostgreSQL clusters and instances rely upon many internal, low-level Google Cloud resources. These include the virtual machine (VM) instances that serve as AlloyDB nodes and load balancers, and the storage volumes that hold your data. Because AlloyDB is a managed service, Google keeps these internal resources up to date. This helps ensure that your AlloyDB clusters and instances stay reliable, performant, and secure.
Most of these updates require no downtime, but certain system updates require a brief service interruption. We refer to these updates as maintenance. Because these updates require the affected node to restart, they can incur downtime. AlloyDB's non-disruptive maintenance operations limit the downtime to <1 second for primary instances, and zero seconds for read pools. To achieve near-zero and zero downtime, AlloyDB prepares a replacement server with the updates and then switches the database server.
Reasons for maintenance
Periodic maintenance updates can happen for the following reasons:
New AlloyDB features and bug fixes: to launch new features, Google must update the AlloyDB software that runs on the nodes within your cluster. This might also involve updates to the PostgreSQL extensions included with AlloyDB, or installation of new extensions. Updates might also include bug and security fixes, or performance improvements.
Database compatibility upgrades: the PostgreSQL community regularly releases minor-version updates to supported major versions of PostgreSQL. Google incorporates these updates into AlloyDB, and applies them to your clusters. For more information, see Database version policies.
Maintenance timing and maintenance preferences
You can set maintenance windows for both primary and secondary AlloyDB clusters. By default, no maintenance window is set on an AlloyDB cluster. Non-emergency maintenance for an AlloyDB cluster with no configured maintenance windows can occur any time except for the hours between 6 AM and 10 PM on weekdays, in the local time of the region where the cluster is located.
You can also specify a maintenance window. A maintenance window defines your preferred maintenance time, in terms of hour-of-day and day-of-week, for your cluster to begin its maintenance events. For example, you can set a cluster to have a maintenance window that begins at 11AM on Sundays (UTC).
If you set a maintenance window, then AlloyDB schedules future non-emergency maintenance events to begin no later than one hour after the specified time. In addition, if you opt in to receive email notifications about scheduled AlloyDB maintenance events, then you receive an automated notification about the event as soon as it's scheduled. Maintenance events are scheduled at least one week ahead of time.
You can't set when a maintenance window ends. This is because the total time that a single maintenance event requires can vary. The maintenance window duration depends upon the complexity of the cluster—that is, the number of read pool instances that require updates—and the nature of the update. AlloyDB first updates the read pools simultaneously, and then it updates the primary instance.
While the downtime that an individual instance requires can be brief, the entire maintenance process usually completes within an hour. You can only set a one-hour maintenance window. However, for clusters with multiple read pools, the downtime might continue past the one-hour window because the maintenance can start at any time in that window—for example, at the last minute—and then take up to an hour. This means that the downtime can occur after the maintenance window.
Emergency maintenance events, such as urgent security patches, might occur outside default maintenance times or configured maintenance windows. This includes deny maintenance periods.