Schalen van bronnen in Azure Database voor PostgreSQL

Een exemplaar van een flexibele Azure Database for PostgreSQL-server ondersteunt zowel verticale als horizontale schaalopties.

Verticale schaalaanpassing

U kunt uw flexibele serverexemplaar van Azure Database for PostgreSQL verticaal schalen door meer hulpbronnen toe te voegen. U kunt het aantal CPU's en het toegewezen geheugen verhogen of verlagen.

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

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

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

U kunt de rekenlaag op of neer schalen tussen Burstable, Algemeen Doel en Geheugen Geoptimaliseerd om aan te passen aan de behoeften van uw workload. In elk van deze lagen kunt u kiezen uit een brede selectie vooraf geconfigureerde hardware van verschillende generaties met verschillende aantallen CPU's en hoeveelheden geïnstalleerd geheugen. U kunt de optie selecteren die ondersteuning biedt voor uw resourcevereisten, terwijl uw operationele kosten worden verlaagd en aangepast aan uw behoeften.

U kunt het aantal vCores en het geïnstalleerde geheugen omhoog of omlaag schalen. 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.

U kunt deze resources schalen met behulp van meerdere interfaces. U kunt bijvoorbeeld Azure Portal of Azure CLI gebruiken.

Notitie

Nadat u de grootte van de opslag hebt vergroot die aan uw exemplaar is toegewezen, kunt u deze niet verkleinen tot een kleinere grootte.

Horizontale schaalaanpassing

Met elastische Clusters van Azure Database for PostgreSQL kunt u uw database horizontaal uitschalen ter ondersteuning van gegevensworkloads die verder gaan dan de mogelijkheden van één database-exemplaar. Elastische clusters maken het ook mogelijk 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

Een andere benadering voor het horizontaal schalen van uw exemplaar is door leesreplica's te maken. Met leesreplica's kunt u uw leesworkloads schalen naar afzonderlijke exemplaren van flexibele Azure Database for PostgreSQL-servers. Ze hebben geen invloed op de prestaties en beschikbaarheid van het primaire exemplaar.

In een horizontaal geschaalde installatie kunt u ook het primaire exemplaar en de leesreplica's verticaal schalen.

Wanneer u het aantal vCores of de rekenlaag wijzigt, wordt het exemplaar opnieuw opgestart, zodat de nieuwe hardware die is toegewezen, begint met het uitvoeren van de serverworkload. Gedurende deze tijd schakelt het systeem over naar het nieuwe servertype. Er kunnen geen nieuwe verbindingen tot stand worden gebracht 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 back-upretentieperiode zijn een onlinebewerking.

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.

Bijna nul uitvaltijd schalen

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. Er kunnen geen nieuwe verbindingen tot stand worden gebracht tijdens deze overgang naar de nieuwe server.

Normaal gesproken kan dit proces tussen 2 en 10 minuten duren met regelmatige schaalaanpassing. Met de bijna nul downtime-schaalfunctie wordt deze duur teruggebracht 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 exemplaar van flexibele Azure Database for PostgreSQL-servers bijwerkt in schaalscenario's, maakt de service een nieuwe virtuele machine voor uw server met de bijgewerkte configuratie. De synchronisatie vindt plaats met de virtuele machine die momenteel uw exemplaar draait, waarna er wordt overgeschakeld naar de nieuwe virtuele machine, wat een korte onderbreking veroorzaakt. Vervolgens elimineert een achtergrondproces 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 functionaliteit wordt ondersteund voor zowel HA als niet-HA flexibele server-instanties van Azure Database for PostgreSQL.

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 Schalen met leesreplica's voor meer informatie over die reeks.

Notitie

Bijna nul uitvaltijd schalen is het standaardtype bewerking. Wanneer de volgende beperkingen worden aangetroffen, schakelt het systeem over naar regelmatige schaalaanpassing, waarbij meer downtime is in vergelijking met het schalen van bijna nul downtime.

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

• Sta alle binnenkomende en uitgaande verbindingen tussen de IP-adressen in het gedelegeerde subnet toe wanneer u geïntegreerde netwerken van virtuele netwerken gebruikt voor bijna nul uitvaltijd. Als u deze verbindingen niet toestaat, werkt het schaalproces voor bijna geen downtime niet en wordt schalen uitgevoerd volgens de standaard schaalworkflow.
• Schalen met bijna nul downtime werkt niet als er regionale capaciteitsbeperkingen of quotumlimieten voor uw abonnement zijn.
• 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.
• Schalen met bijna nul downtime werkt niet als een virtuele netwerkinjectieserver onvoldoende bruikbare IP-adressen in het gedelegeerde subnet heeft. Als u een zelfstandige server hebt, is er één extra IP-adres nodig. Voor een exemplaar met hoge beschikbaarheid zijn twee extra IP-adressen vereist.
• Logische replicatiesites blijven niet behouden tijdens een failovergebeurtenis van bijna nul. Gebruik de pg_failover_slot-extensie om logische replicatiesites te onderhouden en gegevensconsistentie na een schaalbewerking te garanderen. Zie de pg_failover_slots-extensie inschakelen in een exemplaar van een flexibele 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.

Gerelateerde inhoud

• Azure Database for PostgreSQL beheren