sql >> Database teknologi >  >> RDS >> MariaDB

Sådan automatiseres Galera Cluster ved hjælp af ClusterControl CLI

Som sysadmins og udviklere bruger vi meget vores tid i en terminal. Så vi bragte ClusterControl til terminalen med vores kommandolinjegrænsefladeværktøj kaldet s9s. s9s giver en nem grænseflade til ClusterControl RPC v2 API. Du vil finde det meget nyttigt, når du arbejder med implementeringer i stor skala, da CLI'en tillader det, vil give dig mulighed for at designe mere komplekse funktioner og arbejdsgange.

Dette blogindlæg viser, hvordan man bruger s9s til at automatisere administrationen af ​​Galera Cluster til MySQL eller MariaDB, samt en simpel master-slave-replikeringsopsætning.

Opsætning

Du kan finde installationsinstruktioner til netop dit OS i dokumentationen. Det, der er vigtigt at bemærke, er, at hvis du tilfældigvis bruger de nyeste s9s-værktøjer fra GitHub, er der en lille ændring i den måde, du opretter en bruger på. Følgende kommando vil fungere fint:

s9s user --create --generate-key --controller="https://localhost:9501" dba 

Generelt kræves der to trin, hvis du vil konfigurere CLI lokalt på ClusterControl-værten. Først skal du oprette en bruger og derefter foretage nogle ændringer i konfigurationsfilen - alle trinene er inkluderet i dokumentationen.

Implementering

Når CLI'en er blevet konfigureret korrekt og har SSH-adgang til dine måldatabaseværter, kan du starte implementeringsprocessen. I skrivende stund kan du bruge CLI til at implementere MySQL-, MariaDB- og PostgreSQL-klynger. Lad os starte med et eksempel på, hvordan man implementerer Percona XtraDB Cluster 5.7. Der kræves en enkelt kommando for at gøre det.

s9s cluster --create --cluster-type=galera --nodes="10.0.0.226;10.0.0.227;10.0.0.228" --vendor=percona --provider-version=5.7 --db -admin-passwd="pass" --os-user=root --cluster-name="PXC_Cluster_57" --vent 

Sidste mulighed "--vent" betyder, at kommandoen vil vente, indtil jobbet er fuldført, og viser dets fremskridt. Du kan springe det over, hvis du vil - i så fald vil s9s-kommandoen vende tilbage med det samme til shell, efter at den har registreret et nyt job i cmon. Dette er helt fint, da cmon er den proces, der håndterer selve jobbet. Du kan altid kontrollere status for et job separat ved at bruge:

[email protected]:~# s9s job --list -l----------------------------------- -------------------------------------------------- -------Opret Galera Cluster Installation af MySQL den 10.0.0.226 [██▊ ] 26.09%Oprettet :2017-10-05 11:23:00 ID :1 Status :KØRENDEStartet :2017-1057-11:2017:02 Bruger :dba Vært :Afsluttet :Gruppe:brugere------------------------------------------------ -----------------------------------------------I alt:1  

Lad os tage et kig på et andet eksempel. Denne gang vil vi oprette en ny klynge, MySQL-replikering:simpel master - slave-par. Igen er en enkelt kommando nok:

[email protected]:~# s9s cluster --create --nodes="10.0.0.229?master;10.0.0.230?slave" --vendor=percona --cluster-type=mysqlreplikation -- provider-version=5.7 --os-user=root --waitCreate MySQL Repplication Cluster/ Job 6 FINISHED [██████████] 100 % Cluster oprettet 

Vi kan nu bekræfte, at begge klynger er oppe og køre:

[email protected]:~# s9s cluster --list --longID STATE TYPE EJER GRUPPE NAVN KOMMENTAR 1 STARTET galera dba brugere PXC_Cluster_57 Alle noder er operationelle. 2 STARTEDE replikering dba-brugere cluster_2 Alle noder er operationelle.I alt:2 

Alt dette er selvfølgelig også synligt via GUI:

Lad os nu tilføje en ProxySQL loadbalancer:

