sql >> Database teknologi >  >> NoSQL >> MongoDB

Tips til administration af dine databasekonfigurationer

I de sidste fem indlæg i blog-serien dækkede vi implementering af clustering/replikering (MySQL / Galera, MySQL Replication, MongoDB &PostgreSQL), styring og overvågning af dine eksisterende databaser og klynger, ydeevneovervågning og sundhed, hvordan du laver din opsætning meget tilgængelig gennem HAProxy og MaxScale og i det sidste indlæg, hvordan du forbereder dig selv på katastrofer ved at planlægge sikkerhedskopier.

Siden ClusterControl 1.2.11 har vi foretaget store forbedringer af databasekonfigurationsstyringen. Den nye version tillader ændring af parametre på flere databaseværter på samme tid og, hvis det er muligt, ændring af deres værdier under kørsel.

Vi præsenterede den nye MySQL Configuration Management i et Tips &Tricks blogindlæg, men dette blogindlæg vil gå mere i dybden og dække Configuration Management inden for ClusterControl til MySQL, PostgreSQL og MongoDB.

ClusterControl Configuration Management

Konfigurationsstyringsgrænsefladen kan findes under Administrer> Konfigurationer. Herfra kan du se eller ændre konfigurationerne af dine databasenoder og andre værktøjer, som ClusterControl administrerer. ClusterControl vil importere den seneste konfiguration fra alle noder og overskrive tidligere kopier, der er lavet. I øjeblikket opbevares der ingen historiske data.

Hvis du hellere vil redigere konfigurationsfilerne manuelt direkte på noderne, kan du genimportere den ændrede konfiguration ved at trykke på knappen Importer.

Og sidst men ikke mindst:Du kan oprette eller redigere konfigurationsskabeloner. Disse skabeloner bruges, når du implementerer nye noder i din klynge. Selvfølgelig vil eventuelle ændringer, der er foretaget i skabelonerne, ikke med tilbagevirkende kraft anvendes på de allerede implementerede noder, der blev oprettet ved hjælp af disse skabeloner.

MySQL Configuration Management

Som tidligere nævnt fik MySQL-konfigurationsadministrationen en komplet overhaling i ClusterControl 1.2.11. Grænsefladen er nu mere intuitiv. Ved ændring af parametrene kontrollerer ClusterControl, om parameteren faktisk eksisterer. Dette sikrer, at din konfiguration ikke nægter opstart af MySQL på grund af parametre, der ikke eksisterer.

Fra Administrer -> Konfigurationer finder du en oversigt over alle konfigurationsfiler, der er brugt i den valgte klynge, inklusive load balancer-noder.

Vi bruger en træstruktur til nemt at se værter og deres respektive konfigurationsfiler. Nederst i træet finder du de tilgængelige konfigurationsskabeloner for denne klynge.

Ændring af parametre

Antag, at vi skal ændre en simpel parameter som det maksimale antal tilladte forbindelser (max_connections), vi kan simpelthen ændre denne parameter under kørsel.

Vælg først de værter, som denne ændring skal anvendes på.

Vælg derefter den sektion, du vil ændre. I de fleste tilfælde vil du gerne ændre MYSQLD-sektionen. Hvis du ønsker at ændre standardtegnsættet for MySQL, skal du ændre det i både MYSQLD og klientsektioner.

Om nødvendigt kan du også oprette en ny sektion ved blot at indtaste det nye sektionsnavn. Dette vil oprette en ny sektion i my.cnf.

Når vi har ændret en parameter og indstillet dens nye værdi ved at trykke på "Fortsæt", vil ClusterControl kontrollere, om parameteren findes for denne version af MySQL. Dette er for at forhindre, at ikke-eksisterende parametre blokerer for initialiseringen af ​​MySQL ved næste genstart.

Når vi trykker på "fortsæt" for ændringen af ​​max_connections, vil vi modtage en bekræftelse på, at den er blevet anvendt på konfigurationen og indstillet under kørsel ved hjælp af SET GLOBAL. En genstart er ikke påkrævet, da max_connections er en parameter, vi kan ændre under kørsel.

Antag nu, at vi vil ændre bufferpuljens størrelse, dette ville kræve en genstart af MySQL, før det træder i kraft:

Og som forventet er værdien blevet ændret i konfigurationsfilen, men en genstart er påkrævet. Du kan gøre dette ved at logge på værten manuelt og genstarte MySQL-processen. En anden måde at gøre dette på fra ClusterControl er ved at bruge Nodes dashboard.

