sql >> Database teknologi >  >> RDS >> PostgreSQL

Sådan overvåger du PostgreSQL 12-ydelse med OmniDB – del 1

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 ~/.omnidbdrwxr-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.


  1. 2 måder at oprette en tabel på en sammenkædet server ved hjælp af T-SQL

  2. PHP:Advarsel:sort() forventer, at parameter 1 er array, ressource givet

  3. Der opstod en netværksrelateret eller instansspecifik fejl under oprettelse af en forbindelse til SQL Server

  4. MariaDB Server Database Encryption Basics