[email protected]:~# s9s cluster --add-node --nodes="proxysql://10.0.0.226" --cluster-id=1ADVARSEL:admin/adminADVARSEL:proxy-monitor/ proxy-monitorJob med ID 7 registreret. 

Denne gang brugte vi ikke muligheden '--vent', så hvis vi vil tjekke fremskridtene, skal vi gøre det på egen hånd. Bemærk venligst, at vi bruger et job-id, som blev returneret af den forrige kommando, så vi får kun oplysninger om dette særlige job:

[email protected]:~# s9s job --list --long --job-id=7--------------------------- -------------------------------------------------- ---------------Tilføj ProxySQL til ClusterWaiting for ProxySQL [██████▋ ] 65.00%Oprettet :2017-10-06 14:09:11 ID :7 Status :RUNNINGStartet :2017-10-06 14:09:12 Bruger :dba Vært :Afsluttet :Gruppe:brugere---------------------------------------- -------------------------------------------------- -------Totalt:7 

Udskalering

Noder kan tilføjes til vores Galera-klynge via en enkelt kommando:

s9s cluster --add-node --nodes 10.0.0.229 --cluster-id 1Job med ID 8 [email protected]:~# s9s job --list --job-id=8ID CID STATE EJERGRUPPE OPRETTET RDY TITLE 8 1 FAILED DBA-brugere 14:15:52 0% Tilføj node til ClusterTotal:8 

Noget gik galt. Vi kan tjekke, hvad der præcist skete:

[email protected]:~# s9s job --log --job-id=8addNode:Bekræftelse af jobparametre.10.0.0.229:3306:Tilføjelse af vært til cluster.10.0.0.229:3306:Test af SSH til host.10.0.0.229:3306:Installerer node.10.0.0.229:3306:Opsætning af ny node (installSoftware =true).10.0.0.229:3306:Registrerede en kørende mysqld-server. Det skal først afinstalleres, eller du kan også tilføje det til ClusterControl. 

Okay, den IP er allerede brugt til vores replikeringsserver. Vi skulle have brugt en anden, gratis IP. Lad os prøve det:

[email protected]:~# s9s cluster --add-node --nodes 10.0.0.231 --cluster-id 1Job med ID 9 [email protected]:~# s9s job -- list --job-id=9ID CID STATE EJER GRUPPE OPRETTET RDY TITEL 9 1 FÆRDIG dba-brugere 14:20:08 100% Tilføj node til ClusterTotal:9 

Administrer

Lad os sige, at vi ønsker at tage en sikkerhedskopi af vores replikeringsmaster. Vi kan gøre det fra GUI, men nogle gange skal vi muligvis integrere det med eksterne scripts. ClusterControl CLI ville passe perfekt til et sådant tilfælde. Lad os tjekke, hvilke klynger vi har:

[email protected]:~# s9s cluster --list --longID STATE TYPE EJER GRUPPE NAVN KOMMENTAR 1 STARTET galera dba brugere PXC_Cluster_57 Alle noder er operationelle. 2 STARTEDE replikering dba-brugere cluster_2 Alle noder er operationelle.I alt:2 

Lad os derefter tjekke værterne i vores replikeringsklynge med klynge-ID 2:

[email protected]:~# s9s nodes --list --long --cluster-id=2STAT VERSION CID CLUSTER HOST PORT COMMENTSoM- 5.7.19-17-log 2 cluster_2 10.0.0.229 3306 Up and runningsoS- 5.7.19-17-log 2 cluster_2 10.0.0.230 3306 Up and runningcoC- 1.4.3.2145 2 cluster_2 10.0.2.15 9500 Up and running 

Som vi kan se, er der tre værter, som ClusterControl kender til - to af dem er MySQL-værter (10.0.0.229 og 10.0.0.230), den tredje er selve ClusterControl-instansen. Lad os kun udskrive de relevante MySQL-værter:

[email protected]:~# s9s noder --list --long --cluster-id=2 10.0.0.2*STAT VERSION CID CLUSTER HOST PORT COMMENTSoM- 5.7.19-17-log 2 cluster_2 10.0.0.229 3306 Op og kørersoS- 5.7.19-17-log 2 cluster_2 10.0.0.230 3306 Op og kørerTotal:3 

