This page describes some of the user-controlled configurations that can cause an outage for an AlloyDB for PostgreSQL cluster to be excluded from the AlloyDB Service Level Agreement (SLA), which excludes outages "caused by factors outside of Google's reasonable control."
AlloyDB gives you as much control over your instance configuration as possible. However, customer-controlled configurations can increase the risk of instance downtime, depending on the database load and other configuration parameters.
If your instance becomes unhealthy, and if Google determines that the instance is out of compliance with the operational limits described in this page, then any resulting downtime is not covered by (or does not count against) the AlloyDB SLA.
The operational limits described in this page include the following information:
- Configurations that might result in a cluster being excluded from the AlloyDB SLA.
- How to avoid these types of configurations.
- How to mitigate the risks when a configuration that might result in SLA exclusion is required for your business environment.
Excluded configurations
Excluded configurations belong to the following categories:
- General configuration requirements
- Database flag values
- Resource constraints
General configuration requirements
Only AlloyDB instances configured for high availability (HA) are covered by the AlloyDB SLA, excluding the 1 vCPU shape (Preview).
Instances configured with 1 vCPU aren't covered by the AlloyDB SLA, even if the instances are configured with high availability (HA).
Basic (single-zone configured) instances are not covered by the SLA.
If the instance is configured and used in a way that causes the workload to overload the instance, or if the configuration causes the instance to experience a long recovery time, then the SLA does not apply.
Downtime of instances or clusters that results from your voluntary actions or inactions is excluded.
Disabling the AlloyDB API and other Google Cloud APIs that are required to create and connect to AlloyDB is not considered downtime, and is not covered by the SLA.
If you use VPC Service Perimeter configurations that aren't supported by AlloyDB, any downtime resulting from these unsupported configurations is exempt from the SLA. To learn about supported VPC Service Perimeter configurations, see Configure VPC Service Controls.
For clusters using Customer-Managed Encryption Keys (CMEK), the SLA does not cover downtime caused by the key becoming inaccessible to the AlloyDB service. This key unavailability can occur if you disable, destroy, or revoke permissions for the key.
We recommend that you set up alerts and monitoring in Cloud Monitoring.
Database flag values
AlloyDB lets you configure your instance using
database flags.
Incorrectly setting autovacuum and max_wal_size can cause performance
issues, increased disk space usage, and even instance crashes.
For a list of configurable flags and their defaults, see database flags.
Resource constraints
To maintain AlloyDB SLA coverage, you must avoid the following resource constraints:
Storage full: if your disk utilization is consistently high, and you incorrectly configured your storage quota (which results in a storage full issue), your instance is not properly sized for your workload and the instance might not be covered by the SLA.
CPU overloaded: if your CPU utilization is consistently high, your instance is not properly sized for your workload, and the instance might not be covered by the SLA.
Memory overloaded: if your memory usage is consistently high, even though AlloyDB provides automatic memory management, your instance is not properly sized for your workload, and the instance might not be covered by the SLA.
Connections overload: If your instance experiences constant connection storms that cause the instance to be unstable, you might not have configured the instance with a connection pooler, and the instance might not be covered by the SLA.