Serverparametrar i Azure Database for MySQL – flexibel server

  • Artikel

GÄLLER FÖR: Azure Database for MySQL – flexibel server

Den här artikeln innehåller överväganden och riktlinjer för att konfigurera serverparametrar i Azure Database for MySQL – flexibel server.

Kommentar

Den här artikeln innehåller referenser till termen slav, en term som Microsoft inte längre använder. När termen tas bort från programvaran tar vi bort den från den här artikeln.

Vad är servervariabler?

MySQL-motorn innehåller många olika servervariabler/parametrar som kan användas för att konfigurera och finjustera motorbeteendet. Vissa parametrar kan anges dynamiskt under körning medan andra är "statiska", vilket kräver en omstart av servern för att kunna tillämpas.

Azure Database for MySQL – flexibel server gör det möjligt att ändra värdet för olika MySQL-serverparametrar med hjälp av Azure-portalen och Azure CLI för att matcha dina arbetsbelastningsbehov.

Konfigurerbara serverparametrar

Du kan hantera flexibel serverkonfiguration i Azure Database for MySQL med hjälp av serverparametrar. Serverparametrarna konfigureras med standardvärdet och det rekommenderade värdet när du skapar servern. Bladet serverparameter i Azure-portalen visar både de modifierbara och icke-modifierbara serverparametrarna. De icke-modifierbara serverparametrarna är nedtonade.

Listan över serverparametrar som stöds växer ständigt. Använd fliken serverparametrar i Azure-portalen för att visa den fullständiga listan och konfigurera värden för serverparametrar.

Läs följande avsnitt om du vill veta mer om gränserna för de flera vanliga serverparametrarna. Gränserna bestäms av serverns beräkningsnivå och storlek (virtuella kärnor).

Kommentar

  • Om du ändrar en statisk serverparameter med hjälp av portalen måste du starta om servern för att ändringarna ska börja gälla. Om du använder automationsskript (med verktyg som ARM-mallar, Terraform, Azure CLI osv.) bör skriptet ha en etablering för att starta om tjänsten så att inställningarna börjar gälla även om du ändrar konfigurationerna som en del av skapa-upplevelsen.
  • Om du vill ändra en icke-ändringsbar serverparameter för din miljö öppnar du ett UserVoice-objekt eller röstar om feedbacken redan finns som kan hjälpa oss att prioritera.

lower_case_table_names

För MySQL version 5.7 är standardvärdet 1 i Azure Database for MySQL – flexibel server. Observera att även om det är möjligt att ändra värdet som stöds till 2, är det inte tillåtet att återgå från 2 tillbaka till 1. Kontakta vårt supportteam om du vill ha hjälp med att ändra standardvärdet. För MySQL version 8.0+ kan lower_case_table_names bara konfigureras när servern initieras. Läs mer. Det är förbjudet att ändra inställningen lower_case_table_names när servern har initierats. För MySQL version 8.0 är standardvärdet 1 i Azure Database for MySQL – flexibel server. Värdet som stöds för MySQL version 8.0 är 1 och 2 i Azure Database for MySQL – flexibel server. Kontakta vårt supportteam om du vill ha hjälp med att ändra standardvärdet när servern skapas.

innodb_tmpdir

Parametern innodb_tmpdir i Azure Database for MySQL – flexibel server används för att definiera katalogen för temporära sorteringsfiler som skapas under alter table-onlineåtgärder som återskapas. Standardvärdet för innodb_tmpdir är /mnt/temp. Den här platsen motsvarar den tillfälliga lagrings-SSD som är tillgänglig i GiB med varje serverberäkningsstorlek. Den här platsen är perfekt för åtgärder som inte kräver mycket utrymme. Om du behöver mer utrymme kan du ange innodb_tmpdir till /app/work/tmpdir. Detta använder din lagring, kapacitet som är tillgänglig på din Azure Database for MySQL – flexibel server. Detta kan vara användbart för större åtgärder som kräver mer tillfällig lagring. Det är viktigt att observera att användning /app/work/tmpdir resulterar i långsammare prestanda jämfört med standard temp storage (SSD)/mnt/temp. Valet bör göras baserat på de specifika kraven för åtgärderna.

Informationen som tillhandahålls för är tillämplig på parametrarna innodb_temp_tablespaces_dir, tmpdir och slave_load_tmpdir där standardvärdet /mnt/temp är vanligt, och den alternativa katalogen /app/work/tmpdir är tillgänglig för att konfigurera ökad tillfällig lagring, med en kompromiss i prestanda baserat på specifika driftskrav. innodb_tmpdir

log_bin_trust_function_creators

I Azure Database for MySQL – flexibel server är binära loggar alltid aktiverade (det vill s.v.s log_bin . är inställt på PÅ). log_bin_trust_function_creators är inställt på PÅ som standard på flexibla servrar.

Det binära loggningsformatet är alltid ROW och alla anslutningar till servern använder ALLTID radbaserad binär loggning. Med radbaserad binär loggning finns inte säkerhetsproblem och binär loggning kan inte brytas, så du kan på ett säkert sätt tillåta log_bin_trust_function_creators att den förblir PÅ.

Om [log_bin_trust_function_creators] är inställt på AV kan det hända att du får fel som liknar att du inte har superprivilegier och binär loggning är aktiverat (du kanske vill använda den mindre säkra log_bin_trust_function_creators variabeln) om du försöker skapa utlösare.

innodb_buffer_pool_size

Läs dokumentationen för MySQL om du vill veta mer om den här parametern.

Prisnivå virtuella kärnor Minnesstorlek (GiB) Standardvärde (byte) Minsta värde (byte) Maxvärde (byte)
Burstbar (B1s) 1 1 134217728 33554432 134217728
Burstbar (B1ms) 1 2 536870912 134217728 536870912
Burstbar 2 4 2147483648 134217728 2147483648
Generell användning 2 8 5368709120 134217728 5368709120
Generell användning 4 16 12884901888 134217728 12884901888
Generell användning 8 32 25769803776 134217728 25769803776
Generell användning 16 64 51539607552 134217728 51539607552
Generell användning 32 128 103079215104 134217728 103079215104
Generell användning 48 192 154618822656 134217728 154618822656
Generell användning 64 256 206158430208 134217728 206158430208
Affärskritisk 2 16 12884901888 134217728 12884901888
Affärskritisk 4 32 25769803776 134217728 25769803776
Affärskritisk 8 64 51539607552 134217728 51539607552
Affärskritisk 16 128 103079215104 134217728 103079215104
Affärskritisk 32 256 206158430208 134217728 206158430208
Affärskritisk 48 384 309237645312 134217728 309237645312
Affärskritisk 64 504 405874409472 134217728 405874409472

innodb_file_per_table

MySQL lagrar InnoDB-tabellen i olika tabellområden baserat på den konfiguration som du angav när tabellen skapades. Systemtabellområdet är lagringsområdet för InnoDB-dataordlistan. En tabellyta för fil per tabell innehåller data och index för en enda InnoDB-tabell och lagras i filsystemet i sin egen datafil. Det här beteendet styrs av innodb_file_per_table serverparametern. Inställningen innodb_file_per_table gör att OFF InnoDB skapar tabeller i systemtabellområdet. Annars skapar InnoDB tabeller i tabellutrymmen för fil per tabell.

Azure Database for MySQL – flexibel server har stöd för största, 4 TB, i en enda datafil. Om databasen är större än 4 TB bör du skapa tabellen i innodb_file_per_table-tabellutrymmet. Om du har en enda tabell som är större än 4 TB bör du använda partitionstabellen.

innodb_log_file_size

innodb_log_file_size är storleken i byte för varje loggfil i en logggrupp. Loggfilernas sammanlagda storlek (innodb_log_file_size * innodb_log_files_in_group) får inte överskrida ett maximalt värde som är något mindre än 512 GB). En större loggfilstorlek är bättre för prestanda, men det har en nackdel att återställningstiden efter en krasch är hög. Du måste balansera återställningstiden i den sällsynta händelsen av en kraschåterställning jämfört med att maximera dataflödet under hög belastning. Dessa kan också resultera i längre omstartstider. Du kan konfigurera innodb_log_size till något av dessa värden – 256 MB, 512 MB, 1 GB eller 2 GB för Azure Database for MySQL – flexibel server. Parametern är statisk och kräver en omstart.

