Gepland onderhoud in Azure Database for MySQL

Azure Database for MySQL voert periodiek onderhoud uit om uw beheerde database veilig, stabiel en up-to-date te houden. Tijdens het onderhoud krijgt de server nieuwe functies, updates en patches.

Onderhoudscyclus

In de volgende secties worden de onderhoudstypen beschreven. Raadpleeg de releaseopmerkingen voor specifieke informatie over wat elke onderhoudsupdate inhoudt. Deze notities bevatten uitgebreide informatie over de updates die tijdens het onderhoud worden toegepast, zodat u de wijzigingen die van invloed zijn op uw omgeving, kunt begrijpen en voorbereiden.

Routineonderhoud

Onze standaard onderhoudscyclus is niet minder frequent dan elke 30 dagen. Deze periode zorgt voor systeemstabiliteit en -prestaties en minimaliseert onderbreking van uw services.

Kritiek onderhoud

In bepaalde scenario's, zoals de noodzaak om urgente beveiligingsoplossingen of updates te implementeren die essentieel zijn voor het behoud van beschikbaarheid en gegevensintegriteit, kunnen we vaker onderhoud uitvoeren. Deze uitzonderingen helpen uw gegevens te beschermen en ervoor te zorgen dat uw services continu worden uitgevoerd.

Virtueel Canary-onderhoud

Virtual Canary is een experimenteel onderhoudsprogramma dat vroege toegang biedt tot updates. Hiermee kunnen klanten de compatibiliteit van workloads testen met nieuwe Versies van Azure Database for MySQL en feedback geven over nieuwe functies.

In tegenstelling tot routineonderhoud volgt Virtual Canary niet de minimale tussenruimte van 30 dagen of de meldingsperiode van 7 dagen. Dit programma helpt klanten proactief nieuwe functies te valideren en vroege feedback te geven voor productverbeteringen. Burstable-laagservers, die vaak worden gebruikt voor niet-productieomgevingen, worden automatisch ingeschreven in het Virtual Canary-programma.

Virtuele Canary-aanmelding

Azure Database for MySQL biedt klanten flexibiliteit om hun deelname aan het Virtual Canary-programma te beheren. Klanten kunnen zich indien nodig afmelden voor het programma voor afstemming met hun operationele vereisten.

Gebruik de volgende opdracht om te controleren of uw server is ingeschreven in het Virtual Canary-programma. Als het resultaat "patchStrategy": "VirtualCanary" bevat, wordt de server geregistreerd in het programma.

az mysql flexible-server show --resource-group {resourcegroupname} --name {servername} --query "maintenancePolicy"

Voer de volgende opdracht uit om een server in te schrijven in het Virtual Canary-programma:

az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy VirtualCanary

Als u het Virtual Canary-programma wilt verlaten en wilt terugkeren naar het standaardonderhoudsbeleid, gebruikt u deze opdracht:

az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy Regular

Onderhoudsvensters

U kunt onderhoud op een specifieke dag van de week en een tijdvenster binnen die dag plannen. Of u kunt het systeem automatisch een dag en een tijdvenster laten kiezen. Hoe dan ook, het systeem waarschuwt u zeven dagen voordat er onderhoud wordt uitgevoerd. Het systeem geeft ook aan wanneer het onderhoud wordt gestart en wanneer het is voltooid.

Meldingen over gepland gepland onderhoud kunnen zijn:

• E-mail verzonden naar een specifiek adres.
• E-mail verzonden naar een Azure Resource Manager-rol.
• Verzonden in een sms-bericht naar mobiele apparaten.
• Gepusht als een melding naar een Azure-app.
• Geleverd als een voicemailbericht.

Wanneer u voorkeuren voor het onderhoudsschema opgeeft, kunt u een dag van de week en een tijdvenster kiezen. Als u geen voorkeuren opgeeft, kiest het systeem tijden tussen 11:00 en 7:00 uur in de regiotijd van uw server. U kunt verschillende planningen definiëren voor elke flexibele server in uw Azure-abonnement.

U kunt planningsinstellingen op elk gewenst moment bijwerken. Als onderhoud is gepland voor uw flexibele server en u de planningsvoorkeuren bijwerkt, wordt de huidige implementatie uitgevoerd zoals gepland. De wijziging in de planningsinstellingen wordt van kracht na voltooiing van het volgende geplande onderhoud.

