Resources opschalen in Azure Database for PostgreSQL Flexible Server

Een Azure Database for PostgreSQL flexibele server ondersteunt zowel verticale als horizontale schaalopties.

Verticaal schalen

Schaal uw server verticaal door meer resources toe te voegen aan uw Azure Database for PostgreSQL flexibele server. U kunt het aantal CPU's en het toegewezen geheugen verhogen of verlagen.

De netwerkdoorvoer van uw server is afhankelijk van de waarden die u kiest voor CPU en geheugen.

Nadat u een Azure Database for PostgreSQL flexibele server hebt gemaakt, kunt u onafhankelijk schalen:

• Rekenlaag en SKU.
• Opslaglaag en -grootte.
• Bewaarperiode voor back-ups.

Schaal de rekencategorie omhoog of omlaag tussen Burstable, General Purpose en Memory Optimized om deze af te stemmen op de behoeften van uw workload. Kies in elk van deze lagen uit een brede selectie vooraf geconfigureerde hardware van verschillende generaties met verschillende aantallen CPU's en hoeveelheden geïnstalleerd geheugen. Selecteer de optie die uw resourcevereisten ondersteunt, terwijl uw operationele kosten lager blijven en aangepast aan uw behoeften.

Schaal het aantal vCores en het geïnstalleerde geheugen omhoog of omlaag. U kunt de opslaglaag ook omhoog of omlaag configureren om tegemoet te komen aan de doorvoer- en IOPS-vereisten die uw workload vereist. U kunt alleen de opslaggrootte vergroten. Afhankelijk van uw vereisten kunt u de bewaarperiode voor back-ups tussen 7 en 35 dagen verhogen of verlagen.

Schaal deze resources met behulp van meerdere interfaces. U kunt bijvoorbeeld de Azure-portal of Azure CLI gebruiken.

Horizontaal schalen

Met elastische clusters van Azure Database for PostgreSQL kunt u uw database horizontaal uitschalen om gegevensworkloads te ondersteunen die verder gaan dan de capaciteit van één databaseserver. Elastische clusters bieden ook de mogelijkheid om parallelle bewerkingen tegelijkertijd uit te voeren op alle knooppunten in een cluster, waardoor de doorvoer aanzienlijk toeneemt en ultra-lage latentie wordt ontgrendeld. Elastische clusters bieden twee tabel-shardingmodellen: op rijen gebaseerde sharding en op schema gebaseerde sharding.

Schaalbaarheid van leesreplica's

U kunt uw server horizontaal schalen door leesreplica's te maken. Met leesreplica's kunt u uw leesworkloads opschalen naar afzonderlijke flexibele Azure Database for PostgreSQL-servers. Ze hebben geen invloed op de prestaties en beschikbaarheid van de primaire server.

In een horizontaal geschaalde configuratie kunt u ook de primaire server en de leesreplica's verticaal schalen.

Wanneer u het aantal vCores of de rekenlaag wijzigt, wordt de server opnieuw opgestart zodat de nieuwe hardware die is toegewezen, begint met het uitvoeren van uw serverworkload. Gedurende deze tijd schakelt het systeem over naar het nieuwe servertype. U kunt geen nieuwe verbindingen tot stand brengen en alle niet-doorgevoerde transacties worden teruggedraaid.

De totale tijd die nodig is om de server opnieuw op te starten, is afhankelijk van het crashherstelproces en de databaseactiviteit op het moment van het opnieuw opstarten. Het opnieuw opstarten duurt meestal een minuut of minder, maar dit kan enkele minuten duren. De tijdsinstellingen zijn afhankelijk van de transactionele activiteit wanneer de herstart is gestart.

Als uw toepassing gevoelig is voor verlies van in-flight transacties die kunnen optreden tijdens het schalen van berekeningen, implementeert u een patroon voor opnieuw proberen van transacties.

Voor het schalen van de opslag is in de meeste gevallen geen server opnieuw opgestart. Zie opslagopties in Azure Database for PostgreSQL voor meer informatie.

Wijzigingen in de bewaartermijn van back-ups kunnen online worden uitgevoerd.

Voer schaalbewerkingen uit tijdens daluren om de herstarttijd te verbeteren. Deze aanpak vermindert de tijd die nodig is om de databaseserver opnieuw op te starten.

Opschalen met vrijwel geen uitvaltijd

