OmniDB er et open source, grafisk databasestyringsværktøj udviklet af 2ndQuadrant, en verdensledende inden for PostgreSQL-teknologier og -tjenester. OmniDB er et browserbaseret, universelt klientværktøj, der kan administrere store databasemotorer som PostgreSQL, MariaDB, MySQL og Oracle. Andre motorer, der snart vil blive understøttet, omfatter SQLite, Firebird, MS SQL Server og IBM DB2.
Som enhver fremragende databaseklientsoftware giver OmniDB også brugerne nogle fantastiske funktioner. Disse omfatter muligheden for at oprette og tilpasse dashboards til overvågning af databaseydeevne. I denne artikelserie i to dele vil vi lære, hvordan man bruger OmniDBs indbyggede overvågningsenheder – almindeligvis kendt som "widgets" i dashboard-termer – til at bygge dashboards til kontrol af ydeevnesundhed til en PostgreSQL 12 replikeringsklynge.
Testmiljøet
Vores testmiljø er en to-node PostgreSQL 12-klynge, der kører i en AWS VPC i us-east-1-regionen. VPC'en spænder over tre tilgængelighedszoner og har tre undernet. Hvert undernet er i en separat tilgængelighedszone (AZ). Den primære og standby-knuden er placeret i to af disse undernet. Noderne er både t2.large EC2-instanstypen og vil køre open source PostgreSQL 12. Den primære node vil replikere til standby-knuden.
Der vil også være en "overvågningsknude", der kører den seneste version af 2ndQuadrants OmniDB-databasestyringsværktøj. Denne node vil ikke være en del af PostgreSQL-klyngen, men vil blive hostet i det tredje undernet af VPC, i en anden AZ. OmniDB vil være i stand til at oprette forbindelse til både master- og standby-knuden og kontrollere deres ydeevne. OmniDB-knuden vil være en t2.medium EC2-instans.
Alle tre noder vil køre Red Hat Enterprise Linux (RHEL) 8. Billedet nedenfor viser den forenklede arkitektur:
Testscenariet
Når vi har sat klyngen og OmniDB op, vil vi registrere begge PostgreSQL-noder i OmniDB. Vi vil derefter stifte bekendtskab med nogle af standardovervågningsenhederne i OmniDB og se ydeevnemålinger fra begge klyngens noder. Vi vil derefter køre en belastningstest i den primære node ved hjælp af pgbench. Ideelt set bør belastningstesten startes fra en separat maskine, men i dette tilfælde kører vi den lokalt. Vi vil derefter se, hvordan OmniDBs overvågningsdashboard viser ændringerne i forskellige ydeevnetællere, efterhånden som belastningen ændres.
Opsætning af miljøet
Trin 1:Installation af en PostgreSQL 12-replikeringsklynge
For at oprette en to-node PostgreSQL-klynge følger vi trinene beskrevet i en tidligere offentliggjort 2ndQuadrant-blog. Læseren kan tjekke denne artikel for at se, hvordan vi installerede en tre-node-klynge med en vidne-node ved hjælp af et andet 2ndQuadrant-produkt kaldet repmgr . For vores nuværende opsætning følger vi de samme trin ved at bruge repmgr til at oprette en to-node-klynge i stedet for en tre-node. Replikeringsklyngen vil heller ikke have nogen vidneknude. For at gøre tingene enkle viser denne artikel ikke de detaljerede installations- og konfigurationstrin.
Når vores klynge er konfigureret, kan vi bekræfte, at den fungerer ved at forespørge pg_stat_replication view fra den primære node:
VÆLG brugsnavn, client_addr, application_name, state, sent_lsn, write_lsn,replay_lsnFROM pg_stat_replication;
Trin 2:Installation og konfiguration af en OmniDB-server
OmniDB tilgås ved hjælp af en URL, hvilket betyder, at den bag scenen kører en egen webserver. Der er to varianter af OmniDB:
- OmniDB-applikation :Dette køres typisk fra en arbejdsstation og opfører sig som et normalt skrivebordsprogram. OmniDB kører webserveren på en tilfældig port, og der er ingen yderligere opsætning nødvendig.
- OmniDB-server :Dette er til installation af OmniDB på en netværksserver til en flerbrugertilstand. I servertilstanden kan vi angive portnummeret for adgang til URL'en, SSL-kryptering af URL'en, belastningsbalancering og omvendt proxy, SSH-passthrough-adgang til databasenoder og oprettelse af brugerkonti til adgang.
Til vores testscenarie vil vi installere en OmniDB-server i OmniDB EC2-noden. Først downloader vi den seneste pakke fra OmniDB-webstedet:
# wget https://www.omnidb.org/dist/2.17.0/omnidb-server_2.17.0-centos7-amd64.rpm
Dernæst starter vi installationen. Her installerer vi OmniDB som root-bruger, men du kan bruge enhver anden bruger, så længe den har de korrekte rettigheder:
# rpm -ivh omnidb-server_2.17.0-centos7-amd64.rpmVerificerer... ############################ #### [100%]Forbereder... ############################### [100%]Opdaterer / installerer... 1:omnidb-server-2.17.0-0 ####################################### 100 %]
Når pakken er installeret, kan vi starte OmniDB fra kommandoprompten:
# omnidb-server
Dette viser serveren, der starter:
Starter OmniDB websocket...Kontrollerer porttilgængelighed...Starter websocketserver ved port 25482 .Starter OmniDB-server...Kontrollerer porttilgængelighed...Starter server OmniDB 2.17.0 på 127.0.0.1:8000 .Starter migrering af brugerdatabase fra version 0.0.0 til version 2.17.0...OmniDB migrerede med succes brugerdatabase fra version 0.0.0 til version 2.17.0Åbn OmniDB i din yndlingsbrowserTryk på Ctrl+C for at afslutte
Vi kan se, at OmniDB har valgt en standard webserverport på 8000 og en standard websocket-server ved port 25482.
Vi trykker på Ctrl+C for at stoppe serverprocessen og browse til rodbrugerens hjemmebibliotek. Vi kan se, at der er en skjult mappe ved navn .omnidb . Under denne mappe er der en undermappe kaldet omnidb-server . Inde i undermappen omnidb-server er der få filer:
# ls -la ~ …drwxr-xr-x. 3 root root 27. juni 13 02:49 .omnidb ……# ls -la ~/.omnidb …drwxr-xr-x. 2 root root 106 Jun 13 02:49 omnidb-server # ls -la ~/.omnidb/omnidb-server/ …-rw-r--r--. 1 root root 131072 Jun 13 02:49 db.sqlite3-rw-r--r--. 1 rodrod 1209 Jun 13 02:49 omnidb.conf -rw-r--r--. 1 rodrod 116736 Jun 13 02:49 omnidb.db -rw-r--r--. 1 rodrod 0 13. juni 02:49 omnidb.db.bak_2.17.0-rw-r--r--. 1 rodrod 579 Jun 13 02:49 omnidb.log
Når serverprocessen starter, initialiserer OmniDB disse filer. OmniDB-metadatadatabasen hedder omnidb.db . Dette er en SQLite-database og indeholder oplysninger om databaseforbindelser, OmniDB-brugere og så videre. omnidb.conf filen indeholder konfigurationsmuligheder for OmniDB-serveren. Hvis vi åbner denne fil i en editor, ser den sådan ud:
# OmniDB Server-konfigurationsfil[webserver]# Hvilken adresse webserveren lytter til, 0.0.0.0 lytter til alle adresser, der er bundet til maskinenlistening_address =127.0.0.1 # Webserverport, hvis porten er i brug, vil en anden tilfældig port blive valgtlytteport =8000 # Websocket-port, hvis porten er i brug, vil en anden tilfældig port blive valgtwebsocket_port =25482 # Ekstern Websocket-port, brug denne parameter, hvis OmniDB ikke er direkte synlig af klienten# external_websocket_port =25482# Security parameters# is_ssl =True kræver ssl_certificate_file og ssl_key_file parameters# Dette anbefales stærkt for at beskytte informationis ss = l b> ssl_certificate_file =/sti/til/certifikatfil ssl_key_file =/path/to/key_file # Trusted origins, brug denne parameter, hvis OmniDB er konfigureret med SSL og tilgås af et andet domaincsrf_trusted_origins =origin1,origin2,origin3# URL-sti til adgang til OmniDB, standard er tomsti = [queryserver]# Maks. antal tråde, der kan bruges af hver avanceret objektsøgningsanmodningthread_pool_max_workers =2 # Antal sekunder mellem hver anmodning om adgangskode. Standard:30 minutterpwd_timeout_total =1800
OmniDB kører to serverprocesser. Den ene er en webserver, der viser brugergrænsefladen, den anden er websocket-serveren. Websocket-serveren bruges af flere funktioner i applikationen, såsom forespørgsel, konsol og debugging.
Fra konfigurationsfilen kan vi se, at OmniDB-serveren som standard accepterer lokal trafik (127.0.0.1) på webserverport 8000. Vi ændrer dette til ALLE IP-adresser. Medmindre maskinen er bag en omvendt proxy, anbefales det stærkt at bruge SSL-kryptering til HTTP-forbindelser til serveren. I vores eksempel vil vi dog forlade is_ssl parameter til "False", fordi vi vil rive denne maskine ned, når vores test er færdig. Vi vil også ændre webserverporten til 8080 og beholde websocketserverporten til standardværdien 25482.
Når først ændringer er foretaget, skal konfigurationsfilen se sådan ud:
meget>Med ændringerne foretaget og gemt, kører vi et andet program kaldet omnidb-config-server . Dette værktøj kan bruges til at udføre nogle ekstra konfigurationer såsom:
- Støvsugning af SQLite-databasen OmniDB-databasen
- Nulstil den gamle database, og opret en ny
- Slet midlertidige filer
- Opret en ny hjemmemappe til databasen og konfigurationsfilen
- Opret en superbruger til at logge på OmniDB
Selvom vi vil logge ind på OmniDB ved hjælp af den admin-brugerkonto, der er oprettet som standard, vil vi oprette en anden superbruger her. Dette kan være nyttigt, hvis vi ønsker at oprette individuelle DBA-konti i OmniDB. Uddraget nedenfor viser dette:
# omnidb-config-server --createsuperuser=dba [email protected]$$w0rd123Opretter superbruger...Superbruger oprettet.
Med superbrugeren oprettet starter vi omnidb-server processen igen:
# omnidb-server Starter OmniDB websocket...Kontrollerer porttilgængelighed...Starter websocketserver ved port 25482.Starter OmniDB-server...Kontrollerer porttilgængelighed...Starter server OmniDB 2.17.0 ved 0.0.0.0:8080. Brugerdatabaseversion 2.17.0 matcher allerede serverversion. Åbn OmniDB i din yndlingsbrowserTryk på Ctrl+C for at afslutte
Før vi får adgang til OmniDB-grænsefladen, tilføjer vi også port 8080 og port 25482 til EC2-instansens sikkerhedsgruppe:
Trin 3:Adgang til OmniDB-grænsefladen
Når du gennemser den offentlige adresse og OmniDB-knudepunktet, vises login-skærmen:
Vi angiver standardbrugernavnet for "admin" og dets adgangskode, "admin". Dette lader os logge ind på hovedomniDB-grænsefladen. Det første skærmbillede vises nedenfor:
Dernæst klikker vi på ikonet "Administrer brugere" i øverste højre hjørne af skærmen:
Og skift standardadgangskoden for administratorbrugeren:
Når det er gjort, klikker vi på knappen "Gem data" for at opdatere adgangskoden. Som du kan se, kan vi også oprette nye brugere fra denne skærm.
Fra øverste venstre hjørne af skærmen klikker vi på linket "Forbindelser", og klik derefter på knappen "Ny forbindelse" fra den resulterende dialogboks:
Vi angiver derefter forbindelsesdetaljerne for den primære PostgreSQL-node og klikker på knappen "Gem data":
Når forbindelsen er gemt, klikker vi på forbindelsesikonet (grønt flueben) fra kolonnen "Handlinger".
Dette åbner en ny fane, der viser databaseforbindelsen. Som vist her, er vi forbundet til den primære PostgreSQL-node her:
Vi følger samme proces for at registrere standby-knuden:
Trin 4:Gendannelse af en prøvedatabase
Vi gendanner nu en prøvedatabase i den primære PostgreSQL-instans. Denne database kaldes "DVDRental", og den kan frit downloades fra PostgreSQL Tutorial-webstedet. Vi har pakket den downloadede fil ud og pakket kildefilerne ud i en undermappe under mappen /tmp i den primære node:
[[email protected] dvdrental] # ls -latotal 2796drwxr-xr-x. 2 root root 280 Jun 16 11:32 .drwxrwxrwt. 9 root root 257 16. juni 11:31 ..-rw-------. 1 postgres postgres 57147 12. maj 2019 3055.dat-rw-------. 1 postgres postgres 8004 12. maj 2019 3057.dat-rw-------. 1 postgres postgres 483 12. maj 2019 3059.dat-rw-------. 1 postgres postgres 333094 12. maj 2019 3061.dat-rw-------. 1 postgres postgres 149469 12. maj 2019 3062.dat-rw-------. 1 postgres postgres 26321 12. maj 2019 3063.dat-rw-------. 1 postgres postgres 46786 12. maj 2019 3065.dat-rw-------. 1 postgres postgres 21762 12. maj 2019 3067.dat-rw-------. 1 postgres postgres 3596 12. maj 2019 3069.dat-rw-------. 1 postgres postgres 140422 12. maj 2019 3071.dat-rw-------. 1 postgres postgres 263 12. maj 2019 3073.dat-rw-------. 1 postgres postgres 718644 12. maj 2019 3075.dat-rw-------. 1 postgres postgres 1214420 12. maj 2019 3077.dat-rw-------. 1 postgres postgres 271 12. maj 2019 3079.dat-rw-------. 1 postgres postgres 57. 12. maj 2019 3081.dat-rw-------. 1 postgres postgres 45872 12. maj 2019 restore.sql-rw-------. 1 postgres postgres 55111 12. maj 2019 toc.dat
Dernæst kører vi følgende shell-kommandoer i den primære PostgreSQL-instans (PG-Node1). Disse kommandoer foretager nogle ændringer i filen restore.sql:
- Fjern alle forekomster af "$$PATH$$/". Dette sikrer, at scriptet kan finde alle datafilerne i den samme mappe
- Rediger alle forekomster af "English_United States.1252" til "en_US.UTF-8". Dette sikrer, at der ikke er fejl på grund af en manglende lokalitet, når scriptet kører.
- Skift kommandoen "DROP DATBASE dvdrental" til "DROP DATBASE IF EXISTS dvdrental", så der ikke vises nogen ugyldig databasefejl.
# sed -i 's/$$PATH$$\//\/tmp\/dvdrental\//g' /tmp/dvdrental/restore.sql# sed -i 's/English_United States.1252/en_US .UTF-8/g' /tmp/dvdrental/restore.sql# sed -i 's/DROP DATABASE dvdrental;/DROP DATABASE HVIS FINDER dvdrental;/g' /tmp/dvdrental/restore.sql
Dernæst skifter vi til postgres-brugeren og kører følgende kommando fra shell-prompten:
$ psql -U postgres -d postgres -f /tmp/dvdrental/restore.sql
Dette gendanner prøvedatabasen i den primære node. Hvis vi tjekker fra OmniDB, kan vi se, at databasen er oprettet:
Konklusion
Vi har nu en fuldt fungerende PostgreSQL-klynge og en OmniDB-instans, der kører i AWS. OmniDB kan oprette forbindelse til begge klyngens noder. Vi har også gendannet en database i den primære node, som bliver replikeret til standby.
Opsætningen af miljøet er nu færdig. I anden del af denne artikel vil vi begynde at oprette et betjeningspanel for ydeevneovervågning for den primære forekomst.