MySQL-configuratievariabelen zijn een set serversysteemvariabelen die worden gebruikt om de werking en het gedrag van de server te configureren. In deze blogpost leggen we de verschillen uit in het beheer van de configuratievariabelen tussen MySQL 5.7 en MySQL 8.0.
We zullen drie verschillende manieren uitleggen voor het instellen van de configuratievariabelen op basis van uw gebruiksscenario. Configuratievariabelen die tijdens runtime kunnen worden ingesteld, worden dynamische variabelen genoemd en variabelen die een herstart van de MySQL-server nodig hebben om van kracht te worden, worden niet-dynamische variabelen genoemd.
1:Stel de configuratie in voor de huidige levensduur van een draaiende MySQL-server
De meeste MySQL-configuraties zijn dynamisch van aard en kunnen tijdens runtime worden ingesteld met het SET-commando. Dit betekent dat de wijzigingen niet blijvend zijn en verloren gaan als de MySQL-server opnieuw wordt opgestart. Dit is handig om het gedrag van uw configuratiewijziging te testen voordat u deze permanent maakt.
Voor zowel MySQL 5.7 als 8.0 kunt u dit bereiken met het commando SET GLOBAL
Voorbeeld:
mysql> set global max_connect_errors=10000;
2:de configuratiewijziging instellen en volhouden tijdens MySQL-herstarts
Zodra u tevreden bent met de instellingen voor het wijzigen van de configuratie, wilt u deze permanent maken.
In MySQL 5.7 zou je dit in 2 stappen moeten doen:
- Stel de runtime-configuratie-instelling in met het commando SET GLOBAL
mysql> set global max_connect_errors=10000;
- Sla deze wijziging op in uw my.cnf-bestand door de bestaande vermelding voor max_connect_errors bij te werken of door een nieuwe toe te voegen.
Dit is veel gemakkelijker geworden in MySQL 8.0. U kunt dit in één stap doen met het commando SET PERSIST
mysql> set persist max_connect_errors=10000;Configuratievariabelen instellen - MySQL 5.7 vs MySQL 8.0Klik om te tweeten
Hiermee wordt de runtime-waarde voor de configuratie ingesteld en wordt de wijziging ook behouden door deze op te slaan in het bestand mysqld-auto.cnf dat in de gegevensmap bestaat. Dit is een json-bestand en u ziet nu de volgende vermeldingen in het bestand.
{
"Version": 1,
"mysql_server": {
"max_connect_errors": {
"Value": "10000",
"Metadata": {
"Timestamp": 1581135119397374,
"User": "sgroot",
"Host": "localhost"
}
}
}
}
Opmerking: De configuratie-instellingen die aanwezig zijn in mysqld-auto.cnf hebben altijd voorrang op de waarden die aanwezig zijn in het my.cnf-bestand. Dus alle verdere wijzigingen die u aanbrengt in het my.cnf-bestand voor de variabele "max_connect_errors" worden niet van kracht. Dit kan verwarrend zijn voor degenen die overstappen van MySQL 5.7, omdat ze misschien gewend zijn om al hun instellingen op te slaan in my.cnf
3:Configuratievariabelen instellen die niet dynamisch zijn
Sommige configuratievariabelen kunnen tijdens runtime niet worden ingesteld en zouden MySQL opnieuw moeten opstarten om effect te hebben.
In MySQL 5.7 zou u deze variabelen in uw my.cnf-bestand invoeren en de MySQL-server herstarten om het van kracht te laten worden. Een voorbeeld voor zo'n variabele is innodb_log_file_size.
In MySQL 8.0 kunt u een commando uitvoeren met de naam SET PERSIST ONLY, dat een invoer maakt in mysqld-auto.cnf.
Voorbeeld:
mysql> set persist_only innodb_log_file_size=134217728;
Het is ook mogelijk om de MySQL-server opnieuw op te starten vanaf de opdrachtregel met behulp van de opdracht RESTART. Hierdoor wordt de gewijzigde waarde van innodb_log_file_size van kracht.
Opmerking: De opdracht RESTART werkt alleen als MySQL wordt beheerd met externe programma's zoals systemd of mysqld_safe. Zie hier meer details over.
Anders mislukt de RESTART-opdracht met een bericht zoals het volgende.
mysql> RESTART; ERROR 3707 (HY000): Restart server failed (mysqld is not managed by supervisor process).
MySQL-configuratiebeheer op meerdere servers
Het beheren van MySQL-configuratie in bron-replica-omgevingen is een vervelend proces als je meerdere clusters moet beheren waarop verschillende MySQL-versies draaien. Dit is waar een beheerde oplossing zoals ScaleGrid nuttig zou zijn.
De ScaleGrid UI-console kan worden gebruikt om de huidige instellingen van verschillende configuratievariabelen te bekijken of hun waarden in te stellen.
ScaleGrid kan herkennen wanneer een configuratie-instelling niet-dynamisch is en zal de gebruiker waarschuwen als MySQL opnieuw moet worden opgestart om de waarde van kracht te laten worden. ScaleGrid maakt ook een back-up van het huidige my.cnf-bestand voordat nieuwe configuratiewijzigingen worden toegepast.
In source-replica-omgevingen wijzigt ScaleGrid de configuratie-instellingen op een rollende manier, één server tegelijk. Als een niet-dynamische variabele moet worden ingesteld, voert ScaleGrid een failover van de huidige master uit om de downtime te minimaliseren die erbij komt kijken als MySQL anders opnieuw moet worden opgestart.
Bezoek de onderstaande link om meer te weten te komen over de verschillende functies van de ScaleGrid MySQL-hostingoplossing.