Genstart af noder i en Galera-klynge

Du kan udføre en genstart pr. node ved at vælge "Genstart node" og trykke på knappen "Fortsæt".

Når du vælger "Initial Start" på en Galera-node, vil ClusterControl tømme MySQL-databiblioteket og tvinge en fuld kopi på denne måde. Dette er naturligvis unødvendigt for en konfigurationsændring. Sørg for at lade afkrydsningsfeltet "indledende" være umarkeret i bekræftelsesdialogen. Dette vil stoppe og starte MySQL på værten, men afhængigt af din arbejdsbelastning og bufferpoolstørrelse kan dette tage et stykke tid, da MySQL vil begynde at skylle de beskidte sider fra InnoDB-bufferpuljen til disken. Dette er de sider, der er blevet ændret i hukommelsen, men ikke på disken.

Genstart af noder i en MySQL Master-Slave topologi

For MySQL master-slave topologier kan du ikke bare genstarte node for node. Medmindre nedetid for masteren er acceptabel, skal du først anvende konfigurationsændringerne på slaverne og derefter fremme en slave til at blive den nye master.

Du kan gå igennem slaverne en efter en og udføre en "Genstart node" på dem.

Efter at have anvendt ændringerne på alle slaver, forfrem en slave til at blive den nye master:

Når slaven er blevet den nye master, kan du lukke og genstarte den gamle masterknude for at anvende ændringen.

Import af konfigurationer

Nu hvor vi har anvendt ændringen direkte på databasen, samt konfigurationsfilen, vil det tage indtil næste konfigurationsimport at se ændringen afspejlet i konfigurationen gemt i ClusterControl. Hvis du er mindre tålmodig, kan du planlægge en øjeblikkelig konfigurationsimport ved at trykke på knappen "Importer".

PostgreSQL-konfigurationsstyring

For PostgreSQL fungerer Configuration Management en smule anderledes end MySQL Configuration Management. Generelt har du den samme funktionalitet her:ændre konfigurationen, importere konfigurationer for alle noder og definere/ændre skabeloner.

Forskellen her er, at du straks kan ændre hele konfigurationsfilen og skrive denne konfiguration tilbage til databasenoden.

Hvis de foretagne ændringer kræver en genstart, vises en "Genstart"-knap, der giver dig mulighed for at genstarte noden for at anvende ændringerne.

MongoDB Configuration Management

MongoDB Configuration Management fungerer på samme måde som MySQL Configuration Management:du kan ændre konfigurationen, importere konfigurationer for alle noder, ændre parametre og ændre skabeloner.

Ændring af konfigurationen er ret ligetil ved at bruge dialogboksen Change Parameter (som beskrevet i afsnittet "Ændring af parametre"::

Når den er ændret, kan du se handlingen efter ændring foreslået af ClusterControl i dialogboksen "Konfigurationsændringslog":

Du kan derefter fortsætte med at genstarte de respektive MongoDB-noder, én node ad gangen, for at indlæse ændringerne.

Sidste tanker

I dette blogindlæg lærte vi om, hvordan du administrerer, ændrer og skaber skabeloner for dine konfigurationer i ClusterControl. Ændring af skabelonerne kan spare dig for en masse tid, når du kun har installeret én node i din topologi. Da skabelonen vil blive brugt til nye noder, vil dette spare dig for at ændre alle konfigurationer efterfølgende. For MySQL- og MongoDB-baserede noder er det imidlertid blevet trivielt at ændre konfigurationen på alle noder på grund af den nye Configuration Management-grænseflade.

Som en påmindelse dækkede vi for nylig i den samme serie implementering af clustering/replikering (MySQL / Galera, MySQL Replication, MongoDB &PostgreSQL), styring og overvågning af dine eksisterende databaser og klynger, præstationsovervågning og sundhed, hvordan du gør dit opsætning højt tilgængelig via HAProxy og MaxScale og i det sidste indlæg, hvordan du forbereder dig på katastrofer ved at planlægge sikkerhedskopier.


  1. projektion fungerer ikke med find-forespørgsel

  2. En introduktion til Percona Server til MongoDB 4.2

  3. MongoDB starter ikke efter servernedbrud

  4. Hvordan unhideIndex() virker i MongoDB