OmniDB är ett grafiskt databashanteringsverktyg med öppen källkod utvecklat av 2ndQuadrant, en världsledande inom PostgreSQL-teknologier och tjänster. OmniDB är ett webbläsarbaserat, universellt klientverktyg som kan hantera stora databasmotorer som PostgreSQL, MariaDB, MySQL och Oracle. Andra motorer som snart kommer att stödjas inkluderar SQLite, Firebird, MS SQL Server och IBM DB2.
Liksom vilken utmärkt databasklientmjukvara som helst, ger OmniDB också användarna några fantastiska funktioner. Dessa inkluderar möjligheten att skapa och anpassa instrumentpaneler för övervakning av databasprestanda. I denna tvådelade artikelserie kommer vi att lära oss hur man använder OmniDB:s inbyggda övervakningsenheter – allmänt kända som "widgets" i instrumentpanelstermer – för att bygga kontrollpaneler för prestandahälsokontroll för ett PostgreSQL 12-replikeringskluster.
Testmiljön
Vår testmiljö är ett PostgreSQL 12-kluster med två noder, som körs i en AWS VPC i us-east-1-regionen. VPC:n sträcker sig över tre tillgänglighetszoner och har tre subnät. Varje undernät finns i en separat tillgänglighetszon (AZ). Den primära noden och standbynoden finns i två av dessa undernät. Noderna är båda av t2.large EC2-instanstyp och kommer att köra postgreSQL 12 med öppen källkod. Den primära noden kommer att replikera till standbynoden.
Det kommer också att finnas en "övervakningsnod" som kör den senaste versionen av 2ndQuadrants OmniDB-databashanteringsverktyg. Denna nod kommer inte att vara en del av PostgreSQL-klustret, utan kommer att vara värd i det tredje subnätet av VPC, i en annan A-Ö. OmniDB kommer att kunna ansluta till både mastern och standbynoden och kontrollera deras prestanda. OmniDB-noden kommer att vara en t2.medium EC2-instans.
Alla tre noderna kommer att köra Red Hat Enterprise Linux (RHEL) 8. Bilden nedan visar den förenklade arkitekturen:
Testscenariot
När vi väl har konfigurerat klustret och OmniDB kommer vi att registrera båda PostgreSQL-noderna i OmniDB. Vi kommer sedan att bekanta oss med några av standardövervakningsenheterna i OmniDB och se prestandamått från båda klusternoderna. Vi kommer sedan att köra ett belastningstest i den primära noden med hjälp av pgbench. Helst bör belastningstestet initieras från en separat maskin, men i det här fallet kommer vi att köra det lokalt. Vi kommer sedan att se hur OmniDB:s övervakningspanel visar förändringarna i olika prestandaräknare när belastningen ändras.
Konfigurera miljön
Steg 1:Installera ett PostgreSQL 12-replikeringskluster
För att skapa ett PostgreSQL-kluster med två noder följer vi stegen som beskrivs i en tidigare publicerad 2ndQuadrant-blogg. Läsaren kan läsa den här artikeln för att se hur vi installerade ett trenodskluster med en vittnesnod med en annan 2ndQuadrant-produkt som heter repmgr . För vår nuvarande inställning följer vi samma steg med repmgr för att skapa ett kluster med två noder istället för ett med tre noder. Replikeringsklustret kommer inte heller att ha någon vittnesnod. För att göra det enkelt visar den här artikeln inte de detaljerade installations- och konfigurationsstegen.
När vårt kluster väl är konfigurerat kan vi bekräfta att det fungerar genom att fråga pg_stat_replikeringsvyn från den primära noden:
SELECT usename, client_addr, application_name, state, sent_lsn, write_lsn,replay_lsn FROM pg_stat_replication;
Steg 2:Installera och konfigurera en OmniDB-server
OmniDB nås med en URL, vilket betyder att bakom scenen kör den en egen webbserver. Det finns två smaker av OmniDB:
- OmniDB Application :Detta körs vanligtvis från en arbetsstation och beter sig som ett vanligt skrivbordsprogram. OmniDB kör webbservern på en slumpmässig port, och det behövs ingen ytterligare installation.
- OmniDB-server :Detta är för att installera OmniDB på en nätverksserver för ett fleranvändarläge. I serverläget kan vi ange portnumret för åtkomst till URL:en, SSL-kryptering av URL:en, lastbalansering och omvänd proxy, SSH-åtkomst till databasnoder och skapa användarkonton för åtkomst.
För vårt testscenario kommer vi att installera en OmniDB-server i OmniDB EC2-noden. Först laddar vi ner det senaste paketet från OmniDB-webbplatsen:
# wget https://www.omnidb.org/dist/2.17.0/omnidb-server_2.17.0-centos7-amd64.rpm
Därefter startar vi installationen. Här installerar vi OmniDB som root-användare, men du kan använda vilken annan användare som helst så länge den har rätt rättigheter:
# rpm -ivh omnidb-server_2.17.0-centos7-amd64.rpm Verifying... ################################# [100%] Preparing... ################################# [100%] Updating / installing... 1:omnidb-server-2.17.0-0 ################################# [100%]
När paketet är installerat kan vi starta OmniDB från kommandotolken:
# omnidb-server
Detta visar att servern startar:
Starting OmniDB websocket... Checking port availability... Starting websocket server at port 25482. Starting OmniDB server... Checking port availability... Starting server OmniDB 2.17.0 at 127.0.0.1:8000. Starting migration of user database from version 0.0.0 to version 2.17.0... OmniDB successfully migrated user database from version 0.0.0 to version 2.17.0 Open OmniDB in your favorite browser Press Ctrl+C to exit
Vi kan se att OmniDB har valt en standardwebserverport på 8000 och en standardwebsocketserver vid port 25482.
Vi trycker på Ctrl+C för att stoppa serverprocessen och bläddra till rotanvändarens hemkatalog. Vi kan se att det finns en dold mapp som heter .omnidb . Under den här mappen finns en underkatalog som heter omnidb-server . Inuti underkatalogen omnidb-server finns det få filer:
# ls -la ~ … drwxr-xr-x. 3 root root 27 Jun 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 root root 1209 Jun 13 02:49 omnidb.conf -rw-r--r--. 1 root root 116736 Jun 13 02:49 omnidb.db -rw-r--r--. 1 root root 0 Jun 13 02:49 omnidb.db.bak_2.17.0 -rw-r--r--. 1 root root 579 Jun 13 02:49 omnidb.log
När serverprocessen startar, initierar OmniDB dessa filer. OmniDB-metadatadatabasen heter omnidb.db . Detta är en SQLite-databas och innehåller information om databasanslutningar, OmniDB-användare och så vidare. omnidb.conf filen innehåller konfigurationsalternativ för OmniDB-servern. Om vi öppnar den här filen i en editor ser den ut så här:
# OmniDB Server configuration file [webserver] # What address the webserver listens to, 0.0.0.0 listens to all addresses bound to the machine listening_address = 127.0.0.1 # Webserver port, if port is in use another random port will be selected listening_port = 8000 # Websocket port, if port is in use another random port will be selected websocket_port = 25482 # External Websocket port, use this parameter if OmniDB isn't directly visible by the client # external_websocket_port = 25482 # Security parameters # is_ssl = True requires ssl_certificate_file and ssl_key_file parameters # This is highly recommended to protect information is_ssl = False ssl_certificate_file = /path/to/cert_file ssl_key_file = /path/to/key_file # Trusted origins, use this parameter if OmniDB is configured with SSL and is being accessed by another domain csrf_trusted_origins = origin1,origin2,origin3 # Url path to access OmniDB, default is empty path = [queryserver] # Max number of threads that can used by each advanced object search request thread_pool_max_workers = 2 # Number of seconds between each prompt password request. Default: 30 minutes pwd_timeout_total = 1800
OmniDB kör två serverprocesser. Den ena är en webbserver som visar användargränssnittet, den andra är websocket-servern. Websocket-servern används av flera funktioner i programmet, som fråga, konsol och felsökning.
Från konfigurationsfilen kan vi se att OmniDB-servern som standard accepterar lokal trafik (127.0.0.1) på webbserverport 8000. Vi kommer att ändra detta till ALLA IP-adresser. Om inte maskinen ligger bakom en omvänd proxy, rekommenderas det starkt att använda SSL-kryptering för HTTP-anslutningar till servern. I vårt exempel kommer vi dock att lämna is_ssl parametern till "False" eftersom vi kommer att riva den här maskinen när våra tester är klara. Vi kommer också att ändra webbserverporten till 8080 och hålla websocketserverporten till dess standardvärde på 25482.
När ändringar har gjorts, bör konfigurationsfilen se ut så här:
[webserver] listening_address = 0.0.0.0 listening_port = 8080 websocket_port = 25482 is_ssl = False ssl_certificate_file = /path/to/cert_file ssl_key_file = /path/to/key_file csrf_trusted_origins = origin1,origin2,origin3 path = [queryserver] thread_pool_max_workers = 2 pwd_timeout_total = 1800
Med ändringarna gjorda och sparade kör vi en annan applikation som heter omnidb-config-server . Det här verktyget kan användas för att utföra extra konfigurationer som:
- Dammsuga SQLite-databasen OmniDB-databasen
- Återställ den gamla databasen och skapa en ny
- Ta bort tillfälliga filer
- Skapa en ny hemkatalog för databasen och konfigurationsfilen
- Skapa en superanvändare för att logga in på OmniDB
Även om vi kommer att logga in på OmniDB med administratörsanvändarkontot som skapats som standard, kommer vi att skapa ytterligare en superanvändare här. Detta kan vara användbart om vi vill skapa individuella DBA-konton i OmniDB. Utdraget nedan visar detta:
# omnidb-config-server --createsuperuser=dba [email protected]$$w0rd123 Creating superuser... Superuser created.
Med superanvändaren skapad startar vi omnidb-serverprocessen igen:
# omnidb-server Starting OmniDB websocket... Checking port availability... Starting websocket server at port 25482. Starting OmniDB server... Checking port availability... Starting server OmniDB 2.17.0 at 0.0.0.0:8080. User database version 2.17.0 is already matching server version. Open OmniDB in your favorite browser Press Ctrl+C to exit
Innan vi kommer åt OmniDB-gränssnittet lägger vi också till port 8080 och port 25482 till EC2-instansens säkerhetsgrupp:
Steg 3:Åtkomst till OmniDB-gränssnittet
När du bläddrar till den allmänna adressen och OmniDB-noden visas nu inloggningsskärmen:
Vi anger standardanvändarnamnet för "admin" och dess lösenord, "admin". Detta låter oss logga in på huvudgränssnittet för OmniDB. Den första skärmen visas nedan:
Därefter klickar vi på ikonen "Hantera användare" i det övre högra hörnet av skärmen:
Och ändra standardlösenordet för administratörsanvändaren:
När det är klart klickar vi på knappen "Spara data" för att uppdatera lösenordet. Som du kan se kan vi också skapa nya användare från den här skärmen.
Från det övre vänstra hörnet på skärmen klickar vi på länken "Anslutningar" och sedan från den resulterande dialogrutan klickar du på knappen "Ny anslutning":
Vi anger sedan anslutningsdetaljerna för den primära PostgreSQL-noden och klickar på knappen "Spara data":
När anslutningen har sparats klickar vi på anslutningsikonen (grön bock) från kolumnen "Åtgärder".
Detta öppnar en ny flik som visar databasanslutningen. Som visas här är vi anslutna till den primära PostgreSQL-noden här:
Vi följer samma process för att registrera standbynoden:
Steg 4:Återställ en exempeldatabas
Vi återställer nu en exempeldatabas i den primära PostgreSQL-instansen. Denna databas kallas "DVDRental" och den är fritt nedladdningsbar från PostgreSQL Tutorial-webbplatsen. Vi har packat upp den nedladdade filen och extraherat källfilerna till en underkatalog under /tmp-mappen för den primära noden:
[[email protected] dvdrental] # ls -la total 2796 drwxr-xr-x. 2 root root 280 Jun 16 11:32 . drwxrwxrwt. 9 root root 257 Jun 16 11:31 .. -rw-------. 1 postgres postgres 57147 May 12 2019 3055.dat -rw-------. 1 postgres postgres 8004 May 12 2019 3057.dat -rw-------. 1 postgres postgres 483 May 12 2019 3059.dat -rw-------. 1 postgres postgres 333094 May 12 2019 3061.dat -rw-------. 1 postgres postgres 149469 May 12 2019 3062.dat -rw-------. 1 postgres postgres 26321 May 12 2019 3063.dat -rw-------. 1 postgres postgres 46786 May 12 2019 3065.dat -rw-------. 1 postgres postgres 21762 May 12 2019 3067.dat -rw-------. 1 postgres postgres 3596 May 12 2019 3069.dat -rw-------. 1 postgres postgres 140422 May 12 2019 3071.dat -rw-------. 1 postgres postgres 263 May 12 2019 3073.dat -rw-------. 1 postgres postgres 718644 May 12 2019 3075.dat -rw-------. 1 postgres postgres 1214420 May 12 2019 3077.dat -rw-------. 1 postgres postgres 271 May 12 2019 3079.dat -rw-------. 1 postgres postgres 57 May 12 2019 3081.dat -rw-------. 1 postgres postgres 45872 May 12 2019 restore.sql -rw-------. 1 postgres postgres 55111 May 12 2019 toc.dat
Därefter kör vi följande skalkommandon i den primära PostgreSQL-instansen (PG-Node1). Dessa kommandon gör några ändringar i filen restore.sql:
- Ta bort alla förekomster av "$$PATH$$/". Detta säkerställer att skriptet kan hitta alla datafiler i samma katalog
- Ändra alla förekomster av "English_United States.1252" till "en_US.UTF-8". Detta säkerställer att det inte finns några fel på grund av att språket saknas när skriptet körs.
- Ändra kommandot "DROP DATBASE dvdrental" till "DROP DATBASE IF EXISTS dvdrental", så att inget ogiltigt databasfel dyker upp.
# 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 IF EXISTS dvdrental;/g' /tmp/dvdrental/restore.sql
Därefter byter vi till postgres-användaren och kör följande kommando från skalprompten:
$ psql -U postgres -d postgres -f /tmp/dvdrental/restore.sql
Detta återställer exempeldatabasen i den primära noden. Om vi kollar från OmniDB kan vi se att databasen är skapad:
Slutsats
Vi har nu ett fullt fungerande PostgreSQL-kluster och en OmniDB-instans som körs i AWS. OmniDB kan ansluta till båda noderna i klustret. Vi har också återställt en databas i den primära noden som replikeras till standby.
Miljöinställningen är nu klar. I den andra delen av den här artikeln kommer vi att börja skapa en prestandaövervakningsinstrumentpanel för den primära instansen.