MySQL Workbench Alternatives - ClusterControl Configuration Management

MySQL-konfigurationsstyring består af to hovedkomponenter - MySQL-konfigurationsfiler og runtime-konfiguration. Anvendelse af konfigurationsændringer på runtime-miljøet kan udføres gennem MySQL-serverklienter uden privilegier til sessionsvariabler, men SUPER-privilegier for globale variabler. Det er også nødvendigt at anvende de samme konfigurationsændringer i MySQL-konfigurationsfilen for at gøre ændringerne vedvarende på tværs af MySQL-genstarter, ellers vil standardværdierne blive indlæst under opstart.

I dette blogindlæg skal vi se på ClusterControl Configuration Management som et alternativ til MySQL Workbench-konfigurationsstyring.

MySQL Workbench Configuration Management

MySQL Workbench er en grafisk klient til at arbejde med MySQL-servere og databaser til serverversioner 5.x og nyere. Det er frit tilgængeligt og bruges almindeligvis af SysAdmins, DBA'er og udviklere til at udføre SQL-udvikling, datamodellering, MySQL-serveradministration og datamigrering.

Du kan bruge MySQL Workbench til at udføre MySQL/MariaDB-konfigurationsstyring på en ekstern MySQL-server. Der kræves dog nogle indledende trin for at aktivere denne funktion. Fra MySQL Workbench skal du vælge en eksisterende forbindelsesprofil og vælge Konfigurer fjernstyring. Du vil blive præsenteret for en trin-for-trin konfigurationsguide, der hjælper dig med at konfigurere fjernstyring for forbindelsesprofilen:

I starten gøres der et forbindelsesforsøg for at bestemme serverversionen og målmaskinens operativsystem. Dette gør det muligt at validere forbindelsesindstillinger og giver guiden mulighed for at vælge en meningsfuld konfigurationsforudindstilling. Hvis dette forsøg mislykkes, kan du stadig fortsætte til næste trin, hvor du kan tilpasse indstillingerne yderligere, så de passer til fjernservermiljøet.

Når fjernforbindelseskonfigurationen er fuldført, skal du dobbeltklikke på forbindelsesprofilen for at begynde at oprette forbindelse til MySQL-instansen. Gå derefter til Instance -> Options File for at åbne sektionen Configuration Manager. Du bør se noget, der ligner følgende skærmbillede:

Alle eksisterende konfigurationsvariabler fra konfigurationsfilen er forudindlæst i denne konfiguration manager, så du kan se, hvilke muligheder der er aktiveret med dens respektive værdier. Konfigurationer er kategoriseret i en række sektioner - Generelt, logning, InnoDB, netværk og så videre - hvilket virkelig hjælper os med at fokusere på specifikke funktioner, som vi ønsker at justere eller aktivere.

Når du er tilfreds med ændringerne, og før du klikker på "Anvend", skal du sørge for at vælge den korrekte MySQL-gruppesektion fra rullemenuen (lige ved siden af ​​knappen Kassér). Når den er blevet anvendt, skulle du se, at konfigurationen er anvendt på MySQL-serveren, hvor en ny linje vises (hvis den ikke eksisterede) i MySQL-konfigurationsfilen.

Bemærk, at et klik på knappen "Anvend" ikke vil skubbe den tilsvarende ændring ind i MySQL runtime. Man skal udføre genstart på MySQL-serveren for at indlæse de nye konfigurationsændringer ved at gå til Instance -> Startup/Shutdown. Dette vil tage et slag på din databases oppetid.

For at se alle de indlæste systemstatus og variabler, gå til Administration -> Status og systemvariabler:

ClusterControl Configuration Management

ClusterControl Configuration Manager kan tilgås under Administrer -> Konfigurationer. ClusterControl trækker en række vigtige konfigurationsfiler og viser dem i en træstruktur. En central visning af disse filer er nøglen til effektivt at forstå og fejlfinde distribuerede databaseopsætninger. Følgende skærmbillede viser ClusterControls konfigurationsfilhåndtering, som listede alle relaterede konfigurationsfiler for denne klynge i én enkelt visning med syntaksfremhævning:

Som du kan se fra skærmbilledet ovenfor, forstår ClusterControl MySQL "!include" " parameter og vil følge alle konfigurationsfiler, der er knyttet til den. For eksempel er der to MySQL-konfigurationsfiler, der trækkes fra vært 192.168.0.21, /etc/my.cnf og /etc/my.cnf.d/secrets-backup.cnf. Du kan åbne flere konfigurationsfiler i en anden redigeringsfane, som gør det nemmere at sammenligne indholdet side om side. ClusterControl henter også den sidste filændringsinformation fra OS-tidsstemplet, som vist nederst til højre i teksteditoren.

