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
Metric Selection and Dashboard Visualization is the practice of choosing the right database measurements and showing them together so teams can protect availability and performance. In Google Cloud, Cloud Monitoring (opens in a new tab) collects measurements from services and resources and provides both a predefined Cloud SQL dashboard and custom dashboards. Cloud SQL (opens in a new tab) uses built-in memory custom agents to collect query telemetry, so primary, standby, and read-replica signals can be viewed at both the database level and the instance level.
Cloud Monitoring is the central system for collecting measurements and visualizing database health and capacity use. The service provides predefined dashboards for many Google Cloud components, including Cloud SQL, which help identify health and capacity issues without manual setup. Teams can also create custom dashboards to monitor chosen metrics side by side and set up alert policies for timely notifications. Third-party solutions integrated with Google Cloud, such as Datadog and Splunk, are an alternative when teams already use those tools.
Core metrics for primary instances are the resource and traffic signals that show whether an instance is constrained or approaching a limit. These metrics can be viewed in summarized form in the Google Cloud console, in the same way Oracle Enterprise Manager Top Activity Graphs show session or SQL activity. Monitoring the primary together with its replicas gives a complete view of load, capacity, and failover readiness.
Storage and connection signals deserve special attention because they directly affect high-availability actions. Automatic storage increases can grow capacity as data grows, but instances still need buffer for peak workloads because usage tends to increase over time. A metrics-based alerting policy on disk utilization can notify teams if available space falls below 20%.
High-availability indicators for standby and read replicas show whether a failover target is in sync and ready to take traffic. Read replicas are monitored the same way as the primary instance in the Google Cloud console, plus a dedicated replication-delay metric that measures lag from the primary instance to the read-replica instance in bytes. That lag can be checked from the read-replica instance overview tab in the Google Cloud console, with gcloud sql instances describe REPLICA_NAME for replication status, and with select * from pg_stat_replication; from a PostgreSQL client.
The standby instance and the read replica have different purposes, sync methods, and visibility, so dashboards must interpret them differently:
| Option | Purpose | How it stays in sync | Open for reads |
|---|---|---|---|
| High-availability standby instance | Automatic failover target for the primary | Disk-level replication, not open for reads or writes | No |
| Read replica | Offload read traffic from the primary | Asynchronous replication, can be in a different zone or region | Yes |
The standby instance fails over automatically when the primary goes down or becomes unresponsive for approximately 60 seconds, and roles swap within a few seconds so the new primary takes over. Read replicas are designed to scale reads, not to serve as the disaster-recovery standby, and adding high availability to an existing primary can require an instance reboot. Because of this split, dashboards should show replication lag in bytes for each replica alongside active connections and storage usage for both primary and standby locations.
Exam tip: Replication delay for Cloud SQL for PostgreSQL read replicas is monitored in bytes from the read-replica overview, while the high-availability standby uses disk-level replication and is not open for reads or writes.
Query-level visibility connects high-level resource metrics to the specific sessions and statements causing pressure. The predefined Query Insights dashboard in Cloud Monitoring identifies the most expensive commands so teams can optimize them before they exhaust CPU, memory, or connections. Cloud Logging (opens in a new tab) is the main platform for postgres.log entries, with filtering by event level such as Critical, Error, or Warning, plus timeframe and free-text filtering, and it supports additional monitoring metrics for Cloud SQL for PostgreSQL.
Routine database checks use live PostgreSQL views that parallel Oracle dynamic performance views. Session activity is checked by querying pg_stat_activity, which is the counterpart to Oracle V$SESSION and V$PROCESS for real-time insight. Long-running queries are found by filtering pg_stat_activity on columns such as query_start and state, while lock problems are checked in pg_locks for real-time information about locks that can hurt performance.
Custom dashboards and alert policies turn selected metrics into a shared operational view with rapid response. A custom dashboard brings primary and standby signals together, including replication lag, active connections, CPU utilization, memory usage, and storage usage across zones and regions. An alert policy on the same metrics, such as disk utilization falling below 20% free space, sends timely notifications before maintenance or failover is blocked. Do not start a new administrative operation before the previous operation has completed, and use a configured maintenance window to control when disruptive updates can occur.
Alerting Policies and Incident Notification is the automated link between database monitoring and rapid response for highly available databases. Cloud Monitoring (opens in a new tab) continuously collects measurements from Google Cloud resources, evaluates those measurements against defined thresholds, and sends timely notifications to configured notification methods when a threshold is breached. For highly available databases, this flow runs from the database instance to Cloud Monitoring to the on-call team, so failover events, instance unavailability, and resource exhaustion are detected without manual checking.
The central monitoring foundation for alerts is Cloud Monitoring observing both database activity and instance resource use in one place. Cloud Monitoring collects measurements of the service and the Google Cloud resources in use, and it includes predefined dashboards for several Google Cloud products, including a Cloud SQL monitoring dashboard. Cloud SQL (opens in a new tab) uses built-in agents to collect query telemetry into that system, so database-level activity and instance-level resource use appear together where all team members can see them.
Custom dashboards and alert policies build on that centralized data. Teams can create custom dashboards to monitor specific metrics and set up alert policies so they receive timely notifications when availability is threatened. Third-party monitoring solutions that are integrated with Google Cloud, such as Datadog and Splunk, are an alternative for teams that already standardize on those tools.
Availability alerting starts with a defined monitoring procedure that covers both system-down events and early warning signs. A complete procedure tracks failures that already happened and resource pressure that could cause the next failure, which gives teams time to intervene before failover is required.
Common items to track for highly available databases include:
A replication lag alert measures how far a Cloud SQL failover replica is behind its primary and warns before that lag makes failover slow or risky. The time required for a failover operation depends on the amount of replication lag when failover is initiated, so the alert uses the Seconds Behind Master metric with a threshold above normal. A common starting point is above 120 seconds for 3 minutes, adjusted to what is appropriate for the environment.
A newly created Cloud SQL instance can take time to appear in the Cloud Monitoring interface. If a new instance is not visible as an alert target, check again in an hour before troubleshooting the policy itself. To create a metric-threshold alert for a specific failover replica:
The same condition works for a group of replicas by changing only the target. For Applies To, select Group, select the failover group, and leave Any Member Violates selected, so data flows from any lagging replica in the group to a single incident notification.
Exam tip: Failover downtime caused by replication lag greater than 1200 seconds is not counted against the instance SLA, so a 120-second alert for 3 minutes is an early warning long before that SLA boundary.
Group-based alerting is the scalable way to monitor multiple failover replicas in the same project without creating one policy per replica. The group depends on a consistent naming convention, such as ending every failover replica name with -failover, and that suffix must not be used for any other type of Cloud SQL instance. A Cloud Monitoring group is then created with a Name Contains rule for that substring, and the summary page is used to confirm that the expected instances are included as resources.
Cloud Monitoring uses the term instances to mean virtual machines (VMs) and VM clusters, so the Groups Overview page may show 0 instances for a Cloud SQL group. Cloud SQL instances appear under Resources instead, which is the correct place to verify membership. Once membership is correct, one alerting policy that targets the group with Any Member Violates covers every current and future replica that matches the naming rule.
A storage-capacity alert protects availability by warning before maintenance and normal growth run out of space. Cloud SQL instances should keep at least 20% available space to accommodate critical database maintenance operations that Cloud SQL might perform. A metrics-based alerting policy on the disk utilization metric sends a notification when available disk space falls below that 20% level, so storage can be increased before writes stall or maintenance fails.
This alert works alongside planned controls such as a maintenance window for the primary instance. The maintenance window controls when disruptive updates can occur, while the disk-space alert provides continuous protection between those windows. Together they ensure that both scheduled changes and unexpected growth are handled without losing availability.
Log Analysis and Diagnostic Auditing is the practice of using logs, metrics, and traces to audit what a database did and to explain why a problem happened. For highly available Cloud SQL (opens in a new tab) databases, telemetry flows from the database instance and the connected application into centralized Google Cloud observability services, where logs show events and operations, metrics show health and performance over time, and traces show request latency. Correlating these signals lets teams audit operations, separate application problems from cloud platform problems, and investigate failover and performance events with a shared view at the database and instance level.
Centralized telemetry collection is the automated gathering of database telemetry into one place where all team members can see database and instance activity. Cloud SQL uses built-in memory custom agents to collect query telemetry, which lowers performance impact and removes agent maintenance and security overhead. When telemetry is collected over time under different load conditions, it establishes a baseline that makes later anomalies and failover-related changes easier to recognize. Implement this monitoring early, such as before a migration or before deploying a new application to production, so current behavior can be compared against past trends.
Telemetry for diagnostic auditing comes in three complementary forms:
Cloud Logging (opens in a new tab) is the service that collects logging data from common application components and Cloud SQL instances for audit and troubleshooting. Log data from Cloud Logging provides the operation-level record used to audit database activity and to review the sequence of events around slow operations, errors, and failover events. For Cloud SQL specifics, instance logs provide the database and instance-level detail that teams review during diagnosis.
Cloud Monitoring (opens in a new tab) is the service that collects measurements from Google Cloud resources and includes a predefined Cloud SQL monitoring dashboard. Teams can also create custom dashboards to watch selected metrics and set up alert policies to receive timely notifications when thresholds are crossed. Third-party solutions integrated with Google Cloud, such as Datadog and Splunk, are an alternative when an organization already standardizes on them.
| Service | What it collects | Diagnostic use |
|---|---|---|
| Cloud Logging | Logging data from application components and Cloud SQL instance logs | Audit database operations and reconstruct event sequences |
| Cloud Monitoring | Measurements of services and Google Cloud resources, including query telemetry | Track health and capacity, compare trends, and trigger alerts |
| Cloud Trace | Latency data and executed query plans from instrumented applications | Follow request paths and detect shifts in latency profiles |
Logs answer what happened, metrics show when behavior departed from baseline, and traces show where time was spent along the request path.
Correlating application context with database performance means linking application code and requests to the SQL statements and latency they produce. Cloud Trace collects latency data and executed query plans, supports comparison of latency distributions over time or across versions, and alerts when it detects a significant shift in an instrumented application's latency profile. This makes it possible to see whether higher latency started after a deployment, during a load change, or around a failover window.
Sqlcommenter is an OpenTelemetry library that strengthens this correlation by automatically instrumenting object-relational mappers (ORMs) to add tags to SQL statements. Trace context information flows from the application through Sqlcommenter to the database, so a database statement can be tied back to its originating application code. With tags and trace context in the database, teams can more easily troubleshoot microservices architectures where many services share the same highly available database.
Exam tip: Use Cloud Logging to audit operation events, Cloud Monitoring to track metric trends and alerts, and Cloud Trace plus Sqlcommenter tags to link slow database work to specific application code.
The Cloud SQL System Insights dashboard is the high-level view of overall database health and performance. The dashboard displays graphs for important signals such as throughput, latency, and cost, which help teams respond proactively as application needs change. By comparing current performance against past trends, teams can identify anomalies that need investigation and judge whether an issue looks like an application regression, resource saturation, or an underlying cloud event.
The Query Insights dashboard in Cloud Monitoring supports deep-dive query analysis by helping identify the most expensive commands for optimization. The Cloud SQL Overview page also shows graphs for key metrics for quick checks during an incident. In a failover investigation, the diagnostic pattern is first to confirm the event timing in logs, then to correlate that timing with System Insights throughput and latency changes and with Query Insights evidence of costly queries or resource pressure. This correlation prevents treating a symptom, such as slow queries after failover, as the root cause when metrics point to memory, CPU, or locality constraints.
Last updated