I kolonnen "STAT" kan du se nogle tegn der. For mere information vil vi foreslå at se på manualsiden for s9s-nodes (man s9s-nodes). Her vil vi blot opsummere de vigtigste stykker. Det første tegn fortæller os om typen af ​​node:"s" betyder, at det er en almindelig MySQL-node, "c" - ClusterControl-controller. Andet tegn beskriver tilstanden af ​​noden:"o" fortæller os, at den er online. Tredje karakter - nodens rolle. Her beskriver "M" en master og "S" - en slave, mens "C" står for controller. Sidste fjerde tegn fortæller os, om noden er i vedligeholdelsestilstand. "-" betyder, at der ikke er planlagt vedligeholdelse. Ellers ville vi se "M" her. Så ud fra disse data kan vi se, at vores master er en vært med IP:10.0.0.229. Lad os tage en sikkerhedskopi af den og gemme den på controlleren.

[email protected]:~# s9s backup --create --nodes=10.0.0.229 --cluster-id=2 --backup-method=xtrabackupfull --waitCreate Backup| Job 12 FÆRDIG [██████████] 100 % Kommando ok 

Vi kan derefter kontrollere, om det faktisk blev gennemført ok. Bemærk venligst "--backup-format", som giver dig mulighed for at definere, hvilke oplysninger der skal udskrives:

[email protected]:~# s9s backup --list --full --backup-format="Startet:%B Afsluttet:%E Metode:%M Gemt på:%S Størrelse:%s %F\n" --cluster-id=2Startet:15:29:11 Afsluttet:15:29:19 Metode:xtrabackupfull Lagret den:10.0.0.229 Størrelse:543382 backup-full-2017-10-06_152911.xbstream.gzTotal 1 
Severalnines DevOps-guide til databasestyring Lær om, hvad du har brug for at vide for at automatisere og administrere dine open source-databaserDownload til gratisrelaterede ressourcer Databaseautomatisering:Integration af ClusterControl CLI med din ChatBot Sådan bruger du s9s - Kommandolinjegrænsefladen til ClusterControl

Overvågning

Alle databaser skal overvåges. ClusterControl bruger rådgivere til at se nogle af metrikken på både MySQL og operativsystemet. Når en betingelse er opfyldt, sendes en meddelelse. ClusterControl leverer også et omfattende sæt af grafer, både i realtid og historiske til post-mortem eller kapacitetsplanlægning. Nogle gange ville det være fantastisk at have adgang til nogle af disse målinger uden at skulle gennemgå GUI'en. ClusterControl CLI gør det muligt gennem kommandoen s9s-node. Information om, hvordan man gør det, kan findes på manualsiden til s9s-node. Vi viser nogle eksempler på, hvad du kan gøre med CLI.

Først og fremmest, lad os tage et kig på "--node-format"-indstillingen til kommandoen "s9s node". Som du kan se, er der masser af muligheder for at udskrive interessant indhold.

[email protected]:~# s9s node --list --node-format "%N %T %R %c kerner %u%% CPU-udnyttelse %fmG ledig hukommelse, %tMB/s af netto TX+RX, %M\n" "10.0.0.2*"10.0.0.226 galera ingen 1 kerner 13,823200% CPU-udnyttelse 0,503227G ledig hukommelse, 0,061036MB/s netto TX+RX, Op og køre10. 227 galera ingen 1 kerner 13,033900% CPU-udnyttelse 0,543209G ledig hukommelse, 0,053596MB/s net TX+RX, Op og køre10.0.0.228 galera ingen 1-kerner 12.929100% CPU-udnyttelse, 8MB 509100% CPU-udnyttelse, 8MB509. af net TX+RX, Op og køre10.0.0.226 proxysql 1 kerner 13,823200% CPU-udnyttelse 0,503227G ledig hukommelse, 0,061036MB/s net TX+RX, Process 'proxysql' kører.10.0.01 core none2. 13,104700% CPU-udnyttelse 0,544048G ledig hukommelse, 0,045713MB/s netto TX+RX, Igangværende 10.0.0.229 mysql master 1 kerner 11.107300% CPU-udnyttelse 0.575871G 0.575871G netto 0.575871G 0.03RX 0.0MB netto hukommelse , Op og køre10.0.0.230 mysql slave 1 kerner 9,861590 % CPU-udnyttelse 0,580315G fre e hukommelse, 0,035451 MB/s net TX+RX, oppe og køre 