Kommentar

Om du har ändrat parametern innodb_log_file_size från standard kontrollerar du om värdet "visa global status som "innodb_buffer_pool_pages_dirty" ligger kvar på 0 i 30 sekunder för att undvika omstartsfördröjning.

max_connections

Värdet för max_connection bestäms av serverns minnesstorlek.

Prisnivå virtuella kärnor Minnesstorlek (GiB) Standardvärde Minsta värde Maxvärde
Burstbar (B1s) 1 1 85 10 171
Burstbar (B1ms) 1 2 171 10 341
Burstbar 2 4 341 10 683
Generell användning 2 8 683 10 1365
Generell användning 4 16 1365 10 2731
Generell användning 8 32 2731 10 5461
Generell användning 16 64 5461 10 10923
Generell användning 32 128 10923 10 21845
Generell användning 48 192 16384 10 32768
Generell användning 64 256 21845 10 43691
Affärskritisk 2 16 1365 10 2731
Affärskritisk 4 32 2731 10 5461
Affärskritisk 8 64 5461 10 10923
Affärskritisk 16 128 10923 10 21845
Affärskritisk 32 256 21845 10 43691
Affärskritisk 48 384 32768 10 65536
Affärskritisk 64 504 43008 10 86016

När anslutningarna överskrider gränsen kan du få följande fel:

FEL 1040 (08004): För många anslutningar

Viktigt!

För bästa möjliga upplevelse rekommenderar vi att du använder en anslutningspool som ProxySQL för att effektivt hantera anslutningar.

Det tar tid att skapa nya klientanslutningar till MySQL och när de har upprättats upptar dessa anslutningar databasresurser, även när de är inaktiva. De flesta program begär många kortvariga anslutningar, vilket förvärrar den här situationen. Resultatet är färre resurser som är tillgängliga för din faktiska arbetsbelastning, vilket leder till sämre prestanda. En anslutningspool som minskar inaktiva anslutningar och återanvänder befintliga anslutningar hjälper till att undvika detta. Mer information om hur du konfigurerar ProxySQL finns i vårt blogginlägg.

Kommentar

ProxySQL är ett öppen källkod community-verktyg. Det stöds av Microsoft på bästa sätt. För att få produktionsstöd med auktoritativ vägledning kan du utvärdera och kontakta Support för ProxySQL-produkt.

innodb_strict_mode

Om du får ett felmeddelande som liknar "Radstorleken är för stor (> 8126)" kanske du vill inaktivera parametern innodb_strict_mode. Serverparametern innodb_strict_mode kan inte ändras globalt på servernivå eftersom om raddatastorleken är större än 8k trunkeras data utan fel, vilket kan leda till potentiell dataförlust. Vi rekommenderar att du ändrar schemat så att det passar sidstorleksgränsen.

Den här parametern kan anges på sessionsnivå med hjälp av init_connect. Om du vill ange innodb_strict_mode på sessionsnivå läser du inställningsparametern som inte visas.

Kommentar

Om du har en skrivskyddad replikserver bryts replikeringen genom att ställa in innodb_strict_mode på AV på sessionsnivå på en källserver. Vi rekommenderar att du behåller parametern inställd på PÅ om du har läsrepliker.

time_zone

Vid den första distributionen innehåller en flexibel Azure Database for MySQL-serverinstans systemtabeller för tidszonsinformation, men dessa tabeller fylls inte i. Tidszonstabellerna kan fyllas i genom att anropa den mysql.az_load_timezone lagrade proceduren från ett verktyg som MySQL-kommandoraden eller MySQL Workbench. I artiklarna i Azure-portalen eller Azure CLI finns information om hur du anropar den lagrade proceduren och anger tidszoner på global nivå eller sessionsnivå.

binlog_expire_logs_seconds

I Azure Database for MySQL – flexibel server anger den här parametern hur många sekunder tjänsten väntar innan den binära loggfilen rensas.