ClusterControl eliminerer gentagelsen ved ændring af en konfigurationsmulighed for en databaseklynge. Ændring af en konfigurationsmulighed på flere noder kan udføres via en enkelt grænseflade og vil blive anvendt på databasenoden i overensstemmelse hermed. Når du klikker på "Skift/indstil parameter", kan du vælge de databaseforekomster, du vil ændre, og angive konfigurationsgruppen, parameteren og værdien:

Du kan tilføje en ny parameter til konfigurationsfilen eller ændre en eksisterende parameter . Parameteren vil blive anvendt på de valgte databasenoders runtime og ind i konfigurationsfilen, hvis indstillingen består variabelvalideringsprocessen. Nogle variabler kan kræve et opfølgningstrin såsom genstart af server eller genindlæsning af konfiguration, som derefter vil blive informeret af ClusterControl.

Alle tjenester konfigureret af ClusterControl bruger en basiskonfigurationsskabelon, der er tilgængelig under /usr/share/cmon/templates på ClusterControl-noden. Du kan ændre filen direkte, så den passer til din implementeringspolitik, men denne mappe vil blive erstattet efter en pakkeopgradering. For at sikre, at dine tilpassede konfigurationsskabelonfiler bevarer på tværs af opgraderinger, skal du gemme dine skabelonfiler under mappen /etc/cmon/templates. Når ClusterControl indlæser skabelonfilen til implementering, vil filer under /etc/cmon/templates altid have højere prioritet over filerne under /usr/share/cmon/templates. Hvis der findes to filer med identiske navne i begge mapper, vil den, der er placeret under /etc/cmon/templates, blive brugt.

Gå til Ydeevne -> DB-variabler for at kontrollere runtime-konfigurationen for alle servere i klyngen:

Lægger du mærke til en linje fremhævet med rødt på skærmbilledet ovenfor? Det betyder, at konfigurationen ikke er identisk i alle noder. Dette giver mere synlighed på konfigurationsforskellen mellem værter i en bestemt databaseklynge.

Workbench v ClusterControl:Fordele og ulemper

Hvert produkt har sit eget sæt af fordele og ulemper. For ClusterControl, da det forstår klynge og topologi, er det den bedste konfigurationsmanager til at administrere flere databasenoder på én gang. Det understøtter flere MySQL-leverandører som MariaDB, Percona samt alle Galera Cluster-varianter. Det forstår også database load balancer konfigurationsformat for HAProxy, MariaDB MaxScale, ProxySQL og Keepalived. Da ClusterControl kræver adgangskodefri SSH-konfiguration i begyndelsen af ​​importen/implementeringen af ​​klyngen, kræver konfigurationsstyring ingen fjernopsætning som Workbench, og den fungerer ud af kassen, efter at værterne er administreret af ClusterControl. MySQL-konfigurationsændringer udført af ClusterControl vil automatisk blive indlæst i runtime (for alle understøttede variabler) samt skrevet ind i MySQL-konfigurationsfiler for at blive ved. Med hensyn til ulemper kommer ClusterControl-konfigurationsstyring ikke med konfigurationsbeskrivelser, som kunne hjælpe os med at forudse, hvad der ville ske, hvis vi ændrede konfigurationsindstillingen. Det understøtter ikke alle platforme, som MySQL kan køre, især kun visse Linux-distributioner som CentOS, RHEL, Debian og Ubuntu.

MySQL Workbench understøtter fjernstyring af mange operativsystemer som Windows, FreeBSD, MacOS, Open Solaris og Linux. MySQL Workbench er tilgængelig gratis og kan også bruges med andre MySQL-leverandører som Percona og MariaDB (selvom det ikke er angivet her, virker det med nogle ældre MariaDB-versioner). Det understøtter også administration af installation fra TAR-pakken. Det tillader nogle tilpasninger af konfigurationsfilstien, service/stop-kommandoer og navngivning af MySQL-gruppesektioner. En af de smarte funktioner er, at MySQL Workbench bruger rullemenuen til faste værdier, hvilket kan være en stor hjælp til at reducere risikoen for fejlkonfiguration fra en bruger, som vist på følgende skærmbillede:

På minussiden understøtter MySQL Workbench ikke administration af flere værtskonfigurationer, hvor du skal udføre konfigurationsændringen på hver vært separat. Den presser heller ikke konfigurationsændringerne ind i runtime uden eksplicit MySQL-genstart, hvilket kan kompromittere databasetjenestens oppetid.

Følgende tabel forenkler de væsentlige forskelle taget fra alle de nævnte punkter: