MySQL Workbench Alternatives - ClusterControl Configuration Management

MySQL-konfigurationshantering består av två huvudkomponenter - MySQL-konfigurationsfiler och runtime-konfiguration. Att tillämpa konfigurationsändringar på runtime-miljön kan göras via MySQL-serverklienter utan behörighet för sessionsvariabler men SUPER-privilegier för globala variabler. Att tillämpa samma konfigurationsändringar i MySQL-konfigurationsfilen är också nödvändigt för att göra ändringarna bestående över MySQL-omstarter, annars kommer standardvärdena att laddas under uppstarten.

I det här blogginlägget kommer vi att titta på ClusterControl Configuration Management som ett alternativ till MySQL Workbench-konfigurationshantering.

MySQL Workbench Configuration Management

MySQL Workbench är en grafisk klient för att arbeta med MySQL-servrar och databaser för serverversioner 5.x och högre. Det är fritt tillgängligt och används ofta av SysAdmins, DBA:er och utvecklare för att utföra SQL-utveckling, datamodellering, MySQL-serveradministration och datamigrering.

Du kan använda MySQL Workbench för att utföra MySQL/MariaDB-konfigurationshantering på en fjärransluten MySQL-server. Det finns dock några inledande steg som krävs för att aktivera den här funktionen. Från MySQL Workbench, välj en befintlig anslutningsprofil och välj Konfigurera fjärrhantering. Du kommer att presenteras med en steg-för-steg konfigurationsguide som hjälper dig att ställa in fjärrhantering för anslutningsprofilen:

I början görs ett anslutningsförsök för att fastställa serverversionen och målmaskinens operativsystem. Detta gör att anslutningsinställningarna kan valideras och gör det möjligt för guiden att välja en meningsfull konfigurationsförinställning. Om detta försök misslyckas kan du fortfarande fortsätta till nästa steg, där du kan anpassa inställningarna ytterligare för att passa fjärrservermiljön.

När fjärranslutningskonfigurationen är klar dubbelklickar du på anslutningsprofilen för att börja ansluta till MySQL-instansen. Gå sedan till Instans -> Alternativfil för att öppna avsnittet för konfigurationshanteraren. Du bör se något som liknar följande skärmdump:

Alla befintliga konfigurationsvariabler från konfigurationsfilen är förinlästa i denna konfiguration manager så att du kan se vilka alternativ som har aktiverats med dess respektive värden. Konfigurationer är kategoriserade i ett antal sektioner - Allmänt, loggning, InnoDB, nätverk och så vidare - vilket verkligen hjälper oss att fokusera på specifika funktioner som vi vill justera eller aktivera.

När du är nöjd med ändringarna, och innan du klickar på "Använd", se till att du väljer rätt MySQL-gruppsektion från rullgardinsmenyn (till höger bredvid knappen Kasta). När den väl har tillämpats bör du se att konfigurationen tillämpas på MySQL-servern där en ny rad kommer att visas (om den inte fanns) i MySQL-konfigurationsfilen.

Observera att om du klickar på knappen "Använd" kommer motsvarande ändring inte att föras in i MySQL-körtid. Man måste utföra omstartsoperation på MySQL-servern för att ladda de nya konfigurationsändringarna genom att gå till Instans -> Startup/Shutdown. Detta kommer att ta en träff på din databas drifttid.

För att se alla inlästa systemstatus och variabler, gå till Hantering -> Status och systemvariabler:

ClusterControl Configuration Management

ClusterControl Configuration Manager kan nås under Hantera -> Konfigurationer. ClusterControl hämtar ett antal viktiga konfigurationsfiler och visar dem i en trädstruktur. En centraliserad vy av dessa filer är nyckeln för att effektivt förstå och felsöka distribuerade databasinställningar. Följande skärmdump visar ClusterControls konfigurationsfilhanterare som listade alla relaterade konfigurationsfiler för detta kluster i en enda vy med syntaxmarkering:

Som du kan se från skärmdumpen ovan förstår ClusterControl MySQL "!include" " parameter och kommer att följa alla konfigurationsfiler som är associerade med den. Till exempel finns det två MySQL-konfigurationsfiler som hämtas från värd 192.168.0.21, /etc/my.cnf och /etc/my.cnf.d/secrets-backup.cnf. Du kan öppna flera konfigurationsfiler i en annan redigeringsflik som gör det lättare att jämföra innehållet sida vid sida. ClusterControl hämtar också den senaste filändringsinformationen från OS-tidsstämpeln, som visas längst ner till höger i textredigeraren.