Den binära loggen innehåller "händelser" som beskriver databasändringar, till exempel åtgärder för att skapa tabeller eller ändringar i tabelldata. Den innehåller också händelser för instruktioner som potentiellt kan ha gjort ändringar. Den binära loggen används främst för två syften, replikering och dataåterställningsåtgärder. Vanligtvis rensas de binära loggarna så snart referensen är fri från tjänsten, säkerhetskopieringen eller replikuppsättningen. Om det finns flera repliker väntar de binära loggarna på att den långsammaste repliken ska läsa ändringarna innan de rensas. Om du vill spara binära loggar under en längre tid kan du konfigurera parametern binlog_expire_logs_seconds. Om binlog_expire_logs_seconds är inställt på 0, vilket är standardvärdet, rensas handtaget till den binära loggen. Om binlog_expire_logs_seconds > 0 väntar den tills sekunderna har konfigurerats innan den rensas. För flexibel Azure Database for MySQL-server hanteras hanterade funktioner som säkerhetskopiering och läsreplikrensning av binära filer internt. När du replikerar datautdata från en flexibel Azure Database for MySQL-server måste den här parametern anges i primärt för att undvika rensning av binära loggar innan repliken läser från ändringarna från den primära. Om du anger binlog_expire_logs_seconds till ett högre värde rensas inte de binära loggarna tillräckligt snart och kan leda till ökad lagringsfakturering.

event_scheduler

I Azure Database for MySQL – flexibel server event_schedule hanterar serverparametern att skapa, schemalägga och köra händelser, dvs. uppgifter som körs enligt ett schema, och de körs av en särskild händelseschematråd. När parametern event_scheduler är inställd på PÅ visas tråden för händelseschemaläggaren som en daemonprocess i utdata från SHOW PROCESSLIST. Du kan skapa och schemalägga händelser med följande SQL-syntax:

CREATE EVENT <event name>
ON SCHEDULE EVERY _ MINUTE / HOUR / DAY
STARTS TIMESTAMP / CURRENT_TIMESTAMP
ENDS TIMESTAMP / CURRENT_TIMESTAMP + INTERVAL 1 MINUTE / HOUR / DAY
COMMENT ‘<comment>’
DO
<your statement>;

Kommentar

Mer information om hur du skapar en händelse finns i dokumentationen för MySQL Event Scheduler här:

Konfigurera event_scheduler-serverparametern

Följande scenario illustrerar ett sätt att använda parametern event_scheduler i Azure Database for MySQL – flexibel server. För att demonstrera scenariot bör du överväga följande exempel, en enkel tabell:

mysql> describe tab1;
+-----------+-------------+------+-----+---------+----------------+
| Field     | Type        | Null | Key | Default | Extra          |
+-----------+-------------+------+-----+---------+----------------+
| id        | int(11)     | NO   | PRI | NULL    | auto_increment |
| CreatedAt | timestamp   | YES  |     | NULL    |                |
| CreatedBy | varchar(16) | YES  |     | NULL    |                |
+-----------+-------------+------+-----+---------+----------------+
3 rows in set (0.23 sec)

Utför följande steg för att konfigurera event_scheduler serverparametern i Azure Database for MySQL – flexibel server:

  1. I Azure-portalen går du till din flexibla Serverinstans för Azure Database for MySQL och väljer sedan Serverparametrar under Inställningar.

  2. På bladet Serverparametrar söker event_schedulerdu efter i listrutan VÄRDE, väljer PÅ och väljer sedan Spara.

    Kommentar

    Konfigurationsändringen av den dynamiska serverparametern distribueras utan omstart.

  3. Skapa sedan en händelse genom att ansluta till den flexibla serverinstansen Azure Database for MySQL och köra följande SQL-kommando:

    CREATE EVENT test_event_01
ON SCHEDULE EVERY 1 MINUTE
STARTS CURRENT_TIMESTAMP
ENDS CURRENT_TIMESTAMP + INTERVAL 1 HOUR
COMMENT ‘Inserting record into the table tab1 with current timestamp’
DO
INSERT INTO tab1(id,createdAt,createdBy)
VALUES('',NOW(),CURRENT_USER());

  4. Om du vill visa information om event scheduler kör du följande SQL-instruktion:

    SHOW EVENTS;

    Följande utdata visas:

    mysql> show events;
