Our production PostgreSQL Flexible Server is currently unreachable

Hallo Olivier,

Bedankt voor het stellen van je vraag op het Microsoft Windows Forum!

Op basis van de beschrijving van het probleem. Nou! Een productieversie van Microsoft Azure Azure Database for PostgreSQL Flexible Server die meer dan 2,5 uur in de Update-status blijft na een compute scaling-operatie is geen verwacht gedrag. Schaalbewerkingen zijn normaal gesproken binnen enkele minuten afgerond, hoewel grotere instanties of opslaggerelateerde operaties langer kunnen duren. Een database die vastzit in Updaten en verbindingen weigert, kan erop wijzen dat de beheeroperatie geblokkeerd is geraakt of een intern platformprobleem heeft ondervonden.

Allereerst wordt aanbevolen om Azure Service Health and Status te controleren door te controleren of er een lopend incident is dat jouw regio of PostgreSQL Flexible Server treft, en ook zowel de openbare Azure Status-pagina als Service Health te controleren (als je toegang hebt tot het portaal). Voor meer informatie https://azure.status.microsoft/en-us/status . Geef alstublieft niet herhaaldelijk extra scale-, restart- of stop/start-operaties uit. Als de server al in een "Update"-toestand is, blijven aanvullende beheeroperaties meestal in de wachtrij staan of falen ze en kunnen ze het herstel bemoeilijken.

Wanneer je de compute-tier van een Flexible Server schaalt, levert Azure een nieuwe virtuele machine op de achtergrond, synchroniseert de data en wisselt vervolgens de eindpunten. Dit proces vereist beschikbare IP-adressen in je gedelegeerde subnet. Als het gedelegeerde subnet niet over voldoende vrije IP-adressen beschikt om de nieuwe compute-node naast de bestaande te provisioneren, hangt de schaalbewerking onbeperkt vast en wordt niet schoon teruggerold. Om de uitputting van subnet-IP's te onderzoeken door naar Virtual Networks te gaan, selecteer > de VNet > Subnets. Controleer de beschikbare IP's op het subnet dat is gedelegeerd aan Microsoft.DBforPostgreSQL/flexibleServers. Als de beschikbare IP-adressen op 0 of 1 staan, kan dit de oorzaak zijn van de deadlock.

Op basis van dit scenario wordt sterk aanbevolen om een kritisch supportticket aan te maken bij Microsoft Azure. Het verstrekken van de servernaam, regio en operationele ID (uit Activity Logs) om de resolutie te versnellen.

Hopelijk is bovenstaande informatie nuttig!