Delen via

Beheertaken voor Azure Cache voor Redis

  • Van toepassing op: ✅ Azure Cache for Redis

In dit artikel worden taken beschreven, zoals het opnieuw opstarten, het leegmaken van een cache, het bijwerken van het updatekanaal en updates plannen voor uw exemplaren van Azure Cache voor Redis.

Opnieuw opstarten

Wanneer u de Basic-, Standard- of Premium-lagen van Azure Cache voor Redis gebruikt, ziet u Opnieuw opstarten in het resourcemenu. Gebruik opnieuw opstarten om een of meer knooppunten van uw cache opnieuw op te starten. Door opnieuw op te starten kunt u uw toepassing testen op tolerantie als er een fout opgetreden is in een cacheknooppunt.

Belangrijk

Opnieuw opstarten is nog niet beschikbaar voor de Enterprise-laag. Opnieuw opstarten is beschikbaar voor alle andere lagen.

Schermopname waarin de menuoptie Opnieuw opstarten is gemarkeerd

Selecteer de knooppunten om opnieuw op te starten en selecteer Opnieuw opstarten.

Schermopname van de knooppunten die u opnieuw kunt opstarten

Als u een Premium-cache hebt waarvoor clustering is ingeschakeld, kunt u selecteren welke shards van de cache opnieuw moeten worden opgestart.

schermopname van shardopties

Als u een of meer knooppunten van uw cache opnieuw wilt opstarten, selecteert u de knooppunten en selecteert u Opnieuw opstarten. Als u een Premium-cache hebt waarvoor clustering is ingeschakeld, selecteert u de shards die u opnieuw wilt opstarten en selecteert u Vervolgens Opnieuw opstarten. Na enkele minuten worden de geselecteerde knooppunten opnieuw opgestart en een paar minuten later weer online.

Het effect op uw clienttoepassingen is afhankelijk van de knooppunten die u opnieuw opstart.

  • Primair : wanneer het primaire knooppunt opnieuw wordt opgestart, voert Azure Cache voor Redis een failover uit naar het replicaknooppunt en wordt dit naar het primaire knooppunt gepromoot. Tijdens deze failover kan er een kort interval zijn waarin verbindingen met de cache kunnen mislukken.
  • Replica : wanneer het replicaknooppunt opnieuw wordt opgestart, heeft dit meestal geen invloed op de cacheclients.
  • Zowel primaire als replica : wanneer beide cacheknooppunten opnieuw worden opgestart, probeert Azure Cache voor Redis beide knooppunten probleemloos opnieuw op te starten, wachtend tot de ene is voltooid voordat de andere opnieuw wordt opgestart. Gegevensverlies treedt doorgaans niet op. Gegevensverlies kan echter nog steeds optreden bij onverwachte onderhouds- of storingen. Als u uw cache meerdere keren achter elkaar opnieuw opstart, neemt de kans op gegevensverlies toe.
  • Knooppunten van een Premium-cache waarvoor clustering is ingeschakeld : wanneer u een of meer knooppunten van een Premium-cache opnieuw opstart met clustering ingeschakeld, is het gedrag voor de geselecteerde knooppunten hetzelfde als wanneer u het bijbehorende knooppunt of de bijbehorende knooppunten van een niet-geclusterde cache opnieuw opstart.

Veelgestelde vragen over opnieuw opstarten

Welk knooppunt moet ik opnieuw opstarten om mijn toepassing te testen?

Als u de tolerantie van uw toepassing wilt testen op fouten in het primaire knooppunt van uw cache, start u het primaire knooppunt opnieuw op. Als u de tolerantie van uw toepassing wilt testen op fouten in het replicaknooppunt, start u het replicaknooppunt opnieuw op.

Kan ik de cache opnieuw opstarten om clientverbindingen te wissen?

