Metodtips för optimala prestanda för Azure Database for MySQL – flexibel server
Lär dig hur du får bästa prestanda när du arbetar med Azure Database for MySQL – flexibel server. När vi lägger till nya funktioner i plattformen fortsätter vi att förfina våra rekommendationer i det här avsnittet.
Fysisk närhet
Se till att du distribuerar ett program och databasen i samma region. En snabbkontroll innan du påbörjar prestandamätningar är att fastställa nätverksfördröjningen mellan klienten och databasen med hjälp av en enkel SELECT 1-fråga.
När resurser som ett webbprogram och dess associerade databas körs i olika regioner kan det uppstå ökad svarstid i kommunikationen mellan dessa resurser. En annan möjlig bieffekt av att ha programmet och databasen i separata regioner gäller kostnader för utgående dataöverföring.
För att förbättra prestanda och tillförlitlighet för ett program i en kostnadsoptimerad distribution rekommenderar vi starkt att webbprogramtjänsten och Resursen Azure Database for MySQL – flexibel server finns i samma region och tillgänglighetszon. Den här samlokaliseringen passar bäst för program som är svarstidskänsliga och ger även det bästa dataflödet, eftersom resurserna är nära kopplade.
Accelererat nätverk
Använd accelererat nätverk för programservern om du använder en virtuell Azure-dator, Azure Kubernetes eller App Services. Accelererat nätverk möjliggör enkel rot-I/O-virtualisering (SR-IOV) till en virtuell dator, vilket avsevärt förbättrar nätverksprestandan. Den här högpresterande sökvägen kringgår värden från datasökvägen, vilket minskar svarstiden, jitter- och CPU-användningen, för användning med de mest krävande nätverksarbetsbelastningarna på virtuella datortyper som stöds.
Anslutningseffektivitet
Att upprätta en ny anslutning är alltid en dyr och tidskrävande uppgift. När ett program begär en databasanslutning prioriteras allokeringen av befintliga inaktiva databasanslutningar i stället för att skapa en ny. Här följer några alternativ för bra anslutningsmetoder:
ProxySQL: Använd ProxySQL, som tillhandahåller inbyggd anslutningspool och belastningsutjämning av din arbetsbelastning till flera läsrepliker efter behov med eventuella ändringar i programkoden.
Heimdall Data Proxy: Alternativt kan du också använda Heimdall Data Proxy, en leverantörsneutral proprietär proxylösning. Den stöder cachelagring av frågor och läsning/skrivning med replikeringsfördröjningsidentifiering. Du kan också se hur du påskyndar MySQL-prestanda med Heimdall-proxyn.
Beständiga eller långlivade anslutningar: Om programmet har korta transaktioner eller frågor vanligtvis med körningstid < 5–10 ms ersätter du korta anslutningar med beständiga anslutningar. Ersätt korta anslutningar med beständiga anslutningar kräver endast mindre ändringar i koden, men det har en stor effekt när det gäller att förbättra prestanda i många typiska programscenarier. Ange tidsgränsen eller stäng anslutningen när transaktionen är klar.
Replik: Om du använder replik använder du ProxySQL för att balansera belastningen mellan den primära servern och den läsbara sekundära replikservern. Lär dig hur du konfigurerar ProxySQL.
Anslutningspooler
Anslutningspooler är en mekanism som hanterar skapande och allokering av databasanslutningar och skyddar en databas mot anslutningstoppar. Överväg att använda anslutningspooler om programmet öppnar många anslutningar på relativt kort tid och anslutningarna är kortvariga. Dessa typer av anslutningar kan till exempel inträffa över en storlek på hundratals eller tusentals per sekund, och den tid det tar att upprätta och stänga dem är betydande jämfört med den totala anslutningslivslängden.
Om programmets utvecklingsramverk inte stöder anslutningspooler använder du i stället en anslutningsproxy, till exempel ProxySQL eller Heimdall-proxy, mellan programmet och databasservern.
Hantera anslutningsskalning
En vanlig metod för att skala webbprogram för att möta varierande efterfrågan är att lägga till och ta bort programservrar. Varje programserver kan använda en anslutningspool med databasen. Den här metoden gör att det totala antalet anslutningar på en databasserver ökar i förhållande till antalet programservrar. Om en databasserver till exempel har 10 programservrar och var och en har konfigurerats för 100 databasanslutningar skulle det ge 1 000 databasanslutningar. Om programmets arbetsbelastning skalas på grund av högre användaraktivitet eller under hög belastning och om ytterligare 50 programservrar läggs till, skulle databasanslutningarna uppgå till 6 000. Vanligtvis är de flesta av dessa anslutningar inaktiva när de har skapats av programservrarna. Eftersom inaktiva anslutningar förbrukar resurser (minne och PROCESSOR) för att förbli öppna kan databasens skalbarhet påverkas.
Ytterligare potentiella utmaningar är att hantera det totala antalet anslutningar till databasservern. Detta styrs av antalet programservrar som är anslutna till databasservern, var och en skapar en egen uppsättning anslutningar. I dessa scenarier bör du överväga att justera anslutningspoolerna på programservrarna. Försök att minska antalet anslutningar i varje pool till ett acceptabelt minimum för att säkerställa att anslutningarna inte är uppsvällda på databasserversidan. Betrakta detta som en kortsiktig åtgärd för att motverka effekterna av programserverskalning i stället för en permanent lösning för att hantera programmets tillväxt.
Som en långsiktig lösning introducerar du en anslutningsproxy, till exempel ProxySQL eller Heimdall proxy, mellan databasservern och programservern. Detta hjälper eftersom proxyn kommer att:
- Upprätta en anslutning till databasservern med ett fast antal anslutningar.
- Acceptera programanslutningar och fungera som en buffert för potentiella anslutningsstormar.
Proxyservrar kan tillhandahålla andra funktioner som cachelagring av frågor, anslutningsbuffertning, omskrivning/routning av frågor och belastningsutjämning. Överväg att använda flera proxyinstanser för att få ännu större skalbarhet.
Anslutningshantering för feltolerans och snabbare återställning
När du utformar dina program och din miljö för feltolerans och snabbare återställning bör du tänka på att det i en databasmiljö sannolikt uppstår anslutningsavbrott eller maskinvarufel. Kom också ihåg behovet av operativa åtgärder som att skala instansstorlekar, korrigera och utföra manuell redundans.
Tänk dig till exempel ett scenario där databasservern slutför redundans inom en minut, men programmet är nere i flera minuter längre på grund av att t.ex. DNS TTL är för långt på programsidan. I dessa fall ger en minskning av TTL-värdet snabbare återställning eller integrering av en anslutningsproxy mellan program- och databasservern för att hantera sådana fel.
Partition
När din produktionsarbetsbelastning använder extremt stora tabeller är partitionering en bra metod för att förbättra databasens prestanda och underlätta underhåll. Partitionering gör det enklare att hantera stora tabeller. Med den här metoden kan du lägga till och släppa partitioner för att hantera stora tabeller effektivt. Partitionering kan också hjälpa till att skala motorn genom att minska den interna strukturkonkurrationen, till exempel interna lås per tabell eller per index (t.ex. överväg btr_search_latch i InnoDB).
Genom att till exempel lägga till fem partitioner bryter du i princip en stor tabell med mycket aktivitet i fem mindre och effektivare tabeller. Detta skulle främst vara till hjälp för fall där huvudåtgärden är primära nyckelsökningar i tabellen, så att frågorna kan dra nytta av "partitionsrensning". Men partitionering kan också vara till hjälp när det gäller tabellgenomsökning.
Även om partitionering har sina fördelar har den också vissa begränsningar, till exempel bristen på stöd för sekundärnycklar i partitionerade tabeller, bristen på frågecache osv. En fullständig lista över dessa begränsningar finns i referenshandboken för MySQL i kapitlet Begränsningar och begränsningar för partitionering.
Separera läsningar och skrivningar
De flesta program läser främst från databasen, med endast en liten andel av interaktionerna som involverar skrivningar. Antalet aktiva anslutningar i den primära databasen som vi beräknade för anslutningspoolerna inkluderar sannolikt lästrafik. Om du avlastar så många frågor som möjligt för att läsa repliker och bevara åtkomsten till den primära skrivbara instansen ökar mängden övergripande databasaktivitet som utförs av programservrarna utan att öka belastningen på den primära databasen. Om du inte redan har åtkomst till läsrepliker åtminstone för frågor som körs längre, till exempel rapporter, bör du överväga att omedelbart flytta rapportering eller analys till läsrepliker.
Bredare skalningsanvändning av läsrepliker kan kräva mer noggrant övervägande, eftersom replikerna ligger något efter den primära på grund av replikeringens asynkrona karaktär. Hitta så många områden i programmet som möjligt som kan hanteras med läsningar från replikerna med mindre kodändringar. Du bör också använda den här metoden på högre nivåer när det gäller cachelagring – hantera mer av det skrivskyddade eller långsamt föränderliga innehållet från en dedikerad cachelagringsnivå, till exempel Azure Cache for Redis.
Skriva skalning och horisontell partitionering
Med tiden utvecklas program och nya funktioner läggs till. Av praktiska skäl eller allmän praxis läggs tabellerna till i den primära databasen. Om du vill hantera växande trafikbelastningar på en databas kan du identifiera områden i programmet som enkelt kan flyttas till separata databaser och överväga horisontell partitionering eller vertikal delning av databasen.
Horisontell partitionering av en databas fungerar genom att skapa flera kopior av programschemat i separata databaser och separera kunder och alla associerade data baserat på kund-ID, geografi eller något annat attribut per kund eller klientorganisation. Detta fungerar mycket bra för SaaS- eller B2C-program där enskilda kunder är små och belastningen på programmet beror på sammanlagd användning av miljontals kunder. Det är dock svårare med B2B-program där kunderna är olika storlekar och enskilda stora kunder kan dominera trafikbelastningen för en viss shard.
Lodrätt dela upp belastningen genom att funktionellt partitionera databasen – flytta separata programdomäner (eller mikrotjänster) till sina egna databaser. Detta distribuerar belastningen från den primära databasen för att separera databaser per tjänst. Enkla exempel är en loggningstabell eller platskonfigurationsinformation som inte behöver finnas i samma databas som tabellen med tungt inlästa beställningar. Mer komplicerade exempel är att bryta kund- och kontodomäner förutom order- eller uppfyllandedomäner. I vissa fall kan detta kräva programändringar, till exempel för att ändra e-post- eller bakgrundsjobbköer så att de är fristående och inte förlitar sig på kopplingar tillbaka till en kund eller ordertabell. Att flytta befintliga tabeller och data till en ny primär databas kan utföras med Azure Database for MySQL – flexibel server, läsrepliker och främja repliken och peka delar av programmet till den nyligen skapade skrivbara databasen. Den nyligen skapade databasen måste begränsa åtkomsten med anslutningspooler, finjustera frågor och sprida belastning med sina egna repliker precis som den ursprungliga primära.
Konfigurationer för dataimport
- Du kan tillfälligt skala instansen till en högre SKU-storlek innan du påbörjar en dataimportåtgärd och sedan skala ned den när importen lyckas.
- Du kan importera dina data med minimal stilleståndstid med hjälp av Migrera MySQL lokalt till Azure Database for MySQL för online- eller offlinemigreringar.
Minnesrekommendationer för Azure Database for MySQL – flexibel server
Bästa praxis för prestanda för Azure Database for MySQL – flexibel server är att allokera tillräckligt med RAM-minne så att arbetsuppsättningen finns nästan helt i minnet.
- Kontrollera om minnesprocenten som används för att nå gränserna med hjälp av måtten för Azure Database for MySQL – flexibel server.
- Konfigurera aviseringar för sådana nummer för att säkerställa att när servern når gränser kan du vidta åtgärder för att åtgärda det. Baserat på de definierade gränserna kontrollerar du om du skalar upp databasens SKU– antingen till högre beräkningsstorlek eller till en bättre prisnivå, vilket resulterar i en dramatisk ökning av prestanda.
- Skala upp tills prestandasiffrorna inte längre sjunker dramatiskt efter en skalningsåtgärd. Information om hur du övervakar en DB-instanss mått finns i Azure Database for MySQL – flexibel server DB-mått.
Använda Uppvärmd InnoDB-buffertpool
När Azure Database for MySQL–instansen för flexibel server har startats om läses de datasidor som finns i lagringen in när tabellerna efterfrågas, vilket leder till ökad svarstid och långsammare prestanda för den första körningen av frågorna. Detta kanske inte är acceptabelt för svarstidskänsliga arbetsbelastningar.
Om du använder innoDB-buffertpoolen förkortas uppvärmningsperioden genom att disksidor som fanns i buffertpoolen läses in igen före omstarten i stället för att vänta på att DML- eller SELECT-åtgärder ska komma åt motsvarande rader.
Du kan minska uppvärmningsperioden när du har startat om azure database for MySQL– flexibel serverinstans, vilket representerar en prestandafördel genom att konfigurera InnoDB-buffertpoolserverparametrar. InnoDB sparar en procentandel av de senast använda sidorna för varje buffertpool vid serveravstängning och återställer dessa sidor vid serverstart.
Det är också viktigt att observera att förbättrad prestanda sker på bekostnad av längre starttid för servern. När den här parametern är aktiverad förväntas serverns start- och omstartstid öka beroende på den IOPS som etablerats på servern.
Vi rekommenderar att du testar och övervakar omstartstiden för att säkerställa att start-/omstartsprestandan är acceptabel eftersom servern inte är tillgänglig under den tiden. Vi rekommenderar inte att du använder den här parametern med mindre än 1 000 etablerade IOPS (eller med andra ord när lagringen är mindre än 335 GB).
Om du vill spara tillståndet för buffertpoolen vid serveravstängning anger du serverparametern innodb_buffer_pool_dump_at_shutdown till ON. På samma sätt ställer du in serverparametern innodb_buffer_pool_load_at_startup på ON för att återställa buffertpoolens tillstånd vid serverstart. Du kan styra effekten på start-/omstartstiden genom att sänka och finjustera värdet för serverparametern innodb_buffer_pool_dump_pct. Som standard är den här parametern inställd på 25.
Kommentar
InnoDB-buffertpoolens uppvärmningsparametrar stöds endast i allmänna lagringsservrar med upp till 16 TB lagring. Mer information finns i Lagringsalternativ för Azure Database for MySQL – flexibel server.