Share via

PostgreSQL read replica "exists" but cannot be found; cannot delete

Kevin S 95 Reputation points
2026-03-10T18:47:19.92+00:00

We've had an ongoing issue where the "replicas" blade for one of our PostgreSQL flexible servers has not properly shown replicas. We're now decommissioning that server. The replica has already been deleted, but we kept the primary around for a bit longer. Upon trying to delete the primary, I see:

Error Code: "ReadReplicaServersExistForSourceServer"

Message: "Server (redacted) has '1' active replicas.Drop operation on server with replicas not allowed.

Great, except. I cannot see any replicas in the portal.

The metadata for the replica exists on the PostgreSQL instance I am trying to delete, but any attempts to find that instance in our subscription have failed. As far as I know, we operate in a single subscription and single tenant, so I should be able to find it.

Apparently I cannot create a support ticket from within Azure, despite being on the paid support plan, so details have been omitted here. Because the replicas blade seems to be broken, this sounds like a problem with Azure.

Azure Database for PostgreSQL

Answer accepted by question author
  1. Pilladi Padma Sai Manisha 6,665 Reputation points Microsoft External Staff Moderator
    2026-03-10T18:55:49.83+00:00

    Hi Kevin S
    Thankyou for reaching microsoft Q&A!
    Thank you for the additional details. The information that the service reports a GeoAsyncReplica in East US (parallax-dev-flex-database-replica) while the server is in Central US, combined with the ResourceNotFound response and the “Failed to load replicas” message in the portal, strongly suggests that the replica resource itself has already been deleted but the replication relationship metadata still exists on the source server.

    In Azure Database for PostgreSQL Flexible Server, when a Geo-replica is created, the platform maintains an internal replication mapping between the source server and the replica server. If the replica resource is removed but the metadata cleanup does not complete successfully, the control plane may still register that replica as active. Because of that, when you attempt to delete the primary server the service validation detects an existing replica and returns the error ReadReplicaServersExistForSourceServer, even though the replica cannot be found in the portal or through the API.

    The ResourceNotFound result when attempting to inspect parallax-dev-flex-database-replica further indicates that the replica resource itself no longer exists and what remains is likely an orphaned replication reference. The portal error “Failed to load replicas” is also consistent with this scenario because the UI cannot resolve the replica ID that still exists in the backend metadata.

    The resize of the server from General Purpose to Burstable should not directly cause this condition, but if the server had an existing geo-replication relationship earlier, the metadata for that relationship may still be attached to the source server even after the replica deletion.

    Since the replica resource is no longer accessible, there is typically no customer-side action that can remove this reference. This usually requires backend intervention to clear the stale GeoAsyncReplica relationship from the server metadata so the source server can be deleted successfully.

    1 person found this answer helpful.
    0 comments No comments

1 additional answer

Sort by: Most helpful
  1. Kevin S 95 Reputation points
    2026-03-12T20:34:56.67+00:00

    Issue was resolved after Azure staff were able to update the metadata to allow the replica to show up in the portal.

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.