MySQL-konfigurationsvariabler är en uppsättning serversystemvariabler som används för att konfigurera serverns funktion och beteende. I det här blogginlägget kommer vi att förklara skillnaderna i hanteringen av konfigurationsvariablerna mellan MySQL 5.7 och MySQL 8.0.
Vi kommer att förklara tre olika sätt att ställa in konfigurationsvariabler baserat på ditt användningsfall. Konfigurationsvariabler som kan ställas in vid körning kallas dynamiska variabler och de som behöver en omstart av MySQL-servern för att träda i kraft kallas icke-dynamiska variabler.
1:Ställ in konfigurationen för den aktuella livslängden för en MySQL-server som körs
De flesta av MySQL-konfigurationerna är dynamiska till sin natur och kan ställas in under körning med kommandot SET. Detta innebär att ändringarna inte är beständiga och kommer att gå förlorade om MySQL-servern startar om. Detta är användbart för att testa beteendet för din konfigurationsändring innan du gör den permanent.
För både MySQL 5.7 och 8.0 kan du åstadkomma detta genom att använda kommandot SET GLOBAL
Exempel:
mysql> set global max_connect_errors=10000;
2:Ställ in och behåll konfigurationsändringen över MySQL-omstarter
När du är nöjd med inställningarna för konfigurationsändring, vill du göra den permanent.
I MySQL 5.7 skulle du behöva göra detta i två steg:
- Ställ in inställningen för körtidskonfiguration med kommandot SET GLOBAL
mysql> set global max_connect_errors=10000;
- Spara den här ändringen i din my.cnf-fil genom att uppdatera den befintliga posten för max_connect_errors eller genom att lägga till en ny.
Detta har blivit mycket enklare i MySQL 8.0. Du kan göra detta i ett enda steg med kommandot SET PERSIST
mysql> set persist max_connect_errors=10000;Hur man ställer in konfigurationsvariabler - MySQL 5.7 vs MySQL 8.0Klicka för att tweeta
Detta kommer att ställa in körtidsvärdet för konfigurationen och även bevara ändringen genom att spara den i filen mysqld-auto.cnf som finns i datakatalogen. Detta är en json-fil och du kommer nu att se följande poster i filen.
{
"Version": 1,
"mysql_server": {
"max_connect_errors": {
"Value": "10000",
"Metadata": {
"Timestamp": 1581135119397374,
"User": "sgroot",
"Host": "localhost"
}
}
}
}
Obs: Konfigurationsinställningarna som finns i mysqld-auto.cnf åsidosätter alltid värdena som finns i filen my.cnf. Så alla ytterligare ändringar du gör i my.cnf-filen för variabeln "max_connect_errors" träder inte i kraft. Detta kan vara förvirrande för dem som går över från MySQL 5.7 eftersom de kan vara vana vid att lagra alla sina inställningar i my.cnf
3:Ställa in konfigurationsvariabler som inte är dynamiska
Vissa av konfigurationsvariablerna kan inte ställas in under körning och skulle kräva en omstart av MySQL för att träda i kraft.
I MySQL 5.7 skulle du göra en post för dessa variabler i din my.cnf-fil och starta om MySQL-servern för att den ska träda i kraft. Exempel på en sådan variabel är innodb_log_file_size.
I MySQL 8.0 kan du köra ett kommando som heter SET PERSIST ONLY som gör en inmatning i mysqld-auto.cnf.
Exempel:
mysql> set persist_only innodb_log_file_size=134217728;
Det är också möjligt att starta om MySQL-servern från kommandoraden med kommandot RESTART. Detta gör att det ändrade värdet på innodb_log_file_size träder i kraft.
Obs: Kommandot RESTART fungerar endast om MySQL hanteras med hjälp av externa program som systemd eller mysqld_safe. Se mer information om detta här.
Annars misslyckas kommandot RESTART med ett meddelande som följande.
mysql> RESTART; ERROR 3707 (HY000): Restart server failed (mysqld is not managed by supervisor process).
MySQL-konfigurationshantering över flera servrar
Hantera MySQL-konfiguration i källreplikmiljöer är en tråkig process om du måste hantera flera kluster som kör olika MySQL-versioner. Det är här en hanterad lösning som ScaleGrid skulle vara fördelaktig.
ScaleGrid UI-konsolen kan användas för att granska de aktuella inställningarna för olika konfigurationsvariabler eller ställa in deras värden.
ScaleGrid kan känna igen när en konfigurationsinställning är icke-dynamisk och kommer att varna användaren om en MySQL-omstart krävs för att värdet ska träda i kraft. ScaleGrid kommer också att göra en säkerhetskopia av den aktuella my.cnf-filen innan några nya konfigurationsändringar tillämpas.
I källreplikmiljöer ändrar ScaleGrid konfigurationsinställningarna på ett rullande sätt en server i taget. Om en icke-dynamisk variabel behöver ställas in, utför ScaleGrid en failover av den aktuella mastern för att minimera stilleståndstiden som är involverad om MySQL annars måste startas om.
Besök länken nedan för att lära dig mer om de olika funktionerna i ScaleGrid MySQL-värdlösningen.