U kunt een door het systeem beheerde planning of een aangepast schema definiëren voor elke flexibele server in uw Azure-abonnement:

• Met een aangepast schema kunt u uw onderhoudsvenster voor de server opgeven door de dag van de week en een tijdvenster van één uur te kiezen.
• Met een door het systeem beheerd schema kiest het systeem een periode van één uur tussen 11:00 en 7:00 uur in de regiotijd van uw server.

In zeldzame gevallen kan een onderhoudsgebeurtenis worden geannuleerd door het systeem of kan het niet voltooien. Als een onderhoudsgebeurtenis mislukt, wordt de update teruggezet en wordt de vorige versie van de binaire bestanden hersteld. In scenario's met mislukte updates is het mogelijk dat de server tijdens het onderhoudsvenster opnieuw wordt opgestart.

Als een onderhoudsgebeurtenis wordt geannuleerd of mislukt, stuurt het systeem u een melding. De volgende poging om onderhoud uit te voeren, wordt gepland volgens uw huidige instellingen. U ontvangt een melding over de volgende poging vijf dagen van tevoren.

Onderhoudsstatus

Voor afzonderlijke servers kunt u de onderhoudsstatus bekijken in de azure MySQL-onderhoudsblade in Azure Portal. De onderhoudsstatus geeft aan of onderhoud wordt gepland, uitgevoerd, voltooid of geannuleerd.

Voor klanten die meerdere flexibele Servers van Azure Database for MySQL beheren, kunt u Azure Resource Graph gebruiken om bulkquery's uit te voeren voor abonnementen en resourcegroepen. Dit is vooral handig voor het controleren van de onderhoudsgeschiedenis, het identificeren van betrokken resources en het bijhouden van onderhoudsgebeurtenissen in de loop van de tijd. Hieronder ziet u de Kusto-query waarmee de onderhoudsstatus, begin- en eindtijden en tracerings-id voor alle flexibele MySQL-servers onder het abonnement van de klant worden opgehaald. Hierdoor kunnen klanten de afgelopen drie maanden onderhoudsactiviteiten bewaken op een schaalbare en geautomatiseerde manier:

ServiceHealthResources
| where type == "microsoft.resourcehealth/events/impactedresources"
| extend TrackingId = split(split(id, "/events/", 1)[0], "/impactedResources", 0)[0]
| extend p = parse_json(properties)
| project subscriptionId, TrackingId, resourceName= p.resourceName, resourceGroup=p.resourceGroup, resourceType=p.targetResourceType, status= p.status, maintenanceStartTime=todatetime(p.maintenanceStartTime),  maintenanceEndTime=todatetime( p.maintenanceEndTime), details = p, id
| where resourceType == "Microsoft.DBforMySQL/flexibleServers" 
| order by maintenanceEndTime

U kunt ook naar het tabblad Beïnvloede resources van Azure Service Health gaan om de onderhoudsstatus voor al uw Azure-resources weer te geven, inclusief flexibele Azure Database for MySQL-servers. Houd er rekening mee dat de onderhoudsstatus die wordt weergegeven in Azure Service Health de algehele status van de onderhoudsgebeurtenis op regioniveau vertegenwoordigt en mogelijk niet de status van afzonderlijke servers weergeeft.

Onderhoud van bijna nul downtime

De onderhoudsfunctie voor Azure Database for MySQL bijna nul downtime is een baanbrekende ontwikkeling voor servers met hoge beschikbaarheid. Deze functie is ontworpen om onderhoudstijd aanzienlijk te verminderen. Deze mogelijkheid is cruciaal voor bedrijven die hoge beschikbaarheid en minimale onderbreking van hun databasebewerkingen eisen.

Voorwaarden en beperkingen

Let op deze voorwaarden en beperkingen om de optimale prestaties te behalen die deze functie biedt:

• Duur van downtime: in de meeste gevallen varieert de downtime tijdens onderhoud van 10 tot 30 seconden.
• Primaire sleutels in alle tabellen: Ervoor zorgen dat elke tabel een primaire sleutel heeft, is essentieel. Een gebrek aan primaire sleutels kan de replicatievertraging aanzienlijk verhogen en de downtime beïnvloeden.
• Lage werkbelasting tijdens onderhoudstijden: onderhoudsperioden moeten samenvallen met tijden van lage werkbelasting op de server om downtime te minimaliseren. We raden u aan om het aangepaste onderhoudsvenster te gebruiken om onderhoud te plannen tijdens daluren.
• Downtime garanties: Hoewel we ernaar streven om de onderhoudsdowntime zo laag mogelijk te houden, garanderen we niet dat deze in alle omstandigheden minder dan 60 seconden zal zijn. Verschillende factoren, zoals een hoge workload of specifieke serverconfiguraties, kunnen de downtime verhogen. In het ergste geval kan downtime vergelijkbaar zijn met die van een zelfstandige server.