+-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
| Db  | Name          | Definer     | Time zone | Type      | Execute at | Interval value | Interval field | Starts              | Ends                | Status  | Originator | character_set_client | collation_connection | Database Collation |
+-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
| db1 | test_event_01 | azureuser@% | SYSTEM    | RECURRING | NULL       | 1              | MINUTE         | 2023-04-05 14:47:04 | 2023-04-05 15:47:04 | ENABLED | 3221153808 | latin1               | latin1_swedish_ci    | latin1_swedish_ci  |
+-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
1 row in set (0.23 sec)

  5. Efter några minuter frågar du raderna från tabellen för att börja visa raderna som infogas varje minut enligt parametern event_scheduler som du konfigurerade:

    mysql> select * from tab1;
+----+---------------------+-------------+
| id | CreatedAt           | CreatedBy   |
+----+---------------------+-------------+
|  1 | 2023-04-05 14:47:04 | azureuser@% |
|  2 | 2023-04-05 14:48:04 | azureuser@% |
|  3 | 2023-04-05 14:49:04 | azureuser@% |
|  4 | 2023-04-05 14:50:04 | azureuser@% |
+----+---------------------+-------------+
4 rows in set (0.23 sec)

  6. Efter en timme kör du en Select-instruktion i tabellen för att visa det fullständiga resultatet av de värden som infogas i tabellen varje minut i en timme som event_scheduler är konfigurerat i vårt fall.

    mysql> select * from tab1;
+----+---------------------+-------------+
| id | CreatedAt           | CreatedBy   |
+----+---------------------+-------------+
|  1 | 2023-04-05 14:47:04 | azureuser@% |
|  2 | 2023-04-05 14:48:04 | azureuser@% |
|  3 | 2023-04-05 14:49:04 | azureuser@% |
|  4 | 2023-04-05 14:50:04 | azureuser@% |
|  5 | 2023-04-05 14:51:04 | azureuser@% |
|  6 | 2023-04-05 14:52:04 | azureuser@% |
..< 50 lines trimmed to compact output >..
| 56 | 2023-04-05 15:42:04 | azureuser@% |
| 57 | 2023-04-05 15:43:04 | azureuser@% |
| 58 | 2023-04-05 15:44:04 | azureuser@% |
| 59 | 2023-04-05 15:45:04 | azureuser@% |
| 60 | 2023-04-05 15:46:04 | azureuser@% |
| 61 | 2023-04-05 15:47:04 | azureuser@% |
+----+---------------------+-------------+
61 rows in set (0.23 sec)

Andra scenarier

Du kan konfigurera en händelse baserat på kraven i ditt specifika scenario. Några liknande exempel på schemaläggning av SQL-instruktioner som ska köras med olika tidsintervall följer.

Kör en SQL-instruktion nu och upprepa en gång per dag utan slut

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS (TIMESTAMP(CURRENT_DATE) + INTERVAL 1 DAY + INTERVAL 1 HOUR)
COMMENT 'Comment'
DO
<your statement>;

Köra en SQL-instruktion varje timme utan slut

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;

Kör en SQL-instruktion varje dag utan slut

CREATE EVENT <event name>
ON SCHEDULE 
EVERY 1 DAY
STARTS str_to_date( date_format(now(), '%Y%m%d 0200'), '%Y%m%d %H%i' ) + INTERVAL 1 DAY
COMMENT 'Comment'
DO
<your statement>;

Begränsningar

För servrar med hög tillgänglighet konfigurerad är det möjligt att event_scheduler serverparametern är inställd på "OFF" när redundansväxlingen sker. Om detta inträffar, när redundansväxlingen är klar, konfigurerar du parametern för att ange värdet till "ON".

Icke-modifierbara serverparametrar

Bladet serverparameter på Azure-portalen visar både de modifierbara och icke-modifierbara serverparametrarna. De icke-modifierbara serverparametrarna är nedtonade. Om du vill konfigurera en icke-modifierad serverparameter på sessionsnivå kan du läsa artikeln i Azure-portalen eller Azure CLI för att ange parametern på anslutningsnivå med hjälp av init_connect.

Nästa steg