Med det, vi har vist her, kan du sikkert forestille dig nogle sager til automatisering. For eksempel kan du se CPU-udnyttelsen af ​​noderne, og hvis den når en tærskel, kan du udføre et andet s9s-job for at spinne en ny node op i Galera-klyngen. Du kan også for eksempel overvåge hukommelsesudnyttelsen og sende advarsler, hvis den overskrider en tærskel.

CLI kan mere end det. Først og fremmest er det muligt at kontrollere graferne inde fra kommandolinjen. Selvfølgelig er de ikke så funktionelle som grafer i GUI, men nogle gange er det nok bare at se en graf for at finde et uventet mønster og afgøre, om det er værd at undersøge nærmere.

[email protected]:~# s9s node --stat --cluster-id=1 --begin="00:00" --end="14:00" --graph=load 10.0 .0.231 
[email protected]:~# s9s node --stat --cluster- id=1 --begin="00:00" --end="14:00" --graph=sqlqueries 10.0.0.231 

I nødsituationer vil du måske kontrollere ressourceudnyttelsen på tværs af klyngen. Du kan oprette et top-lignende output, der kombinerer data fra alle klynge noder:

[email protected]:~# s9s proces --top --cluster-id=1PXC_Cluster_57 - 14:38:01 Alle noder er operationelle.4 værter, 7 kerner, 2.2 us, 3.1 sy, 94.7 id, 0,0 wa, 0,0 st, GiB Mem :2,9 i alt, 0,2 gratis, 0,9 brugt, 0,2 buffere, 1,6 cachelagretGiB Swap:3 i alt, 0 brugt, 3 gratis, PID BRUGERVÆRT PR VIRT RES S %CPU %MEM KOMMANDO 8331 10.0.2.15 20 743748 40948 S 10.28 5,40 CMON26479 ROOT 10.0.0.226 20 278532 6448 S 2,49 0,85 Regnskabsdemon 5466 ROOT 10.0.0.226 20 95372 7132 R 1.72 0.94 SSHD 651 ROOT 10.0.0.0.0 root 10.0.0.228 20 278304 6052 S 1,35 0,80 accounts-daemon22447 n/a 10.0.0.226 20 2744444 148820 S 1,20 19,63 mysq. 5212 S 1.18 15.20 mysqld13691 n/a 10.0.0.227 20 2734104 130568 S 1.11 17.22 mysqld22994 root 10.0.2.15 20 30400 9312 S 0.93 1.23 s9s 9115 root 10.0.0.227 20 95368 7192 S 0.68 0.95 sshd23768 root 10.0.0.228 20 95372 7160 S 0.67 0,94 SSHD15690 MySQL 10.0.2.15 20 1102012 209056 S 0.67 27.58 MySQLD11471 ROOT 10.0.0.226 20 95372 7392 S 0.17 0.98 SSHD22086 Vagrant 10.0.2.15 20 95372 4960 S 0,17 2 9003 rod 10.0.0.226 20 0 0 S 0.09 0.00 kworker/u4:1 1195 rod 10.0.0.227 20 0 0 S 0.09 0.00 kworker/u4:027204 rod 010.07 rod 010. 9. rod 010. 10.0.0.227 20 0 0 S 0,09 0,00 kworker/u4:216181 rod 10.0.0.228 20 0 0 S 0,08 0,00 kworker/u4:1 1744 rod 10.0.0.22 8 20 0 0 S 0,08 0,00 KWORERER/1:128506 ROOT 10.0.0.228 20 95372 7348 S 0,08 0,97 SSHD 691 MessageBUS 10.0.0.228 20 42896 3872 S 0,08 0,51 DBUS-DAemon11892 ROOT 10.0.2.15 20 0 0 S 0,08 08 0,51 DBUS-DAemon11892 ROOT 10.0.2.15 20 0 0 S.08 KWARKER/KWARREER :215609 ROOT 10.0.2.15 20 403548 12908 S 0,08 1,70 APACHE2 256 ROOT 10.0.2.15 20 0 0 S 0,08 0,00 JBD2/DM-0-8 840 ROOT 10.0.2.15 20 316200 1308 S 0,08 0,17 VBOXSERVICES14694 ROOT 10.0 S 0.00 0.95 sshd12724 n/a 10.0.0.227 20 4508 1780 S 0.00 0.23 mysqld_safe10974 root 10.0.0.227 20 95368 7400 S 0.00 0.98 sshd14712 root 10.0.0.227 20 95368 7384 S 0.00 0.97 sshd16952 root 10.0.0.227 20 95368 7344 S 0.00 0.97 sshd17025 root 10.0.0.227 20 95368 7100 S 0,00 0,94 sshd27075 root 10.0.0.227 20 0 0 S 0,00 0,00 kworker/u4:127169 r oot 10.0.0.227 20 0 0 S 0.00 0.00 kworker/0:0 881 rod 10.0.0.227 20 37976 760 S 0.00 0.10 rpc.monteret 100 rod 22.00 0 0 0 0 0 0 0 0 0 0 0 100 rod 10,00. 0,00 0,00 bioset11876 rod 10,0,0,227 20 9588 2572 S 0,00 0,34 bash11852 rod 10,0,0,227 20 95368 7352 S 0,00 0,010 værk:0,0 rd 0,010 s . 

