Dela via

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 slave, 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 serverparametrar?

MySQL-motorn innehåller många serverparametrar (kallas även variabler) som du kan använda för att konfigurera och finjustera motorbeteende. Vissa parametrar kan anges dynamiskt under körning. Andra är statiska och kräver en omstart av servern när du har angett dem.

I Azure Database for MySQL – flexibel server kan du ändra värdet för olika MySQL-serverparametrar med hjälp av Azure Portal och Azure CLI för att matcha dina arbetsbelastningsbehov.

Konfigurerbara serverparametrar

Du kan hantera konfigurationen av en flexibel Azure Database for MySQL-server med hjälp av serverparametrar. Serverparametrarna konfigureras med standardvärdena och rekommenderade värden när du skapar servern. Fönstret Serverparametrar i Azure Portal visar både de modifierbara och icke-modifierbara parametrarna. De icke-modifierbara serverparametrarna är inte tillgängliga.

Listan över serverparametrar som stöds växer ständigt. Du kan använda Azure Portal för att regelbundet visa den fullständiga listan över serverparametrar och konfigurera värdena.

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 (via verktyg som Azure Resource Manager-mallar, Terraform eller Azure CLI) 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 konfigurationen som en del av skapandet.

Om du vill ändra en icke-modifierad serverparameter för din miljö kan du publicera en idé via communityns feedback eller rösta om feedbacken redan finns (vilket kan hjälpa oss att prioritera).

I följande avsnitt beskrivs gränserna för de vanliga serverparametrarna. Beräkningsnivån och storleken (virtuella kärnor) på servern avgör gränserna.

lower_case_table_names

För MySQL version 5.7 är 1 standardvärdet lower_case_table_names för i Azure Database for MySQL – flexibel server. Ä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 . Om du vill ha hjälp med att ändra standardvärdet skapar du en supportbegäran.

För MySQL version 8.0+ kan du bara konfigurera lower_case_table_names när du initierar servern. Läs mer. lower_case_table_names Det är förbjudet att ändra inställningen när servern har initierats.

Värden som stöds för MySQL version 8.0 är 1 och 2 i Azure Database for MySQL – flexibel server. Standardvärdet är 1. Om du vill ha hjälp med att ändra standardvärdet när servern skapas skapar du ett supportärende.

innodb_tmpdir

Du använder parametern innodb_tmpdir i Azure Database for MySQL – Flexibel server för att definiera katalogen för temporära sorteringsfiler som skapas under onlineåtgärder ALTER TABLE som återskapas.

