Not
Åtkomst till denna sida kräver auktorisation. Du kan prova att logga in eller byta katalog.
Åtkomst till denna sida kräver auktorisation. Du kan prova att byta katalog.
Hantering efter migreringen är avgörande för att flytta MySQL-databaser från lokala miljöer till Azure Database for MySQL. Den här artikeln går in på viktiga uppgifter och metodtips för att hantera dina databaser efter migreringen. Du kan se till att dina databaser fungerar effektivt och säkert i Azure-miljön genom att fokusera på övervakning, prestandajustering, säkerhet och underhåll. Den här guiden innehåller insikter och strategier som behövs för att hantera dina migrerade databaser effektivt, hantera potentiella utmaningar och använda Azures avancerade funktioner för att optimera prestanda och tillförlitlighet. Oavsett om du vill förbättra databasens prestanda, säkerställa datasäkerhet eller effektivisera underhållsaktiviteter, ger den här artikeln dig kunskap för att uppnå en lyckad hantering efter migreringen.
Förutsättningar
Migrera MySQL lokalt till Azure Database for MySQL: Datamigrering med MySQL Workbench
Övervaka och aviseringar
När migreringen har slutförts kommer nästa fas att hantera de nya molnbaserade dataarbetsbelastningsresurserna. Hanteringsåtgärder omfattar både kontrollplans- och dataplansaktiviteter. Kontrollplansaktiviteter är de som är relaterade till Azure-resurserna jämfört med dataplanet, som finns i Azure-resursen (i det här fallet MySQL).
Med Azure Database for MySQL kan du övervaka båda dessa typer av operativa aktiviteter med hjälp av Azure-baserade verktyg som Azure Monitor, Log Analytics och Microsoft Sentinel. Förutom de Azure-baserade verktygen kan siem-system (säkerhetsinformation och händelsehantering) konfigureras för att även använda dessa loggar.
Oavsett vilket verktyg som används för att övervaka de nya molnbaserade arbetsbelastningarna måste aviseringar skapas för att varna Azure- och databasadministratörer om misstänkt aktivitet. Om en viss aviseringshändelse har en väldefinierad reparationssökväg kan aviseringar utlösa automatiserade Azure-körningsböcker för att åtgärda händelsen.
Det första steget för att skapa en fullständigt övervakad miljö är att göra det möjligt för MySQL-loggdata att flöda till Azure Monitor. Mer information finns i Konfigurera och komma åt granskningsloggar för Azure Database for MySQL i Azure Portal.
När loggdata flödar använder du frågespråket Kusto-frågespråk (KQL) för att köra frågor mot den olika logginformationen. Administratörer som inte är bekanta med KQL kan hitta ett sql-till-KQL-fuskblad här eller Kom igång med loggfrågor på Azure Monitor-sidan.
Om du till exempel vill hämta minnesanvändningen för Azure Database for MySQL:
AzureMetrics
| where TimeGenerated \> ago(15m)
| limit 10
| where ResourceProvider == "MICROSOFT.DBFORMYSQL"
| where MetricName == "memory\_percent"
| project TimeGenerated, Total, Maximum, Minimum, TimeGrain, UnitName
| top 1 by TimeGenerated
Så här hämtar du CPU-användningen:
AzureMetrics
| where TimeGenerated \> ago(15m)
| limit 10
| where ResourceProvider == "MICROSOFT.DBFORMYSQL"
| where MetricName == "cpu\_percent"
| project TimeGenerated, Total, Maximum, Minimum, TimeGrain, UnitName
| top 1 by TimeGenerated
När du har skapat KQL-frågan skapar du sedan loggaviseringar baserade på dessa frågor.
Serverparametrar
Som en del av migreringen är det troligt att de lokala serverparametrarna har ändrats för att stödja en snabb utgående trafik. Dessutom gjordes ändringar i Azure Database for MySQL-parametrarna för att stödja en snabb ingress. Azure-serverparametrarna ska ställas in på sina ursprungliga lokala arbetsbelastningsoptimerade värden efter migreringen.
Se dock till att granska och göra ändringar av serverparametrar som är lämpliga för arbetsbelastningen och miljön. Vissa värden som var bra för en lokal miljö kanske inte är optimala för en molnbaserad miljö. När du planerar att migrera de aktuella lokala parametrarna till Azure kontrollerar du dessutom att de faktiskt kan anges.
Vissa parametrar kan inte ändras i Azure Database for MySQL.
PowerShell-modul
Azure Portal och Windows PowerShell kan användas för att hantera Azure Database for MySQL. Kom igång med PowerShell genom att installera Azure PowerShell-cmdletarna för MySQL med följande PowerShell-kommando:
Install-Module -Name Az.MySql
När modulerna har installerats refererar du till självstudier som följande för att lära dig hur du kan använda skript för dina hanteringsaktiviteter:
Självstudie: Utforma en Azure Database for MySQL med hjälp av PowerShell
Säkerhetskopiera och återställa en Azure Database for MySQL-server med hjälp av PowerShell
Konfigurera serverparametrar i Azure Database for MySQL med hjälp av PowerShell
Utöka lagringsutrymmet automatiskt i Azure Database for MySQL-servern med hjälp av PowerShell
Så här skapar och hanterar du läsrepliker i Azure Database for MySQL med hjälp av PowerShell
Uppgraderingsprocess för Azure Database for MySQL
Eftersom Azure Database for MySQL är ett PaaS-erbjudande ansvarar administratörerna inte för hanteringen av uppdateringarna i operativsystemet eller MySQL-programvaran. Det är dock viktigt att vara medveten om att uppgraderingsprocessen kan vara slumpmässig och när den distribueras kan den stoppa MySQL-serverarbetsbelastningarna. Planera för dessa driftstopp genom att omdirigera arbetsbelastningarna till en läsreplik i händelse av att den specifika instansen hamnar i underhållsläge.
Kommentar
Den här typen av redundansarkitektur kan kräva ändringar i programdatalagret för att stödja den här typen av redundansscenario. Om läsrepliken underhålls som en läsreplik och inte befordras kan programmet bara läsa data och det kan misslyckas när någon åtgärd försöker skriva information till databasen.
Aviseringsfunktionen Planerat underhåll informerar resursägare upp till 72 timmar före installationen av en uppdatering eller kritisk säkerhetskorrigering. Databasadministratörer kan behöva meddela programanvändare om planerat och oplanerat underhåll.
Kommentar
Azure Database for MySQL-underhållsmeddelanden är otroligt viktiga. Databasunderhållet kan ta ner databasen och anslutna program under en viss tidsperiod.
WWI-scenario
WWI bestämde sig för att använda Azure-aktivitetsloggarna och aktivera MySQL-loggning för att flöda till en Log Analytics-arbetsyta. Den här arbetsytan är konfigurerad för att vara en del av Microsoft Sentinel så att alla hotanalyshändelser visas och incidenter skapas.
MySQL DBAs installerade Azure Database for MySQL Azure PowerShell-cmdletar för att göra hanteringen av MySQL-servern automatiserad jämfört med att behöva logga in på Azure Portal varje gång.
Checklista för hantering
Skapa resursaviseringar för vanliga saker som CPU och minne.
Kontrollera att serverparametrarna har konfigurerats för måldataarbetsbelastningen efter migreringen.
Vanliga administrativa uppgifter för skript.
Konfigurera meddelanden för underhållshändelser som uppgraderingar och korrigeringar. Meddela användarna efter behov.