Design, migrate, and run scalable, highly available databases on Google Cloud across relational and NoSQL services, and track your readiness for the Professional Cloud Database Engineer exam.
Prepare and test your skills
Prepare and test your skills
Notification Integration and Incident Response is the practice of connecting planned database maintenance to stakeholder alerts and application readiness actions. A maintenance signal flows from the database instance or cluster to a notification workflow, and the workflow flows onward to stakeholders and to application controls. Those controls can shift traffic, pause writes, or hold health checks so service level objectives stay intact.
The availability architecture of AlloyDB Omni (opens in a new tab) defines which failures the database can survive and what notifications must cover. AlloyDB Omni offers three reference architectures with different recovery time objective (RTO) and recovery point objective (RPO) tradeoffs. Standard Availability uses backups for basic protection, Enhanced Availability adds zonal replication inside a region, and Premium Availability adds zonal plus regional replication for mission-critical needs.
The three architectures differ by which failure scopes they recover from, as shown below. The notification plan depends on this choice because a zone or regional event needs stakeholder and application response only when the architecture does not absorb it automatically.
| Architecture | VM and node failure | Zone failure | Regional failure |
|---|---|---|---|
| Standard Availability | Supported | Not supported | Not supported |
| Enhanced Availability | Supported | Supported | Not supported |
| Premium Availability | Supported | Supported | Supported |
Choose Standard Availability when the workload is development or can restore from backup. Choose Enhanced Availability when the workload must survive a zone loss in one region. Choose Premium Availability when the workload must survive a full region loss with 99.99% availability and zero data loss on recovery.
Preparing notification-ready instances means giving Cloud SQL enough space and headroom so routine work does not become an incident. Cloud SQL may perform critical maintenance that needs free space and manageable metadata size. Keeping at least 20% available space, keeping table count under 10,000 per instance, and sizing for transaction log retention on high-write instances reduces upgrade time and prevents stalls.
SQL Server workloads have additional storage and growth dependencies that affect maintenance success:
autogrow in megabytes rather than as a percentage, using increments matched to the requirement.When these dependencies are met, the database depends less on emergency action during the window. Notifications can then focus on expected behavior rather than unexpected capacity failures.
Maintenance mode in Kubernetes keeps a database pod in a running state while repair or update work proceeds. AlloyDB Omni for Kubernetes enters maintenance mode by disabling liveness probes and startup probes on the database container. The health check normally flows from the kubelet to the database container probe endpoint, and disabling that check breaks the restart trigger while work continues.
The enable sequence states its order explicitly. First, verify that probes exist by inspecting the pod specification in its namespace for the database container liveness probe and startup probe. Then, disable the liveness and startup probes to place the pod in maintenance mode. Only after the work is complete, re-enable the probes so health reporting flows again from the database container to Kubernetes. Application readiness protocols should treat the maintenance-mode pod as intentionally unavailable for new work until probes are restored.
Exam tip: Maintenance mode disables liveness and startup probes to prevent restarts during repair; it does not remove the need for 20% free space and under 10,000 tables for a smooth upgrade.
Incident response is an ordered escalation where low-effort actions are tried before disruptive re-architecture. Notifications flow alongside this sequence from the database operations team to stakeholders through Cloud Pub/Sub or email alerts. The alerts mark when maintenance starts, when traffic shifts to a replica, and when the system returns to normal, so applications can shed load, retry safely, or fail over in step with the database.
The response follows a fixed order from scaling to sharding:
Maintenance Window and Track Selection is the practice of deciding when database maintenance runs and how updates are applied. A maintenance window aligns disruptive work with low-traffic periods for the application, while track selection balances system stability with adoption of new features. In Cloud SQL, this means scheduling index and statistics work and ensuring capacity for upgrades, while in AlloyDB Omni (opens in a new tab) it means using maintenance mode to hold a pod running during updates.
Scheduling database maintenance operations means performing routine upkeep on tables and indexes during windows chosen from application traffic patterns. Cloud SQL maintenance includes peer tasks that address fragmentation and stale statistics. Scheduling also depends on recent changes from normal activity, such as adding a new column or a surge of updates on a table.
The core upkeep tasks are:
For Cloud SQL for SQL Server, upkeep also includes setting a schedule to reorganize or rebuild indexes based on how often data changes, setting an appropriate fill factor to reduce fragmentation, and monitoring for missing indexes.
Preparing the instance for maintenance windows means leaving enough space and sizing so Cloud SQL can complete critical operations and upgrades. The instance should keep at least 20% available space to accommodate maintenance operations performed by Cloud SQL. Table count affects upgrade time, so the goal is under 10,000 tables per instance, and instance size must account for transaction log retention, especially for high write activity.
Preparation also includes storage and growth controls that prevent maintenance from stalling. A disk size of 4 TB or greater provides more throughput and IOPS, and higher vCPU provides more IOPS and throughput. Database files should use autogrow in MBs rather than as a percentage, with proactive growth management before the threshold is reached, and automatic storage increases can scale capacity automatically without manual intervention.
Maintenance mode in AlloyDB Omni is a state that keeps a database pod running while a maintenance update or repair is performed. Maintenance mode applies only to AlloyDB Omni using the container orchestrator deployment option and does not apply to AlloyDB Omni using containers. It works by disabling the liveness probes and startup probes that check whether the database pod is healthy, so Kubernetes does not restart the pod for failed health checks.
When probes are disabled, repair work can proceed without interruption from the orchestrator. After the update or repair is complete, probes are re-enabled so health reporting resumes. Aligning the maintenance window with this lifecycle keeps application traffic away from the pod under repair until it is healthy again.
Exam tip: Maintenance mode disables liveness probes and startup probes to hold the database pod in a running state during repair; it does not apply to AlloyDB Omni using containers.
Maintenance Rescheduling and Exclusion is the practice of moving or holding database maintenance so it does not interrupt critical business periods or peak demand. In Cloud SQL, this means scheduling internal maintenance and instance changes around availability needs. In AlloyDB Omni, this means holding a database pod in a running state while an update or repair is performed.
Rescheduling database maintenance operations means timing recurring upkeep tasks for periods when they will not harm availability. These recurring tasks keep performance stable and should be checked based on when they were last performed and whether normal activity changed. A new column or a large increase in updates to a table can make rescheduling or earlier maintenance necessary.
The recurring tasks to schedule or reschedule are:
For Cloud SQL for SQL Server, set a schedule to reorganize or rebuild indexes depending on how often data changes, set an appropriate fill factor to reduce fragmentation, and monitor for missing indexes. When a performance issue is active, vertically scale first and reschedule deeper tuning, query rewrites, partitioning, or sharding until after the incident.
Preparing the instance so maintenance can succeed means providing room and capacity before the window opens. A Cloud SQL (opens in a new tab) instance must keep at least 20% available space for critical maintenance operations, keep table count ideally under 10,000 tables per instance to limit upgrade time, and be sized to account for transaction and binary log retention on high write activity instances. Without this headroom, maintenance may stall and force a reschedule.
Proactive growth management prevents last-minute capacity failures. Enable automatic storage increases, set autogrow in MBs rather than as a percentage, and manage growth before the autogrow threshold is reached. For large SQL Server workloads, a disk size of 4 TB or greater provides more throughput and IOPS, higher vCPU provides more IOPS and throughput, and symmetric multithreading (SMT) should be turned off if application threads become a bottleneck.
Holding a pod during maintenance in AlloyDB Omni (opens in a new tab) keeps a database pod in a running state while an update or repair is made. Maintenance mode applies only to AlloyDB Omni using the container orchestrator deployment option and does not apply to AlloyDB Omni using containers. It works by disabling the liveness probes and startup probes that Kubernetes uses to check pod health, so Kubernetes does not restart the pod in the middle of the work.
Verification starts by checking the database container for its probes with kubectl get po, using the namespace and database pod name, before disabling them to enter maintenance mode. This hold acts as an exclusion at the pod level because the orchestrator is prevented from interrupting the work. Probes are re-enabled only after maintenance completes.
Avoiding disruptive changes during peak demand means excluding operations that cause extra downtime when repeated too quickly. If an instance is scaled down more than once during a three-hour period, only the first scale down event benefits from near-zero downtime and subsequent scale down events experience regular downtime. The dependency is strict: the second change closely following the first causes the longer outage.
Postpone a second scale down until after the three-hour window when availability matters. When vertical scaling is not sufficient and tuning has not resolved load, route read queries to a read replica to improve overall workload performance. Routing reads to a replica helps avoid changes during peak, although applications may need changes to connect to the read replica.
Exam tip: Only the first scale down in a three-hour period gets near-zero downtime; a second scale down in the same window uses regular downtime, so postpone it outside critical periods.
Last updated