ClusterControl eliminerar repetitiviteten när man ändrar ett konfigurationsalternativ för ett databaskluster. Ändring av ett konfigurationsalternativ på flera noder kan utföras via ett enda gränssnitt och kommer att tillämpas på databasnoden i enlighet med detta. När du klickar på "Ändra/Ange parameter" kan du välja de databasinstanser som du vill ändra och ange konfigurationsgrupp, parameter och värde:

Du kan lägga till en ny parameter i konfigurationsfilen eller ändra en befintlig parameter . Parametern kommer att tillämpas på de valda databasnodernas körtid och i konfigurationsfilen om alternativet klarar variabelvalideringsprocessen. Vissa variabler kan kräva ett uppföljningssteg som omstart av servern eller omladdning av konfiguration, vilket sedan kommer att meddelas av ClusterControl.

Alla tjänster som konfigurerats av ClusterControl använder en baskonfigurationsmall tillgänglig under /usr/share/cmon/templates på ClusterControl-noden. Du kan direkt ändra filen så att den passar din distributionspolicy, men den här katalogen kommer att ersättas efter en paketuppgradering. För att se till att dina anpassade konfigurationsmallfiler finns kvar över uppgraderingar, lagra dina mallfiler i katalogen /etc/cmon/templates. När ClusterControl laddar upp mallfilen för distribution kommer filer under /etc/cmon/templates alltid ha högre prioritet över filerna under /usr/share/cmon/templates. Om två filer med identiska namn finns i båda katalogerna kommer den som finns under /etc/cmon/templates att användas.

Gå till Prestanda -> DB-variabler för att kontrollera körtidskonfigurationen för alla servrar i klustret:

Lägger du märke till en linje markerad i rött i skärmdumpen ovan? Det betyder att konfigurationen inte är identisk i alla noder. Detta ger mer synlighet på konfigurationsskillnaden mellan värdar i ett visst databaskluster.

Workbench v ClusterControl:Fördelar och nackdelar

Varje produkt har sina egna fördelar och nackdelar. För ClusterControl, eftersom den förstår kluster och topologi, är det den bästa konfigurationshanteraren för att hantera flera databasnoder samtidigt. Det stöder flera MySQL-leverantörer som MariaDB, Percona samt alla Galera Cluster-varianter. Den förstår också databasbelastningsbalanseringskonfigurationsformat för HAProxy, MariaDB MaxScale, ProxySQL och Keepalived. Eftersom ClusterControl kräver lösenordslös SSH-konfiguration i början av importen/distribueringen av klustret, kräver konfigurationshantering ingen fjärrinstallation som Workbench och den fungerar direkt efter att värdarna hanteras av ClusterControl. MySQL-konfigurationsändringar som utförs av ClusterControl kommer att laddas in i runtime automatiskt (för alla variabler som stöds) samt skrivs in i MySQL-konfigurationsfiler för beständighet. När det gäller nackdelar kommer ClusterControl-konfigurationshantering inte med konfigurationsbeskrivningar som kan hjälpa oss att förutse vad som skulle hända om vi ändrade konfigurationsalternativet. Den stöder inte alla plattformar som MySQL kan köra, särskilt bara vissa Linux-distributioner som CentOS, RHEL, Debian och Ubuntu.

MySQL Workbench stöder fjärrhantering av många operativsystem som Windows, FreeBSD, MacOS, Open Solaris och Linux. MySQL Workbench är tillgängligt gratis och kan också användas med andra MySQL-leverantörer som Percona och MariaDB (trots att det inte anges här, fungerar det med vissa äldre MariaDB-versioner). Det stöder också hantering av installation från TAR-paketet. Det tillåter vissa anpassningar av konfigurationsfilens sökväg, service/stoppkommandon och namngivning av MySQL-gruppsektioner. En av de snygga funktionerna är att MySQL Workbench använder rullgardinsmenyn för fasta värden, vilket kan vara till stor hjälp för att minska risken för felkonfiguration från en användare, som visas i följande skärmdump:

På nackdelen, MySQL Workbench stöder inte hantering av flera värdkonfigurationer där du måste utföra konfigurationsändringen på varje värd separat. Den pressar inte heller konfigurationsändringarna till körning, utan explicit MySQL-omstart som kan äventyra databastjänstens drifttid.

Följande tabell förenklar de signifikanta skillnaderna från alla de nämnda punkterna: