In de afgelopen vijf berichten van de blogreeks hebben we het gehad over de implementatie van clustering/replicatie (MySQL / Galera, MySQL Replication, MongoDB &PostgreSQL), beheer en monitoring van uw bestaande databases en clusters, prestatiebewaking en gezondheid, hoe u uw installatie kunt maken zeer beschikbaar via HAProxy en MaxScale en in de laatste post, hoe u zich kunt voorbereiden op rampen door back-ups te plannen.
Sinds ClusterControl 1.2.11 hebben we belangrijke verbeteringen aangebracht in de databaseconfiguratiemanager. Met de nieuwe versie kunnen parameters op meerdere databasehosts tegelijkertijd worden gewijzigd en, indien mogelijk, hun waarden tijdens runtime worden gewijzigd.
We hebben het nieuwe MySQL-configuratiebeheer beschreven in een Tips &Tricks-blogpost, maar deze blogpost gaat dieper in op configuratiebeheer binnen ClusterControl voor MySQL, PostgreSQL en MongoDB.
ClusterControl Configuratiebeheer
De interface voor configuratiebeheer is te vinden onder Beheren> Configuraties. Van hieruit kunt u de configuraties van uw databaseknooppunten en andere tools die door ClusterControl worden beheerd, bekijken of wijzigen. ClusterControl importeert de nieuwste configuratie van alle knooppunten en overschrijft eerder gemaakte kopieën. Momenteel worden er geen historische gegevens bijgehouden.
Als u de configuratiebestanden liever handmatig rechtstreeks op de knooppunten wilt bewerken, kunt u de gewijzigde configuratie opnieuw importeren door op de knop Importeren te drukken.
En last but not least:u kunt configuratiesjablonen maken of bewerken. Deze sjablonen worden gebruikt wanneer u nieuwe knoop punten in uw cluster implementeert. Uiteraard worden wijzigingen die in de sjablonen zijn aangebracht niet met terugwerkende kracht toegepast op de reeds geïmplementeerde nodes die met deze sjablonen zijn gemaakt.
MySQL-configuratiebeheer
Zoals eerder vermeld, kreeg het MySQL-configuratiebeheer een volledige revisie in ClusterControl 1.2.11. De interface is nu intuïtiever. Bij het wijzigen van de parameters controleert ClusterControl of de parameter daadwerkelijk bestaat. Dit zorgt ervoor dat uw configuratie het opstarten van MySQL niet zal weigeren vanwege parameters die niet bestaan.
Via Beheren -> Configuraties vindt u een overzicht van alle configuratiebestanden die binnen het geselecteerde cluster worden gebruikt, inclusief load balancer-knooppunten.
We gebruiken een boomstructuur om hosts en hun respectievelijke configuratiebestanden gemakkelijk te bekijken. Onder aan de structuur vindt u de configuratiesjablonen die beschikbaar zijn voor dit cluster.
Parameters wijzigen
Stel dat we een eenvoudige parameter moeten wijzigen, zoals het maximum aantal toegestane verbindingen (max_connections), dan kunnen we deze parameter eenvoudig tijdens runtime wijzigen.
Selecteer eerst de hosts waarop u deze wijziging wilt toepassen.
Selecteer vervolgens de sectie die u wilt wijzigen. In de meeste gevallen zult u de MYSQLD-sectie willen wijzigen. Als u de standaardtekenset voor MySQL wilt wijzigen, moet u dat wijzigen in zowel de MYSQLD- als de clientsectie.
Indien nodig kunt u ook een nieuwe sectie maken door simpelweg de nieuwe sectienaam in te typen. Hiermee wordt een nieuwe sectie in de my.cnf gemaakt.
Zodra we een parameter hebben gewijzigd en de nieuwe waarde hebben ingesteld door op "Doorgaan" te drukken, controleert ClusterControl of de parameter bestaat voor deze versie van MySQL. Dit is om te voorkomen dat niet-bestaande parameters de initialisatie van MySQL bij de volgende herstart blokkeren.
Wanneer we op "Doorgaan" drukken voor de max_connections-wijziging, ontvangen we een bevestiging dat deze is toegepast op de configuratie en tijdens runtime is ingesteld met SET GLOBAL. Opnieuw opstarten is niet vereist, aangezien max_connections een parameter is die we tijdens runtime kunnen wijzigen.
Stel nu dat we de grootte van de bufferpool willen wijzigen, dan zou MySQL opnieuw moeten worden opgestart voordat het van kracht wordt:
En zoals verwacht is de waarde gewijzigd in het configuratiebestand, maar een herstart is vereist. U kunt dit doen door handmatig in te loggen op de host en het MySQL-proces opnieuw te starten. Een andere manier om dit vanuit ClusterControl te doen, is door het Nodes-dashboard te gebruiken.
Nodes herstarten in een Galera-cluster
U kunt per node een herstart uitvoeren door "Restart Node" te selecteren en op de knop "Doorgaan" te drukken.
Wanneer u "Initial Start" selecteert op een Galera-knooppunt, zal ClusterControl de MySQL-gegevensmap leegmaken en op deze manier een volledige kopie forceren. Bij een configuratiewijziging is dit uiteraard niet nodig. Zorg ervoor dat u het selectievakje "initiële" uitgeschakeld laat in het bevestigingsvenster. Dit stopt en start MySQL op de host, maar afhankelijk van uw werklast en bufferpoolgrootte kan dit enige tijd duren, aangezien MySQL de vuile pagina's van de InnoDB-bufferpool naar schijf zal spoelen. Dit zijn de pagina's die zijn gewijzigd in het geheugen, maar niet op de schijf.
Nodes herstarten in een MySQL Master-Slave-topologieën
Voor MySQL-master-slave-topologieën kunt u niet zomaar knooppunt voor knooppunt opnieuw opstarten. Tenzij downtime van de master acceptabel is, moet u eerst de configuratiewijzigingen toepassen op de slaves en vervolgens een slave promoveren om de nieuwe master te worden.
Je kunt de slaves één voor één doorlopen en er een "Restart Node" op uitvoeren.
Nadat u de wijzigingen op alle slaven hebt toegepast, promoveert u een slaaf om de nieuwe meester te worden:
Nadat de slave de nieuwe master is geworden, kunt u de oude master-node afsluiten en opnieuw opstarten om de wijziging toe te passen.
Configuraties importeren
Nu we de wijziging rechtstreeks op de database hebben toegepast, evenals in het configuratiebestand, duurt het tot de volgende configuratie-import om de wijziging weerspiegeld te zien in de configuratie die is opgeslagen in ClusterControl. Als u minder geduld heeft, kunt u een onmiddellijke configuratie-import plannen door op de knop "Importeren" te drukken.
PostgreSQL-configuratiebeheer
Voor PostgreSQL werkt het configuratiebeheer iets anders dan het MySQL-configuratiebeheer. Over het algemeen heb je hier dezelfde functionaliteit:wijzig de configuratie, importeer configuraties voor alle nodes en definieer/wijzig sjablonen.
Het verschil hier is dat je het hele configuratiebestand onmiddellijk kunt wijzigen en deze configuratie terug kunt schrijven naar het databaseknooppunt.
Als de aangebrachte wijzigingen een herstart vereisen, verschijnt een knop "Herstarten" waarmee u het knooppunt opnieuw kunt opstarten om de wijzigingen toe te passen.
MongoDB-configuratiebeheer
Het MongoDB-configuratiebeheer werkt vergelijkbaar met het MySQL-configuratiebeheer:u kunt de configuratie wijzigen, configuraties voor alle knooppunten importeren, parameters wijzigen en sjablonen wijzigen.
Het wijzigen van de configuratie is vrij eenvoudig, door gebruik te maken van het dialoogvenster Parameter wijzigen (zoals beschreven in de sectie "Parameters wijzigen"::
Eenmaal gewijzigd, kunt u de door ClusterControl voorgestelde actie na de wijziging zien in het dialoogvenster "Config Change Log":
U kunt vervolgens doorgaan met het opnieuw opstarten van de respectieve MongoDB-knooppunten, één knooppunt tegelijk, om de wijzigingen te laden.
Laatste gedachten
In deze blogpost hebben we geleerd hoe u uw configuraties in ClusterControl kunt beheren, wijzigen en sjablonen. Het wijzigen van de sjablonen kan u veel tijd besparen wanneer u slechts één knooppunt in uw topologie hebt geïmplementeerd. Aangezien de sjabloon voor nieuwe nodes zal worden gebruikt, bespaart dit u achteraf alle configuraties te wijzigen. Voor op MySQL en MongoDB gebaseerde knooppunten is het wijzigen van de configuratie op alle knooppunten echter triviaal geworden vanwege de nieuwe interface voor configuratiebeheer.
Ter herinnering, we hebben onlangs in dezelfde serie de implementatie van clustering/replicatie (MySQL / Galera, MySQL-replicatie, MongoDB &PostgreSQL), beheer en monitoring van uw bestaande databases en clusters, prestatiebewaking en gezondheid besproken, hoe u uw installatie sterk kunt maken beschikbaar via HAProxy en MaxScale en in de laatste post, hoe u zich kunt voorbereiden op rampen door back-ups te plannen.