Beheer van Azure Cache voor Redis

In dit artikel wordt beschreven hoe u beheertaken uitvoert, zoals het opnieuw opstarten en bijwerken van kanalen en updates plannen voor uw Azure Cache voor Redis exemplaren.

Opnieuw opstarten

Aan de linkerkant kunt u met Opnieuw opstarten een of meer knooppunten van uw cache opnieuw opstarten. Met deze mogelijkheid voor opnieuw opstarten 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, Azure Cache voor Redis failover naar het replicaknooppunt en bevordert het naar het primaire. Tijdens deze failover is er mogelijk een kort interval waarin verbindingen de cache niet kunnen gebruiken.
  • 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, waarna de ene knooppunten zijn 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 elke clientverbinding wordt 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, worden de clientverbindingen mogelijk nog steeds gebruikt.

Verlies ik gegevens uit mijn cache als ik opnieuw opstart?

Als u zowel de primaire als de replicaknooppunten opnieuw opstart, zijn alle gegevens in de cache (of in die shard wanneer u een Premium-cache gebruikt waarvoor clustering is ingeschakeld) waarschijnlijk veilig. In sommige gevallen gaan de gegevens echter verloren. 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. Zie Wat is er gebeurd met mijn gegevens in Redis voor meer informatie over mogelijke oorzaken voor gegevensverlies ?

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 status 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. Met de bewerking Gegevens leegmaken kunt u alle gegevens in uw cache verwijderen of leegmaken . Deze flush-bewerking kan worden gebruikt voordat schaalbewerkingen worden uitgevoerd om de benodigde tijd voor het voltooien van de schaalbewerking in uw cache 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. Het is nu beschikbaar in 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

Aan de linkerkant kunt u planningsupdates kiezen voor een updatekanaal en een onderhoudsvenster voor uw cache-exemplaar.

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 doet er alles aan om redis-serversoftware te starten en bij te werken binnen het opgegeven tijdvenster dat u definieert.

Belangrijk

Het updatekanaal en onderhoudsvenster zijn van toepassing op updates en updates van Redis-servers voor het besturingssysteem van de VM's die als host fungeren voor de cache. 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, waarbij 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.cnusgovcloudapi.net of cloudapi.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.

Meer informatie over Azure Cache voor Redis functies.