At sikre en problemfri drift af dine produktionsdatabaser er ikke en triviel opgave, og der er en række værktøjer og hjælpeprogrammer til at hjælpe med jobbet. Der er tilgængelige værktøjer til overvågning af sundhed, serverydeevne, analyse af forespørgsler, implementeringer, administration af failover, opgraderinger, og listen fortsætter. ClusterControl som en administrations- og overvågningsplatform for din databaseinfrastruktur skiller sig ud med sin evne til at styre hele livscyklussen fra implementering til overvågning, løbende administration og skalering.
Selvom ClusterControl tilbyder vigtige funktioner som automatisk database-failover, kryptering under transport/i hvile, backup-styring, punkt-i-tidsgendannelse, Prometheus-integration, databaseskalering, kan disse findes i andre virksomhedsstyrings-/overvågningsværktøjer på markedet. Der er dog nogle funktioner, som du ikke finder så nemt. I dette blogindlæg præsenterer vi 9 funktioner, som du ikke finder i andre styrings- og overvågningsværktøjer på markedet (i skrivende stund).
Backupbekræftelse
Enhver sikkerhedskopi er bogstaveligt talt ikke en sikkerhedskopi, før du ved, at den kan gendannes - ved virkelig at bekræfte, at den kan gendannes. ClusterControl gør det muligt at verificere en sikkerhedskopi, efter at sikkerhedskopien er taget, ved at dreje en ny server og teste gendannelse. Bekræftelse af en sikkerhedskopi er en kritisk proces for at sikre, at du opfylder din Recovery Point Objective (RPO)-politik i tilfælde af katastrofegendannelse. Verifikationsprocessen udfører gendannelsen på en ny selvstændig vært (hvor ClusterControl installerer nødvendige databasepakker før gendannelse) eller på en server dedikeret til sikkerhedskopiering.
For at konfigurere sikkerhedskopieringsbekræftelse skal du blot vælge en eksisterende sikkerhedskopi og klikke på Gendan. Der vil være en mulighed for at gendanne og bekræfte:
Derefter skal du blot angive IP-adressen på den server, du ønsker at gendan og bekræft:
Sørg for, at den angivne vært er tilgængelig via adgangskodefri SSH på forhånd. Du har også en håndfuld muligheder nedenunder for klargøringsprocessen. Du kan også lukke bekræftelsesserveren efter gendannelse for at spare omkostninger og ressourcer, efter at sikkerhedskopien er blevet bekræftet. ClusterControl leder efter gendannelsesprocessens afslutningskode og observerer gendannelsesloggen for at kontrollere, om verifikationen mislykkes eller lykkes.
Forenkling af ProxySQL-administration gennem en GUI
Mange er enige om, at det er mere effektivt at have en grafisk brugergrænseflade og mindre udsat for menneskelige fejl, når man konfigurerer et system. ProxySQL er en del af det kritiske databaselag (selvom det sidder oven på det) og skal være synligt nok for DBA's øjne til at spotte almindelige problemer og problemer. ClusterControl giver en omfattende grafisk brugergrænseflade til ProxySQL.
ProxySQL-instanser kan implementeres på nye værter, eller eksisterende kan importeres til ClusterControl. ClusterControl kan konfigurere ProxySQL til at blive integreret med en virtuel IP-adresse (leveret af Keepalved) for enkelt slutpunktsadgang til databaseserverne. Det giver også overvågningsindsigt til de vigtigste ProxySQL-komponenter som Queries Backend, Slow Queries, Top Queries, Query Hits og en masse andre overvågningsstatistikker. Det følgende er et skærmbillede, der viser, hvordan du tilføjer en ny forespørgselsregel:
Hvis du tilføjede en meget kompleks forespørgselsregel, ville du være mere tryg ved at gøre det via den grafiske brugergrænseflade. Hvert felt har et værktøjstip til at hjælpe dig, når du udfylder formularen for forespørgselsregel. Når du tilføjer eller ændrer en ProxySQL-konfiguration, vil ClusterControl sørge for, at ændringerne foretages i runtime og gemmes på disken for at holde dem.
ClusterControl 1.7.4 understøtter nu både ProxySQL 1.x og ProxySQL 2.x.
Driftsrapporter
Driftsrapporter er et sæt oversigtsrapporter for din databaseinfrastruktur, som kan genereres på farten eller kan planlægges til at blive sendt til forskellige modtagere. Disse rapporter består af forskellige kontroller og omhandler forskellige daglige DBA-opgaver. Ideen bag ClusterControl driftsrapportering er at samle alle de mest relevante data i et enkelt dokument, som hurtigt kan analyseres for at få en klar forståelse af status for databaserne og dens processer.
Med ClusterControl kan du planlægge miljørapporter på tværs af klynge som daglig systemrapport, pakkeopgraderingsrapport, skemaændringsrapport samt sikkerhedskopier og tilgængelighed. Disse rapporter hjælper dig med at holde dit miljø sikkert og operationelt. Du vil også se anbefalinger til, hvordan du løser huller. Rapporter kan adresseres til SysOps, DevOps eller endda ledere, der gerne vil have regelmæssige statusopdateringer om et givet systems helbred.
Følgende er et eksempel på en daglig driftsrapport sendt til din postkasse med hensyn til tilgængelighed:
Vi har dækket dette i detaljer i dette blogindlæg, En oversigt over databasedriftsrapportering i ClusterControl.
Gensynkroniser en slave via sikkerhedskopiering
ClusterControl tillader iscenesættelse af en slave (uanset om det er en ny slave eller en ødelagt slave) via den seneste fulde eller trinvise backup. Det lyder ikke særlig spændende, men denne funktion er enorm, hvis du har store datasæt på 100 GB og derover. Almindelig praksis ved resynkronisering af en slave er at streame en sikkerhedskopi af den aktuelle master, hvilket vil tage noget tid afhængigt af databasestørrelsen. Dette vil tilføje en ekstra byrde for masteren, hvilket kan bringe masterens ydeevne i fare.
For at gensynkronisere en slave via backup skal du vælge slavenoden under Nodes-siden og gå til Node Actions -> Rebuild Replication Slave -> Genopbyg fra en backup. Kun PITR-kompatibel backup vil blive vist i rullemenuen:
Gensynkronisering af en slave fra en sikkerhedskopi vil ikke medføre yderligere overhead til masteren, hvor ClusterControl udtrækker og streamer sikkerhedskopien fra backuplagerpladsen til slaven og til sidst konfigurerer replikeringsforbindelsen mellem slaven til masteren. Slaven vil senere indhente masteren, når replikeringslinket er etableret. Mesteren er uberørt under hele processen, og du kan følge hele fremskridtet under Aktivitet -> Jobs.
Bootstrap en Galera Cluster
Galera Cluster er en meget populær, når man implementerer høj tilgængelighed for MySQL eller MariaDB, men de forkerte ledelseskommandoer kan føre til katastrofale konsekvenser. Tag et kig på dette blogindlæg om, hvordan man bootstrap en Galera Cluster under forskellige forhold. Dette illustrerer, at bootstrapping af en Galera Cluster har mange variabler og skal udføres med ekstrem omhu. Ellers kan du miste data eller forårsage en splittet hjerne. ClusterControl forstår databasetopologien og ved præcis, hvad de skal gøre for at bootstrap en databaseklynge korrekt. For at bootstrap en klynge via ClusterControl skal du klikke på Cluster Actions -> Bootstrap Cluster:
Du vil have mulighed for at lade ClusterControl vælge den rigtige bootstrap-knude automatisk, eller udføre en indledende bootstrap, hvor du vælger en af databasenoderne fra listen til at blive referencenoden og sletter MySQL-datadirigen på joiner-knuderne for at tvinge SST fra den bootstrapped node. Hvis bootstrapping-processen mislykkes, vil ClusterControl trække MySQL-fejlloggen.
Hvis du gerne vil udføre en manuel bootstrap, kan du også bruge "Find mest avancerede node"-funktionen og udføre cluster bootstrap-handlingen på den mest avancerede node rapporteret af ClusterControl.
Centraliseret konfiguration og logning
ClusterControl trækker en række vigtige konfigurations- og logfiler og viser dem i en træstruktur i ClusterControl. En central visning af disse filer er nøglen til effektivt at forstå og fejlfinde distribuerede databaseopsætninger. Den traditionelle måde at tailing/greppe disse filer på er for længst forbi med ClusterControl. Følgende skærmbillede viser ClusterControls konfigurationsfilhåndtering, som oplistede alle relaterede konfigurationsfiler for denne klynge i én enkelt visning (med syntaksfremhævelse, selvfølgelig):
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 en genstart af serveren, som derefter vil blive informeret af ClusterControl.
Databaseklyngekloning
Med ClusterControl kan du hurtigt klone en eksisterende MySQL Galera Cluster, så du har en nøjagtig kopi af datasættet på den anden klynge. ClusterControl udfører kloningsoperationen online uden nogen form for låsning eller nedetid til den eksisterende klynge. Det er som en klyngeskaleringsoperation, bortset fra at begge klynger er uafhængige af hinanden, efter at synkroniseringen er fuldført. Den klonede klynge behøver ikke nødvendigvis at have samme klyngestørrelse som den eksisterende. Vi kunne starte med en "one-node cluster" og skalere den ud med flere databasenoder på et senere tidspunkt.
En anden lignende funktion, der tilbydes af ClusterControl, er "Create Cluster from Backup". Denne funktion blev introduceret i ClusterControl 1.7.1, specifikt for Galera Cluster og PostgreSQL klynger, hvor man kan oprette en ny klynge fra den eksisterende backup. I modsætning til klyngekloning bringer denne operation ikke yderligere belastning til kildeklyngen med den afvejning, at den klonede klynge ikke vil være i samme tilstand som kildeklyngen.
Vi har dækket dette emne i detaljer i dette blogindlæg, Sådan opretter du en klon af din MySQL- eller PostgreSQL-databaseklynge.
Gendan fysisk sikkerhedskopi
De fleste databasestyringsværktøjer tillader sikkerhedskopiering af en database, og kun en håndfuld af dem understøtter kun databasegendannelse af logisk backup. ClusterControl understøtter fuld gendannelse ikke kun for logiske sikkerhedskopier, men også fysiske sikkerhedskopier, uanset om det er en fuld eller trinvis sikkerhedskopiering. Gendannelse af en fysisk sikkerhedskopi kræver en række kritiske trin (især trinvise sikkerhedskopier), som grundlæggende går ud på at forberede en sikkerhedskopi, kopiere de forberedte data til databiblioteket, tildele korrekt tilladelse/ejerskab og starte noden i en korrekt rækkefølge for at opretholde datakonsistens på tværs alle medlemmer i klyngen. ClusterControl udfører alle disse handlinger automatisk.
Du kan også gendanne en fysisk sikkerhedskopi til en anden node, der ikke er en del af en klynge. I ClusterControl hedder muligheden for dette "Create Cluster from Backup". Du kan starte med en "one-node cluster" for at teste gendannelsesprocessen på en anden server eller for at kopiere din databaseklynge til en anden placering.
ClusterControl understøtter også gendannelse af en ekstern sikkerhedskopi, en sikkerhedskopi, der ikke er taget gennem ClusterControl. Du skal blot uploade sikkerhedskopien til ClusterControl-serveren og angive den fysiske sti til backupfilen ved gendannelse. ClusterControl tager sig af resten.
Klynge-til-klynge-replikering
Dette er en ny funktion introduceret i ClusterControl 1.7.4. ClusterControl kan nu håndtere og overvåge klynge-klynge-replikering, hvilket grundlæggende udvider den asynkrone databasereplikering mellem flere klyngesæt på flere geografiske steder. En klynge kan indstilles som en masterklynge (aktiv klynge, som behandler læser/skriver), og slaveklyngen kan indstilles som en skrivebeskyttet klynge (standbyklynge, som også kan behandle udlæsninger). ClusterControl understøtter asynkron cluster-cluster-replikering til Galera Cluster (binær log skal være aktiveret) og også master-slave-replikering til PostgreSQL Streaming-replikering.
For at oprette en ny klynge, replikaterne fra en anden klynge, skal du gå til Cluster Actions -> Create Slave Cluster:
Resultatet af ovenstående implementering præsenteres tydeligt på Database Cluster List-dashboardet :
Slave-klyngen konfigureres automatisk som skrivebeskyttet, replikerer fra den primære klynge og fungerer som en standby-klynge. Hvis en katastrofe rammer den primære klynge, og du vil aktivere det sekundære websted, skal du blot vælge menuen "Deaktiver skrivebeskyttet" , der er tilgængelig under rullemenuen Noder -> Nodehandlinger for at promovere den som en aktiv klynge.