Standardvärdet innodb_tmpdir för är /mnt/temp. Den här platsen motsvarar den tillfälliga lagringen (SSD) och är tillgänglig i gibibyte (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. Den här inställningen använder den tillgängliga lagringskapaciteten på din flexibla Azure Database for MySQL-server. Den här inställningen kan vara användbar för större åtgärder som kräver mer tillfällig lagring.

Tänk på att användningen resulterar /app/work/tmpdir i långsammare prestanda jämfört med standardvärdet för tillfällig lagring (SSD). /mnt/temp Gör valet baserat på de specifika kraven för åtgärderna.

Den information som tillhandahålls gäller för innodb_tmpdir parametrarna innodb_temp_tablespaces_dir, tmpdir och slave_load_tmpdir där:

  • Standardvärdet /mnt/temp är vanligt.
  • 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.

log_bin_trust_function_creators

I Azure Database for MySQL – flexibel server är binära loggar alltid aktiverade (det vill: log_bin är inställt på ON). Parametern log_bin_trust_function_creators är som standard inställd ON på flexibla servrar.

Det binära loggningsformatet är alltid ROW, och 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 kvar som ON.

Om log_bin_trust_function_creators är inställt på OFF och du försöker skapa utlösare kan du få fel som liknar: "Du har inte superprivilegier och binär loggning är aktiverad (du kanske vill använda den mindre säkra log_bin_trust_function_creators variabeln)."

innodb_buffer_pool_size

Mer information om parametern finns i innodb_buffer_pool_size MySQL-dokumentationen.

Den fysiska minnesstorleken i följande tabell representerar det tillgängliga ramminnet (random-access memory), i gigabyte (GB) på din flexibla Azure Database for MySQL-server.

Prisnivå Virtuella kärnor Storlek på fysiskt minne (GB) Standardvärde (byte) Minsta värde (byte) Maxvärde (byte)
Burstbar (B1s) 1 1 134217728 33554432 268435456
Burstbar (B1ms) 1 2 536870912 134217728 1073741824
Burstbar (B2s) 2 4 2147483648 134217728 2147483648
Burstbar (B2ms) 2 8 4294967296 134217728 5368709120
Burstbar 4 16 12884901888 134217728 12884901888
Burstbar 8 32 25769803776 134217728 25769803776
Burstbar 12 48 51539607552 134217728 51539607552
Burstbar 16 64 2147483648 134217728 2147483648
Burstbar 20 80 64424509440 134217728 64424509440
Generell användning 2 8 4294967296 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 20 160 128849018880 134217728 128849018880
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 den lagras i filsystemet i sin egen datafil. Parametern innodb_file_per_table server styr det här beteendet.

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 stöder högst 8 terabyte (TB) i en enda datafil. Om databasstorleken är större än 8 TB bör du skapa tabellen i innodb_file_per_table tabellområdet. Om du har en tabellstorlek som är större än 8 TB bör du använda partitionstabellen.

innodb_log_file_size

Värdet för 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 nackdelen är att återställningstiden efter en krasch är hög. Du måste balansera återställningstiden för den sällsynta händelsen av en krasch jämfört med att maximera dataflödet under hög belastning. En större loggfilstorlek kan också resultera i längre omstartstider.

Du kan konfigurera innodb_log_size till 256 MEGABYTE (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 standardvärdet kontrollerar du om värdet show global status like 'innodb_buffer_pool_pages_dirty' för stannar kvar i 0 30 sekunder för att undvika omstartsfördröjning.

max_connections

Serverns minnesstorlek avgör värdet max_connectionsför . Den fysiska minnesstorleken i följande tabell representerar det tillgängliga RAM-minnet i gigabyte på din flexibla Azure Database for MySQL-server.

Prisnivå Virtuella kärnor Storlek på fysiskt minne (GB) Standardvärde Minvärde Maxvärde
Burstbar (B1s) 1 1 85 10 171
Burstbar (B1ms) 1 2 171 10 341
Burstbar (B2s) 2 4 341 10 683
Burstbar (B2ms) 2 4 683 10 1365
Burstbar 4 16 1365 10 2731
Burstbar 8 32 2731 10 5461
Burstbar 12 48 4097 10 8193
Burstbar 16 64 5461 10 10923
Burstbar 20 80 6827 10 13653
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 20 160 13653 10 27306
Affärskritisk 32 256 21845 10 43691
Affärskritisk 48 384 32768 10 65536
Affärskritisk 64 504 43008 10 86016

När anslutningar överskrider gränsen kan du få följande fel: "FEL 1040 (08004): För många anslutningar."

Det tar tid att skapa nya klientanslutningar till MySQL. När du har upprättat dessa anslutningar upptar de 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 dig att undvika det här problemet. För bästa möjliga upplevelse rekommenderar vi att du använder en anslutningspool som ProxySQL för att effektivt hantera anslutningar. Mer information om hur du konfigurerar ProxySQL finns i det här blogginlägget.

Kommentar

ProxySQL är ett communityverktyg med öppen källkod. Microsoft stöder det på bästa sätt. Kontakta supporten för ProxySQL-produkten för att få produktionsstöd med auktoritativ vägledning.

innodb_strict_mode

Om du får ett felmeddelande som liknar "Radstorleken är för stor (> 8126)" kanske du vill inaktivera serverparametern innodb_strict_mode . Det går inte att ändra den här parametern globalt på servernivå eftersom om raddatastorleken är större än 8 000 trunkeras data utan fel. Den här trunkeringen kan leda till potentiell dataförlust. Vi rekommenderar att du ändrar schemat så att det passar sidstorleksgränsen.

Du kan ange den här parametern på sessionsnivå med hjälp init_connectav . Mer information finns i Ange icke-modifierbara serverparametrar.

Kommentar

Om du har en skrivskyddade replikserver kommer replikeringen att OFF avbrytas om du anger innodb_strict_mode på sessionsnivå på en källserver. Vi rekommenderar att du behåller parametern inställd på ON om du har läsrepliker.

time_zone

Vid den första distributionen innehåller en Azure Database for MySQL – flexibel server-instans systemtabeller för tidszonsinformation, men dessa tabeller är inte ifyllda. Du kan fylla i tidszonstabellerna genom att anropa den mysql.az_load_timezone lagrade proceduren från ett verktyg som MySQL-kommandoraden eller MySQL Workbench. Du kan också anropa den lagrade proceduren och ange tidszoner på global nivå eller sessionsnivå med hjälp av Azure Portal eller Azure CLI.

binlog_expire_logs_seconds

I Azure Database for MySQL – flexibel server anger parametern binlog_expire_logs_seconds antalet sekunder som tjänsten väntar innan den binära loggfilen tas bort.

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 binära loggen innehåller också händelser för instruktioner som potentiellt kan ha gjort ändringar. Den binära loggen används huvudsakligen för två syften: replikering och dataåterställningsåtgärder.

Vanligtvis tas de binära loggarna bort 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 tas bort.

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å standardvärdet för 0tas en binär logg bort så snart referensen till den frigörs. Om värdet binlog_expire_logs_seconds för är större än 0tas den binära loggen bort efter det konfigurerade antalet sekunder.

Azure Database for MySQL – Flexibel server hanterar hanterade funktioner, till exempel säkerhetskopiering och läsning av replikborttagning av binära filer internt. När du replikerar datautdata från Azure Database for MySQL – Flexibel server måste den här parametern anges i den primära för att undvika borttagning av binära loggar innan repliken läse från ändringarna i den primära. Om du anger binlog_expire_logs_seconds ett högre värde tas inte de binära loggarna bort tillräckligt snart. Den fördröjningen kan leda till en ökning av lagringsfakturering.

event_scheduler

I Azure Database for MySQL – flexibel server event_scheduler hanterar serverparametern att skapa, schemalägga och köra händelser. Parametern hanterar uppgifter som körs enligt ett schema av en särskild MySQL Event Scheduler-tråd. När parametern event_scheduler är inställd på ONvisas Event Scheduler-tråden som en daemonprocess i utdata från SHOW PROCESSLIST.

Du kan skapa och schemalägga händelser med hjälp av 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>;

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

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 på 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 Portal går du till din Azure Database for MySQL – flexibel serverinstans. Under Inställningar väljer du Serverparametrar.

  2. I fönstret Serverparametrar söker event_schedulerdu efter . I listrutan VÄRDE väljer du PÅ och sedan Spara.

    Kommentar

    Distributionen av den dynamiska konfigurationsändringen till serverparametern kräver ingen omstart.

  3. Om du vill skapa en händelse ansluter du till Azure Database for MySQL – flexibel serverinstans och kör 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 den event_scheduler parameter som du har konfigurerat:

    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 värdena som infogas i tabellen varje minut i en timme (vilket event_scheduler är konfigurerat i det här fallet):

    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 exempel på schemaläggning av SQL-instruktioner som ska köras med olika tidsintervall följer.

Så här kör du en SQL-instruktion nu och upprepar 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>;

Så här kör du en SQL-instruktion varje timme utan slut:

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

Så här kör du 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. Om detta inträffar, när redundansväxlingen är klar, konfigurerar du parametern för att ange värdet till ON.

Icke-modifierbara serverparametrar

Fönstret Serverparametrar i Azure Portal visar både de modifierbara och icke-modifierbara serverparametrarna. De icke-modifierbara serverparametrarna är inte tillgängliga. Du kan konfigurera en icke-modifierad serverparameter på sessionsnivå med hjälp init_connect av i Azure Portal eller Azure CLI.

Relaterat innehåll