Dela via

Migrera MySQL lokalt till Azure Database for MySQL: Prestandabaslinjer

  • Artikel

Det är viktigt att upprätta prestandabaslinjer för att migrera MySQL-databaser från lokala miljöer till Azure Database for MySQL. Den här artikeln beskriver vikten av prestandabaslinjer och ger en detaljerad guide om hur du mäter och analyserar dina aktuella databasprestanda. Genom att förstå dina befintliga prestandamått kan du ange realistiska förväntningar och identifiera förbättringsområden under migreringsprocessen. Den här guiden ger dig kunskap om att skapa korrekta prestandabaslinjer, vilket säkerställer att dina migrerade databaser uppfyller eller överskrider sina aktuella prestandanivåer i Azure-miljön. Oavsett om du vill optimera frågeprestanda, förbättra skalbarheten eller säkerställa konsekvent användarupplevelse ger den här artikeln de insikter som behövs för att uppnå dina prestandamål.

Förutsättningar

Migrera MySQL lokalt till Azure Database for MySQL: Testplaner

Översikt

Att förstå den befintliga MySQL-arbetsbelastningen är en av de bästa investeringarna som kan göras för att säkerställa en lyckad migrering. Utmärkta systemprestanda beror på lämplig maskinvara och bra programdesign. Objekt som CPU, minne, disk och nätverk måste vara storleksanpassade och konfigurerade på lämpligt sätt för den förväntade belastningen. Maskinvara och konfiguration är en del av systemets prestandaekvation. Utvecklaren måste förstå databasfrågebelastningen och de dyraste frågorna som ska köras. Att fokusera på de dyraste frågorna kan avsevärt påverka de övergripande prestandamåtten.

Att skapa frågeprestandabaslinjer är viktigt för ett migreringsprojekt. Prestandabaslinjerna kan användas för att verifiera konfigurationen av Azure-landningszonen för de migrerade dataarbetsbelastningarna. De flesta system körs dygnet om och har olika belastningstider. Det är viktigt att samla in de högsta arbetsbelastningarna för baslinjen. Mått samlas in flera gånger. Senare i dokumentet utforskar vi källserverparametrarna och hur de är viktiga för den övergripande prestandabaslinjebilden. Serverparametrarna bör inte förbises under ett migreringsprojekt.

Verktyg

Nedan visas verktyg som används för att samla in servermått och information om databasarbetsbelastningar. Använd de insamlade måtten för att fastställa lämplig Azure Database för MySQL-nivån och de associerade skalningsalternativen.

  • MySQL Enterprise-telemetri: Det här icke-kostnadsfria enterprise edition-verktyget kan ge en sorterad lista över de dyraste frågorna, servermåtten, fil-I/O och topologiinformation

  • Percona Monitoring and Management (PMM) : en förstklassig databasövervakningslösning med öppen källkod. Det hjälper till att minska komplexiteten, optimera prestanda och förbättra säkerheten i affärskritiska databasmiljöer, oavsett den distribuerade platsen.

Serverparametrar

