Issue with Cloud SQL HA Failover - Zone did not change post failover

We have CloudSQL HA with a read only replica instance.

Recently, we have received the following alert in our Cloud SQL HA instance: "Cloud SQL Database - Available for failover (Deprecated) is above threshold of 0.5 with a value of 1".

Our primary zone is zone-b, standby is in zone-c, and replica is in zone-d.

Despite no Cloud SQL and operation logs during the incident, our setup didn't execute the failover as expected. Zone-b retained primary status instead of transitioning to zone-c. While there was no downtime detected, the reason for this anomaly is unclear.

Any insights on potential issues would be appreciated for further investigation.

Below is the graph that shows the failover of master database:

GeorgeJackBand_0-1711566126635.png

 

0 2 100
2 REPLIES 2

The alert you received, "Cloud SQL Database - Available for failover (Deprecated) is above a threshold of 0.5 with a value of 1," highlights a condition potentially necessitating a failover event in your Cloud SQL HA setup. However, the lack of an actual failover, despite this alert, can be attributed to various factors. A deeper dive into Cloud SQL's high availability (HA) management, failover mechanisms, and your specific configuration nuances is crucial for unraveling this anomaly.

Cloud SQL's automatic failover mechanism activates under certain conditions:

  • Unavailability of the Primary Instance: Scenarios include the primary instance becoming unresponsive due to hardware failures, network disruptions, or significant infrastructure issues.

  • Zone Outages: Failover is initiated if the zone hosting the primary instance experiences an outage.

  • Manual Initiation: Users also have the option to manually trigger a failover.

These mechanisms are designed with precision to minimize disruption, employing thorough health checks that assess not only basic availability and response times but also the instance's capacity to manage request loads effectively.

Several factors could explain the absence of a failover in your scenario:

  • Temporary or Borderline Conditions: The detected condition might have been transient or insufficiently severe to justify a failover, such as a brief network glitch.

  • Health Checks Passed: Despite the alert, the primary instance might have consistently passed health checks, indicating its effectiveness in handling requests, albeit with slightly degraded metrics.

  • Failover Settings and Sensitivity: Your Cloud SQL instance's failover sensitivity settings may require more pronounced conditions to trigger an automatic failover.

  • Deprecated Alert: The "Deprecated" status of the alert suggests it originates from an older monitoring system. It's essential to integrate such alerts with the latest monitoring tools and alerts for a comprehensive system health overview.

To further investigate the incident, consider the following steps:

  • Review Cloud SQL and Audit Logs: Re-examine Cloud SQL operation logs and Cloud audit logs around the incident timeframe for signs of health check failures, failover evaluations, or administrative activities that might have influenced the Cloud SQL instance's behavior.

  • Examine Resource Utilization Metrics: Investigate anomalies in resource utilization (CPU, memory, disk I/O, network bandwidth) in Cloud Monitoring, as these can lead to performance issues without necessarily triggering a failover.

  • Assess Recent Configuration Changes: Review any recent changes to the Cloud SQL instance or its network configuration that might have impacted the failover mechanism or instance communication, utilizing version-controlled history for a precise analysis.

Additional Considerations

  • Failover Testing: Conducting controlled failover tests, if not already done, can validate the failover process and uncover any configuration issues or areas for improvement. These tests should mimic real-world scenarios, including peak load times and various failure simulations, to ensure robustness.

  • Review Documentation and Best Practices: Align your setup with the latest Cloud SQL documentation and best practices for high availability and failover configurations. 

  • Engaging with Google Cloud Support: Should the above steps not clarify the situation, reach out to Google Cloud Support with detailed information about your setup, the incident, and your findings for a deeper investigation.

The complexity of high availability setups in cloud environments necessitates ongoing, proactive monitoring, testing, and configuration adjustments. Documenting and analyzing incidents like the one you've encountered is part of a continuous improvement process, ensuring that your Cloud SQL instances are optimally configured for resilience and availability. By adopting a proactive stance towards monitoring and leveraging community wisdom and updated documentation, you can anticipate and mitigate potential issues, maintaining a robust and reliable Cloud SQL HA setup.

Thank you for the thorough explanations provided. We will carefully assess your guidance and proceed with an in-depth investigation into the matter.