Onderhoud opnieuw plannen

Met de functie voor het opnieuw plannen van onderhoud hebt u meer controle over de timing van onderhoudsactiviteiten op uw flexibele Azure Database for MySQL-server. Nadat u een onderhoudsmelding hebt ontvangen, kunt u deze opnieuw plannen voor een geschikter tijdstip, ongeacht of het door het systeem wordt beheerd of op een aangepaste manier wordt beheerd.

Gebruik deze functie om onderbrekingen tijdens kritieke databasebewerkingen te voorkomen. We raden uw feedback aan naarmate we deze functionaliteit blijven ontwikkelen.

Parameters en meldingen opnieuw plannen

Herscheduling is niet beperkt tot vaste tijdsleuven. Het hangt af van de vroegste en meest recente toegestane tijden in de huidige onderhoudscyclus. De cyclus omvat doorgaans van de eerste dag tot de laatste dag van het onderhoudsvenster voor de regio. Wanneer u de wijzigingen opnieuw wilt plannen, krijgt u een melding om de wijzigingen te bevestigen, volgens het standaardmeldingsbeleid.

Overwegingen en beperkingen

Houd rekening met de volgende punten over de functie:

• Beschikbaarheid van de tier: Het opnieuw plannen van onderhoud is niet beschikbaar voor de Burstable compute tier. Deze functie is bedoeld voor servers in de productieomgeving, terwijl de Burstable-laag is ontworpen voor niet-productiedoeleinden.
• Vraagbeperkingen: uw geplande onderhoud kan worden geannuleerd als er tegelijkertijd een groot aantal onderhoudsactiviteiten in dezelfde regio plaatsvindt.
• Beperkingsperiode: Het is niet mogelijk om 15 minuten vóór de aanvankelijk geplande onderhoudstijd opnieuw te plannen, om de betrouwbaarheid van de dienst te behouden.
• Herschikkingsdrempel: Als er te veel servers in dezelfde regio voor onderhoud zijn ingepland tijdens dezelfde periode, kunnen herschikkingsverzoeken mislukken. Als deze fout optreedt, ontvangt u een foutmelding die u adviseert een alternatieve tijdsperiode te kiezen. Gepland onderhoud is waarschijnlijk niet geannuleerd.

Er is geen beperking voor het aantal keren dat een onderhoudsbeurt opnieuw kan worden gepland. Zolang een onderhoudsgebeurtenis de status In voorbereiding niet heeft ingevoerd, kunt u deze altijd opnieuw plannen.

Veelgestelde vragen

Waarom hebben sommige van mijn servers onderhoudsmeldingen ontvangen terwijl anderen dat niet hebben gedaan?

De begintijden van onderhoud verschillen tussen regio's. Servers in verschillende regio's kunnen op verschillende momenten onderhoudsmeldingen ontvangen.

Waarom hebben sommige servers in dezelfde regio onderhoudsmeldingen ontvangen, terwijl andere niet?

Het is mogelijk dat de servers die geen meldingen hebben ontvangen, onlangs zijn gemaakt en het systeem heeft vastgesteld dat ze nog geen onderhoud nodig hebben.

Kan ik me afmelden voor gepland onderhoud?

Nee, afmelden voor gepland onderhoud is niet toegestaan. U kunt echter de functie voor het opnieuw plannen van onderhoud gebruiken om de timing aan te passen. U kunt ook de functie voor hoge beschikbaarheid inschakelen om downtime te minimaliseren. Omdat Azure Database for MySQL een PaaS-databaseproduct (Platform as a Service) is, zorgt het tijdig onderhoud voor de beveiliging en betrouwbaarheid van uw database.

Gerelateerde inhoud

• Het onderhoudsschema wijzigen
• Meldingen ontvangen over gepland onderhoud
• Waarschuwingen instellen over gepland geplande onderhoudsevenementen