MySQL-serverns standardkonfigurationer kanske inte har tillräckligt stöd för en arbetsbelastning. Det finns en mängd serverparametrar i MySQL, men i de flesta fall bör migreringsteamet fokusera på en handfull. Följande parametrar bör utvärderas i käll- och målmiljöerna. Felaktiga konfigurationer kan påverka migreringens hastighet. Vi går tillbaka till dessa parametrar igen när vi utför migreringsstegen.

  • innodb_buffer_pool_size: Ett stort värde säkerställer att minnesinterna resurser används först innan disk-I/O används. Typiska värden sträcker sig från 80 % till 90 % av det tillgängliga minnet. Ett system med 8 GB minne bör till exempel allokera 5–6 GB för poolstorleken.

  • innodb_log_file_size: Gör om loggarna säkerställer snabba, varaktiga skrivningar. Den här transaktionssäkerhetskopian är användbar under en systemkrasch. Från och med innodb_log_file_size = 512M (vilket ger 1 GB omloggar) bör ge gott om utrymme för skrivningar. Skrivintensiva program som använder MySQL 5.6 eller senare bör börja med innodb_log_file_size = 4G.

  • max_connections: Den här parametern kan hjälpa dig att lindra Too many connections felet. Standardvärdet är 151 anslutningar. Att använda en anslutningspool på programnivå är att föredra, men konfigurationen av serveranslutningen kan också behöva öka.

  • innodb_file_per_table: Den här inställningen anger för InnoDB om den ska lagra data och index i det delade tabellområdet eller en separat.ibd-fil för varje tabell. Med en fil per tabell kan servern frigöra utrymme när tabeller tas bort, trunkeras eller återskapas. Databaser som innehåller många tabeller bör inte använda tabellen per filkonfiguration. Från och med MySQL 5.6 är standardvärdet PÅ. Tidigare databasversioner bör ange konfigurationen till PÅ innan data läses in. Den här inställningen påverkar endast nyligen skapade tabeller.

  • innodb_flush_log_at_trx_commit: Standardinställningen för ett innebär att InnoDB är helt ACID-kompatibelt. Den här transaktionskonfigurationen med lägre risk kan ha betydande omkostnader på system med långsamma diskar på grund av de extra synkroniseringar som krävs för att tömma varje ändring i de omgjorda loggarna. Att ställa in parametern på 2 är lite mindre tillförlitligt eftersom de checkade transaktionerna endast rensas till de omgjorda loggarna en gång i sekunden. Risken kan vara acceptabel i vissa huvudsituationer och det är ett bra värde för en replik. Värdet 0 ger bättre systemprestanda, men databasservern är mer lik för att förlora vissa data vid ett fel. Den nedersta raden är att endast använda värdet 0 för en replik.

  • innodb_flush_method: Den här inställningen styr hur data och loggar töms till disk. Använd O_DIRECT när det finns en MASKINVARU-RAID-styrenhet med en batteriskyddad återskrivningscache. Använd fdatasync (standardvärde) för andra scenarier.

  • innodb_log_buffer_size: Den här inställningen är buffertstorleken för transaktioner som ännu inte har checkats in. Standardvärdet (1 MB) är acceptabelt. Transaktioner med stora blob-/textfält kan snabbt fylla bufferten och utlösa extra I/O-belastning. Titta på Innodb_log_waits statusvariabeln och öka innodb_log_buffer_sizeom den inte är 0 .

  • query_cache_size: Frågecachen är en välkänd flaskhals som kan ses under måttlig samtidighet. Det initiala värdet ska anges till 0 för att inaktivera cacheminnet, till exempel query_cache_size = 0. Detta är standardvärdet för MySQL 5.6 och senare.

  • log_bin: Den här inställningen aktiverar binär loggning. Aktivering av binär loggning är obligatoriskt om servern ska fungera som replikeringshanterare.

  • server_id: Den här inställningen är unik för identitetsservrar i replikeringstopologier.

  • expire_logs_days: Den här inställningen styr hur många dagar de binära loggarna ska rensas automatiskt.

  • skip_name_resolve: användare för att utföra klientvärdnamnsmatchning. Om DNS är långsam är anslutningen långsam. När du inaktiverar namnmatchning måste GRANT-uttrycken endast använda IP-adresser. Eventuella tidigare GRANT-instruktioner måste göras om för att använda IP-adressen.

Kör följande kommando för att exportera serverparametrarna till en fil för granskning. Med hjälp av en enkel parsning kan utdata tillämpa samma serverparametrar igen efter migreringen, om det är lämpligt, på Azure Database for MySQL-servern. Referens Konfigurera serverparametrar i Azure Database for MySQL med hjälp av Azure Portal.

mysql -u root -p -A -e "SHOW GLOBAL VARIABLES;" > settings.txt

MySQL 5.5.60 standard installerade serverparametrar finns i bilagan.

Innan migreringen påbörjas exporterar du mySQL-källkonfigurationsinställningarna. Jämför dessa värden med instansinställningarna för Azure-landningszonen efter migreringen. Om några inställningar har ändrats från standardinställningen i azure-målinstansen för landningszoner kontrollerar du att dessa har ställts in igen efter migreringen. Dessutom bör migreringsanvändaren kontrollera att serverparametrarna kan anges före migreringen.

En lista över serverparametrar som inte kan konfigureras finns i Icke konfigurerbara serverparametrar.

Utgående och inkommande

MySQL-serverparametrarna för källa och mål måste ändras för varje respektive datamigreringsverktyg och sökväg för att stödja snabbast möjliga utgående och inkommande. Beroende på verktyget kan parametrarna vara olika. Ett verktyg som utför en parallell migrering kan till exempel behöva fler anslutningar mellan källan och målet jämfört med ett enkeltrådat verktyg.

Granska eventuella timeout-parametrar som kan påverkas av datauppsättningarna. Dessa kan vara:

Granska dessutom eventuella parametrar som påverkar maxvärden:

Kommentar

Ett vanligt migreringsfel är MySQL server has gone away. Parametrarna som nämns här är de vanligaste syndarna för att lösa det här felet.

WWI-scenario

WWI granskade arbetsbelastningen för konferensdatabasen och fastställde att den hade en liten belastning. Även om en server på grundläggande nivå skulle fungera för dem, ville de inte utföra arbete senare för att migrera till en annan nivå. Servern som distribueras kommer så småningom att vara värd för de andra MySQL-dataarbetsbelastningarna, så de valde General Performance nivån.

När jag granskade MySQL-databasen upptäckte jag att MySQL 5.5-servern körs med standardserverparametrarna som angavs under den första installationen.

Gå vidare

Migrera MySQL lokalt till Azure Database for MySQL: Data Migration