Ja, als u de cache opnieuw opstart, worden alle clientverbindingen gewist. Opnieuw opstarten kan handig zijn in het geval dat alle clientverbindingen worden gebruikt vanwege een logische fout of een fout in de clienttoepassing. Elke prijscategorie heeft verschillende clientverbindingslimieten voor de verschillende grootten en zodra deze limieten zijn bereikt, worden er geen clientverbindingen meer geaccepteerd. Het opnieuw opstarten van de cache biedt een manier om alle clientverbindingen te wissen.

Belangrijk

Als u de cache opnieuw opstart om clientverbindingen te wissen, wordt StackExchange.Redis automatisch opnieuw verbonden zodra het Redis-knooppunt weer online is. Als het onderliggende probleem niet is opgelost, kunnen de clientverbindingen mogelijk uitgeput blijven.

Verlies ik gegevens uit mijn cache als ik opnieuw opstart?

Als u zowel de primaire als de replicaknooppunten opnieuw opstart, moeten alle gegevens in de cache of alle gegevens in die shard wanneer u een Premium-cache gebruikt waarvoor clustering is ingeschakeld, veilig zijn. In sommige gevallen kunnen de gegevens echter verloren gaan. Bij het opnieuw opstarten van beide knooppunten moet u voorzichtig zijn.

Als u slechts één van de knooppunten opnieuw opstart, gaan gegevens meestal niet verloren, maar zijn ze mogelijk nog steeds. Als het primaire knooppunt bijvoorbeeld opnieuw wordt opgestart en er een schrijfbewerking in de cache wordt uitgevoerd, gaan de gegevens van de cache-schrijfbewerking verloren. Een ander scenario voor gegevensverlies is als u het ene knooppunt opnieuw opstart en het andere knooppunt uitvalt vanwege een fout op hetzelfde moment.

U moet ook weten dat het opnieuw opstarten van beide knooppunten niet leidt tot het leegmaken van gegevens. Als u gegevens wilt wissen, gebruikt u de flush-procedure vanuit de portalconsole.

Kan ik mijn cache opnieuw opstarten met behulp van PowerShell, CLI of andere beheerhulpprogramma's?

Ja, zie voor PowerShell-instructies om een Azure Cache voor Redis opnieuw op te starten.

Kan ik mijn Enterprise-cache opnieuw opstarten?

Nee. Opnieuw opstarten is nog niet beschikbaar voor de Enterprise-laag. Opnieuw opstarten is beschikbaar voor basic-, Standard- en Premium-lagen. De instellingen die u in het menu Resource onder Beheer ziet, zijn afhankelijk van de laag van uw cache. U ziet opnieuw opstarten niet wanneer u een cache van de Enterprise-laag gebruikt.

Gegevens leegmaken

Wanneer u de Basic-, Standard- of Premium-lagen van Azure Cache voor Redis gebruikt, ziet u Flush data in het resourcemenu. Gebruik Flush-gegevens om alle gegevens in uw cache te verwijderen of leeg te maken . Fluschen kan worden gebruikt voordat schaalvergrotingsbewerkingen worden uitgevoerd om de tijd die nodig is om schaalvergrotingsbewerkingen in de cache te voltooien, te verkorten. U kunt ook configureren dat de flush-bewerking periodiek wordt uitgevoerd op uw dev/test-caches om het geheugengebruik in de gaten te houden.

Tijdens het leegmaken op een geclusterde cache worden gegevens van alle shards tegelijkertijd gewist.

Belangrijk

Voorheen was de flush-bewerking alleen beschikbaar voor geo-gerepliceerde Enterprise-laagcaches. Deze is nu beschikbaar in de Basic-, Standard- en Premium-lagen.

Schermopname van het leegmaken van gegevens die zijn geselecteerd in het resourcemenu van een cache-exemplaar.

Kanaal bijwerken en updates plannen

Wanneer u de Basic-, Standard- of Premium-lagen van Azure Cache voor Redis gebruikt, ziet u Updates inplannen in het resourcemenu. Gebruik planningsupdates om een updatekanaal en een onderhoudsvenster voor uw cache-exemplaar te kiezen.