Bijna nul uitvaltijd schalen is een functie die is ontworpen om downtime te minimaliseren wanneer u opslag- en rekenlagen wijzigt. Als u het aantal vCores wijzigt of de rekenlaag wijzigt, wordt de server opnieuw opgestart om de nieuwe configuratie toe te passen. Tijdens deze overgang naar de nieuwe server kunt u geen nieuwe verbindingen tot stand brengen.

Normaal gesproken duurt dit proces 2 tot 10 minuten met regelmatige schaalaanpassing. Door de schaalfunctie met vrijwel geen uitvaltijd te gebruiken, verkort u deze duur tot minder dan 30 seconden. Deze vermindering van downtime tijdens het schalen van resources verbetert de algehele beschikbaarheid van uw database-exemplaar.

Hoe het werkt

Wanneer u uw Azure Database for PostgreSQL flexibele server bijwerkt in schaalscenario's, maakt de service een nieuwe virtuele machine voor uw server met de bijgewerkte configuratie. Vervolgens synchroniseert het met de virtuele machine waarop uw server momenteel draait en schakelt het daarna met een korte onderbreking over naar de nieuwe virtuele machine. Een achtergrondproces elimineert de oude virtuele machine.

Dit proces maakt naadloze updates mogelijk met minimale downtime en wordt automatisch geactiveerd wanneer u opslag- of rekenlagen wijzigt. U hoeft geen actie te ondernemen om deze mogelijkheid te gebruiken. Deze mogelijkheid wordt ondersteund voor zowel HA- als niet-HA-configuraties van de Azure Database for PostgreSQL - Flexibele server.

Voor horizontaal geschaalde configuraties, bestaande uit een primaire server en een of meer leesreplica's, moeten schaalbewerkingen een specifieke volgorde volgen om gegevensconsistentie te garanderen en downtime te minimaliseren. Zie voor meer informatie over die volgorde schalen met leesreplica’s.

Exacte downtime-verwachtingen

• Duur van downtime: in de meeste gevallen varieert de downtime van 10 tot 30 seconden.
• Andere overwegingen: Na een schaalbeurt is er een inherente DNS-periode Time-To-Live (TTL) van ongeveer 30 seconden. Het schaalproces bepaalt deze periode niet rechtstreeks. Het is een standaardonderdeel van DNS-gedrag. Vanuit het perspectief van een toepassing kan de totale downtime tijdens het schalen binnen 40 tot 60 seconden liggen.

Overwegingen en beperkingen

• Om schalen met vrijwel geen downtime mogelijk te maken, staat u alle inkomende en uitgaande verbindingen tussen de IP-adressen in het gedelegeerde subnet toe wanneer u integratie met een virtueel netwerk gebruikt. Als u deze verbindingen niet toestaat, werkt het schaalproces voor bijna geen downtime niet en wordt schalen uitgevoerd volgens de standaard schaalworkflow.
• Bijna zonder downtime schalen is niet mogelijk als er regionale capaciteitsbeperkingen zijn of als er quotumbeperkingen voor uw abonnement gelden.
• Uitvaltijd bijna nul werkt niet voor een replicaserver, omdat deze alleen wordt ondersteund op de primaire server. Voor replicaservers doorloopt de schaalbewerking automatisch het normale proces.
• Opschalen met vrijwel geen downtime werkt niet als een server met injectie in een virtueel netwerk niet voldoende bruikbare IP-adressen heeft in het gedelegeerde subnet. Als u een zelfstandige server hebt, is er één extra IP-adres nodig. Voor een server met hoge beschikbaarheid zijn twee extra IP-adressen vereist.
• Logische replicatieslots worden niet behouden tijdens een failovergebeurtenis met bijna geen downtime. Gebruik de pg_failover_slot-extensie om logische replicatieslots te behouden en gegevensconsistentie na een schaalactie te waarborgen. Zie de extensie pg_failover_slots inschakelen in een instantie van Flexible Server voor meer informatie.
• Het schalen van bijna nul downtime werkt niet met niet-vastgelegde tabellen. Als u niet-gelogde tabellen voor een van uw gegevens gebruikt, verliest u alle gegevens in die tabellen na schalen met bijna nul uitvaltijd.
• Near-zero werkt niet als u de rekenkracht van uw server schaalt van of naar een rekenkracht van 1 of 2 vCores van de Burstable-laag.

Verwante inhoud

• Azure Database for PostgreSQL beheren