Når du kigger på toppen, vil du se CPU- og hukommelsesstatistikker samlet på tværs af hele klyngen.

[email protected]:~# s9s proces --top --cluster-id=1PXC_Cluster_57 - 14:38:01 Alle noder er operationelle.4 værter, 7 kerner, 2.2 us, 3.1 sy, 94.7 id, 0,0 wa, 0,0 st, GiB Mem :2,9 i alt, 0,2 gratis, 0,9 brugt, 0,2 buffere, 1,6 cachelagretGiB Swap:3 i alt, 0 brugt, 3 gratis, 

Nedenfor kan du finde listen over processer fra alle noderne i klyngen.

PID BRUGERVÆRT PR VIRT RES S %CPU %MEM KOMMANDO 8331 root 10.0.2.15 20 743748 40948 S 10.28 5.40 cmon26479 root 10.0.0.226 20 2745 3 mon 2745 30 2745 30 2745 30 2749 30 2749 30 2749 7132 R 1.72 0.94 SSHD 651 ROOT 10.0.0.227 20 278416 6184 S 1.37 0.82 Konto-Daemon 716 ROOT 10.0.0.228 20 278304 6052 S 1.35 0.80 Konto-Demon224447 N/A 10.0.0.0.226 20 2744444444448820 S 1.20 197. 0,228 20 2733624 115212 S 1,18 15,20 mysqld13691 n/a 10.0.0.227 20 2734104 130568 S 1.11 17.22 mysqld

Dette kan være yderst nyttigt, hvis du har brug for at finde ud af, hvad der forårsager belastningen, og hvilken knude der er mest berørt.

Forhåbentlig gør CLI-værktøjet det nemmere for dig at integrere ClusterControl med eksterne scripts og infrastruktur-orkestreringsværktøjer. Vi håber, du vil nyde at bruge dette værktøj, og hvis du har feedback om, hvordan du kan forbedre det, er du velkommen til at fortælle os det.


  1. Hvordan deaktiverer jeg midlertidigt triggere i PostgreSQL?

  2. TIMESTAMPADD() Eksempler – MySQL

  3. Endnu et argument for lagrede procedurer

  4. TSQL - Hvordan bruger man GO inde i en BEGIN .. END blok?