Elk cache-exemplaar dat het stabiele updatekanaal gebruikt, ontvangt enkele weken later updates dan cache-exemplaren met behulp van het preview-updatekanaal . U wordt aangeraden het preview-updatekanaal te kiezen voor uw niet-productie en minder kritieke workloads. Kies het stabiele updatekanaal voor uw meest kritieke productieworkloads. Alle caches zijn standaard ingesteld op het stabiele updatekanaal.

Belangrijk

Als u het updatekanaal op uw cache-exemplaar wijzigt, krijgt uw cache een patch-gebeurtenis om de juiste updates toe te passen. Overweeg het updatekanaal te wijzigen tijdens het onderhoudsvenster.

Met een onderhoudsvenster kunt u de dagen en tijden van een week beheren waarin de VM's die uw cache hosten, kunnen worden bijgewerkt. Azure Cache voor Redis probeert met de grootste inspanning de Redis-serversoftware te starten en te voltooien binnen het door u opgegeven tijdvenster.

Belangrijk

Het updatekanaal en onderhoudsvenster zijn van toepassing op updates voor Redis-servers en updates voor het besturingssysteem van de VM's die de cache hosten. Het updatekanaal en onderhoudsvenster zijn niet van toepassing op updates van hostbesturingssystemen op de hosts die als host fungeren voor de cache-VM's of andere Onderdelen van Azure-netwerken. In zeldzame gevallen waarin caches worden gehost op oudere modellen, is het onderhoudsvenster ook niet van toepassing op updates van gastbesturingssystemen. U kunt zien of uw cache zich op een ouder model bevindt als de DNS-naam van de cache wordt omgezet in een achtervoegsel van cloudapp.net, chinacloudapp.cnof usgovcloudapi.netcloudapi.de.

Er is momenteel geen optie beschikbaar voor het configureren van een updatekanaal of geplande updates voor een Enterprise-laagcache.

Schermopname van planningsupdates

Als u een onderhoudsvenster wilt opgeven, controleert u de gewenste dagen en geeft u het beginuur van het onderhoudsvenster voor elke dag op. Selecteer vervolgens OK. De tijd van het onderhoudsvenster is in UTC en kan alleen per uur worden geconfigureerd.

Het standaard- en minimale onderhoudsvenster voor updates is vijf uur. Deze waarde kan niet worden geconfigureerd vanuit Azure Portal, maar u kunt deze in PowerShell configureren met behulp van de MaintenanceWindow parameter van de cmdlet New-AzRedisCacheScheduleEntry . Zie Kan ik geplande updates beheren met PowerShell, CLI of andere beheerprogramma's voor meer informatie ?

Veelgestelde vragen over het plannen van updates

Wanneer worden er updates uitgevoerd als ik de functie planningsupdates niet gebruik?

Als u geen onderhoudsvenster opgeeft, kunnen er op elk gewenst moment updates worden uitgevoerd.

Welk type updates worden uitgevoerd tijdens het geplande onderhoudsvenster?

Alleen Redis-serverupdates worden uitgevoerd tijdens het geplande onderhoudsvenster. Het onderhoudsvenster is niet van toepassing op Azure-updates of -updates op het hostbesturingssysteem.

Kan ik geplande updates beheren met PowerShell, CLI of andere beheerhulpprogramma's?

Ja, u kunt uw geplande updates beheren met behulp van de volgende PowerShell-cmdlets:

Kan een update die wordt gedekt en beheerd door de functie Geplande updates, plaatsvinden buiten het venster Geplande updates?

Ja. Over het algemeen worden updates niet toegepast buiten het geconfigureerde venster Geplande updates. Zeldzame kritieke beveiligingsupdates kunnen buiten het patchschema worden toegepast als onderdeel van ons beveiligingsbeleid.

Verwante inhoud

Meer informatie over Azure Cache voor Redis functies.