Resources schalen in Azure Database for PostgreSQL - Flexibele server
VAN TOEPASSING OP: 
Azure Database for PostgreSQL - Flexibele server
Azure Database for PostgreSQL - Flexible Server ondersteunt zowel verticale als horizontale schaalopties.
Verticale schaalaanpassing
U kunt uw exemplaar verticaal schalen door meer resources toe te voegen aan uw flexibele serverexemplaren van Azure Database for PostgreSQL. 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 een exemplaar van een flexibele Azure Database for PostgreSQL-server is gemaakt, kunt u onafhankelijk schalen:
- Rekenlaag en SKU.
- Opslaglaag en -grootte.
- Bewaarperiode voor back-ups.
De rekenlaag kan omhoog of omlaag worden geschaald tussen Burstable, Algemeen gebruik en Geoptimaliseerd voor geheugen, om aan te passen aan de behoeften van uw workload. In elk van deze lagen is er een ruime selectie van vooraf geconfigureerde hardware van verschillende generaties en met meer of minder CPU's en meer of minder geïnstalleerd geheugen. Onder die brede selectie kunt u op elk gewenst moment de resourcevereisten kiezen die uw resourcevereisten ondersteunt, terwijl uw operationele kosten worden verlaagd en aangepast aan uw behoeften.
Het aantal vCores en het geïnstalleerde geheugen kan omhoog of omlaag worden geschaald. De opslaglaag kan ook omhoog of omlaag worden geconfigureerd om tegemoet te komen aan de vereisten van doorvoer en IOPS die uw workload nodig heeft. De opslaggrootte kan alleen worden verhoogd. Afhankelijk van uw vereisten kunt u ook de bewaarperiode voor back-ups tussen 7 en 35 dagen verhogen of verlagen.
Deze resources kunnen worden geschaald 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
U kunt uw exemplaar horizontaal schalen 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 kunnen de primaire instantie en de leesreplica's ook verticaal worden geschaald.
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 uw 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, raden we u aan een patroon voor opnieuw proberen van transacties te implementeren.
Voor het schalen van de opslag is in de meeste gevallen geen server opnieuw opgestart. Zie opslagopties in Azure Database for PostgreSQL - Flexible Server voor meer informatie.
Wijzigingen in de back-upretentieperiode zijn een onlinebewerking.
Om de herstarttijd te verbeteren, raden we u aan om schaalbewerkingen uit te voeren tijdens daluren. 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. Vervolgens wordt gesynchroniseerd met de virtuele machine waarop uw exemplaar momenteel wordt uitgevoerd en schakelt u over naar de nieuwe met een korte onderbreking. Vervolgens elimineert een achtergrondproces de oude virtuele machine. Dit proces gebeurt allemaal zonder extra kosten voor u.
Dit proces zorgt voor naadloze updates, terwijl downtime wordt geminimaliseerd en kostenefficiëntie wordt gegarandeerd. Dit schaalproces wordt geactiveerd wanneer er wijzigingen worden aangebracht in de opslag- en rekenlagen. Er is geen actie van de klant vereist om deze mogelijkheid te gebruiken.
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 deze verbindingen niet zijn toegestaan, werkt het schaalproces voor bijna nul downtime niet en wordt schalen uitgevoerd via de standaardwerkstroom voor schalen.
- 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-vastgelegde tabellen voor een van uw gegevens gebruikt, gaan alle gegevens in die tabellen verloren na het schalen van bijna nul downtime.