We encountered a support case involving Azure Database for PostgreSQL Flexible Server where the database returned a read-only error after a High Availability (HA) failover. This blog explains the root cause, resolution steps, and best practices to prevent similar issues.
Co-authored with HaiderZ-MSFT
The issue occurred when the application attempted write operations immediately after an HA failover. The failover caused the primary role to switch, but the client continued connecting to the old primary (now standby), which is in read-only mode.
Symptoms
- Application writes failures during transactions
- Errors indicating read-only mode
- Example error:
ERROR: cannot execute %s in a read-only transaction
Root Cause
The root cause was a DNS resolution mismatch after the HA failover. When the primary server role shifted to the standby instance, the private IP address changed.
If the application was configured to connect using:
- A static IP address instead of the FQDN, or
- A custom/private DNS record that wasn’t updated post-failover,
…the client connected to the old primary, which is now read-only.
Contributing Factors
- Hardcoded IP addresses in connection strings
- Private DNS records not updated after failover
- Lack of DNS validation during failover events
Specific Conditions
- HA-enabled server with VNET integration
- Planned or unplanned failover occurred
Mitigation Steps
To resolve the issue:
- Update DNS configuration to ensure the application connects via FQDN (<servername>.postgres.database.azure.com).
- Verify DNS resolution using nslookup from the client network:
nslookup yourservername.postgres.database.azure.com - For private DNS zones, update the A record to point to the current primary IP.
Post-resolution:
- Application successfully connected to the primary server
- Write operations resumed without errors
Prevention & Best Practices
- Always use FQDN in connection strings; avoid hardcoding IP addresses
- Implement retry logic in applications to handle transient errors during failover
- Regularly validate DNS resolution for HA-enabled servers
- For private DNS zones, ensure A records are updated automatically or monitored after failover
Reference: https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-monitor-high-availability
Why This Matters
Failing to use FQDN or properly configure DNS can lead to:
- Application downtime during failover
- Read-only errors impacting business-critical transactions
By following these practices, customers can ensure seamless failover and maintain high availability without manual intervention.
Microsoft