OmniDB is een open-source, grafische tool voor databasebeheer, ontwikkeld door 2ndQuadrant, een wereldleider in PostgreSQL-technologieën en -services. OmniDB is een browsergebaseerde, universele clienttool die grote database-engines zoals PostgreSQL, MariaDB, MySQL en Oracle kan beheren. Andere binnenkort ondersteunde engines zijn SQLite, Firebird, MS SQL Server en IBM DB2.
Zoals elke uitstekende databaseclientsoftware, biedt OmniDB gebruikers ook enkele geweldige functies. Deze omvatten de mogelijkheid om dashboards voor het bewaken van databaseprestaties te maken en aan te passen. In deze tweedelige serie artikelen leren we hoe we de ingebouwde controle-eenheden van OmniDB - in dashboardtermen algemeen bekend als 'widgets' - kunnen gebruiken om dashboards voor prestatiecontrole te bouwen voor een PostgreSQL 12-replicatiecluster.
De testomgeving
Onze testomgeving is een PostgreSQL 12-cluster met twee knooppunten, die wordt uitgevoerd in een AWS VPC in de us-east-1-regio. De VPC strekt zich uit over drie beschikbaarheidszones en heeft drie subnetten. Elk subnet bevindt zich in een afzonderlijke Beschikbaarheidszone (AZ). Het primaire en het standby-knooppunt bevinden zich in twee van deze subnetten. De knooppunten zijn beide van het type t2.large EC2 en zullen open-source PostgreSQL 12 uitvoeren. Het primaire knooppunt wordt gerepliceerd naar het stand-by-knooppunt.
Er zal ook een "bewakingsknooppunt" zijn waarop de nieuwste versie van de OmniDB-databasebeheertool van 2ndQuadrant wordt uitgevoerd. Dit knooppunt maakt geen deel uit van het PostgreSQL-cluster, maar wordt gehost in het derde subnet van de VPC, in een andere AZ. OmniDB kan verbinding maken met zowel de master- als de standby-node en hun prestaties controleren. Het OmniDB-knooppunt is een t2.medium EC2-instantie.
Op alle drie de nodes wordt Red Hat Enterprise Linux (RHEL) 8 uitgevoerd. De onderstaande afbeelding toont de vereenvoudigde architectuur:
Het testscenario
Zodra we het cluster en OmniDB hebben ingesteld, registreren we beide PostgreSQL-knooppunten in OmniDB. We zullen dan vertrouwd raken met enkele van de standaard bewakingseenheden in OmniDB en prestatiestatistieken van beide clusterknooppunten bekijken. We zullen dan een belastingstest uitvoeren in het primaire knooppunt met behulp van pgbench. Idealiter zou de belastingstest moeten worden gestart vanaf een afzonderlijke machine, maar in dit geval zullen we deze lokaal uitvoeren. We zullen dan zien hoe het monitoringdashboard van OmniDB de wijzigingen in verschillende prestatiemeteritems laat zien als de belasting verandert.
De omgeving instellen
Stap 1:Een PostgreSQL 12-replicatiecluster installeren
Om een PostgreSQL-cluster met twee knooppunten te maken, volgen we de stappen die zijn beschreven in een eerder gepubliceerde 2ndQuadrant-blog. De lezer kan dit artikel lezen om te zien hoe we een cluster met drie knooppunten en een getuigenknooppunt hebben geïnstalleerd met behulp van een ander 2ndQuadrant-product met de naam repmgr . Voor onze huidige configuratie volgen we dezelfde stappen met behulp van repmgr om een cluster met twee knooppunten te maken in plaats van een cluster met drie knooppunten. Het replicatiecluster heeft ook geen getuigenknooppunt. Om het simpel te houden, toont dit artikel niet de gedetailleerde installatie- en configuratiestappen.
Zodra ons cluster is ingesteld, kunnen we bevestigen dat het functioneert door de pg_stat_replication-weergave op te vragen vanaf het primaire knooppunt:
SELECT usename, client_addr, application_name, state, sent_lsn, write_lsn,replay_lsn FROM pg_stat_replication;
Stap 2:Een OmniDB-server installeren en configureren
OmniDB is toegankelijk via een URL, wat betekent dat het achter de schermen een eigen webserver heeft. Er zijn twee smaken van OmniDB:
- OmniDB-toepassing :Dit wordt meestal uitgevoerd vanaf een werkstation en gedraagt zich als een normale desktoptoepassing. OmniDB draait de webserver op een willekeurige poort en er is geen extra installatie nodig.
- OmniDB-server :Dit is voor het installeren van OmniDB op een netwerkserver voor een modus voor meerdere gebruikers. In de servermodus kunnen we het poortnummer specificeren voor toegang tot de URL, SSL-codering van de URL, taakverdeling en reverse proxy, SSH-passthrough-toegang tot databaseknooppunten en het maken van gebruikersaccounts voor toegang.
Voor ons testscenario zullen we een OmniDB-server installeren in de OmniDB EC2-node. Eerst downloaden we het nieuwste pakket van de OmniDB-site:
# wget https://www.omnidb.org/dist/2.17.0/omnidb-server_2.17.0-centos7-amd64.rpm
Vervolgens starten we de installatie. Hier installeren we OmniDB als rootgebruiker, maar u kunt elke andere gebruiker gebruiken zolang deze de juiste rechten heeft:
# rpm -ivh omnidb-server_2.17.0-centos7-amd64.rpm Verifying... ################################# [100%] Preparing... ################################# [100%] Updating / installing... 1:omnidb-server-2.17.0-0 ################################# [100%]
Zodra het pakket is geïnstalleerd, kunnen we OmniDB starten vanaf de opdrachtprompt:
# omnidb-server
Dit toont de server die start:
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
We kunnen zien dat OmniDB een standaard webserverpoort van 8000 heeft gekozen en een standaard websocketserver op poort 25482.
We drukken op Ctrl+C om het serverproces te stoppen en bladeren naar de homedirectory van de rootgebruiker. We kunnen zien dat er een verborgen map is met de naam .omnidb . Onder deze map bevindt zich een submap met de naam omnidb-server . In de omnidb-server submap zijn er weinig bestanden:
# 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
Zodra het serverproces is gestart, initialiseert OmniDB deze bestanden. De OmniDB-metadatadatabase heet omnidb.db . Dit is een SQLite-database en bevat informatie over databaseverbindingen, OmniDB-gebruikers, enzovoort. De omnidb.conf bestand bevat configuratie-opties voor de OmniDB-server. Als we dit bestand in een editor openen, ziet het er als volgt uit:
# 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 voert twee serverprocessen uit. De ene is een webserver die de gebruikersinterface weergeeft, de andere is de websocket-server. De websocket-server wordt gebruikt door verschillende functies van de applicatie, zoals query's, console en foutopsporing.
Uit het configuratiebestand kunnen we zien dat de OmniDB-server standaard lokaal verkeer (127.0.0.1) op webserverpoort 8000 accepteert. We zullen dit veranderen in ALLE IP-adressen. Tenzij de machine zich achter een reverse proxy bevindt, wordt het ten zeerste aanbevolen om SSL-codering te gebruiken voor HTTP-verbindingen met de server. In ons voorbeeld laten we echter de is_ssl parameter op "Fals" omdat we deze machine zullen afbreken zodra onze tests zijn voltooid. We zullen ook de webserver-poort wijzigen in 8080 en de websocket-serverpoort behouden op de standaardwaarde van 25482.
Nadat de wijzigingen zijn aangebracht, zou het configuratiebestand er als volgt uit moeten zien:
[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
Met de gemaakte en opgeslagen wijzigingen voeren we een andere applicatie uit genaamd omnidb-config-server . Deze tool kan worden gebruikt om extra configuraties uit te voeren, zoals:
- Vacuüm van de SQLite-database OmniDB-database
- Reset de oude database en maak een nieuwe
- Tijdelijke bestanden verwijderen
- Maak een nieuwe homedirectory voor de database en het configuratiebestand
- Maak een superuser aan om in te loggen bij OmniDB
Hoewel we bij OmniDB inloggen met het beheerdersaccount dat standaard is aangemaakt, zullen we hier nog een supergebruiker maken. Dit kan handig zijn als we individuele DBA-accounts willen maken in OmniDB. Het onderstaande fragment laat dit zien:
# omnidb-config-server --createsuperuser=dba [email protected]$$w0rd123 Creating superuser... Superuser created.
Nadat de superuser is gemaakt, starten we het omnidb-serverproces opnieuw:
# 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
Voordat we toegang krijgen tot de OmniDB-interface, voegen we ook poort 8080 en poort 25482 toe aan de beveiligingsgroep van de EC2-instantie:
Stap 3:Toegang tot de OmniDB-interface
Als u naar het openbare adres en OmniDB-knooppunt bladert, wordt nu het inlogscherm weergegeven:
We specificeren de standaard gebruikersnaam "admin" en het wachtwoord "admin". Hierdoor kunnen we inloggen op de hoofdinterface van OmniDB. Het eerste scherm wordt hieronder getoond:
Vervolgens klikken we op het pictogram "Gebruikers beheren" in de rechterbovenhoek van het scherm:
En verander het standaard wachtwoord van de admin-gebruiker:
Als we klaar zijn, klikken we op de knop "Gegevens opslaan" om het wachtwoord bij te werken. Zoals je kunt zien, kunnen we vanaf dit scherm ook nieuwe gebruikers aanmaken.
Vanuit de linkerbovenhoek van het scherm klikken we op de link 'Verbindingen' en vervolgens in het resulterende dialoogvenster op de knop 'Nieuwe verbinding':
We specificeren vervolgens de verbindingsdetails voor de primaire PostgreSQL-node en klikken op de knop "Gegevens opslaan":
Zodra de verbinding is opgeslagen, klikken we op het verbindingspictogram (groen vinkje) in de kolom "Acties".
Dit opent een nieuw tabblad met de databaseverbinding. Zoals hier wordt weergegeven, zijn we hier verbonden met het primaire PostgreSQL-knooppunt:
We volgen hetzelfde proces om het standby-knooppunt te registreren:
Stap 4:Een voorbeelddatabase herstellen
We herstellen nu een voorbeelddatabase in de primaire PostgreSQL-instantie. Deze database heet "DVDRental" en kan gratis worden gedownload van de PostgreSQL Tutorial-site. We hebben het gedownloade bestand uitgepakt en de bronbestanden uitgepakt in een submap onder de map /tmp van het primaire knooppunt:
[[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
Vervolgens voeren we de volgende shell-opdrachten uit in de primaire PostgreSQL-instantie (PG-Node1). Deze opdrachten brengen enkele wijzigingen aan in het bestand restore.sql:
- Verwijder alle exemplaren van "$$PATH$$/". Dit zorgt ervoor dat het script alle gegevensbestanden in dezelfde map kan vinden
- Wijzig alle exemplaren van "English_United States.1252" in "en_US.UTF-8". Dit zorgt ervoor dat er geen fouten zijn vanwege een ontbrekende landinstelling wanneer het script wordt uitgevoerd.
- Verander de opdracht "DROP DATBASE dvdrental" in "DROP DATBASE IF EXISTS dvdrental", zodat er geen ongeldige databasefout verschijnt.
# 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
Vervolgens schakelen we over naar de postgres-gebruiker en voeren we de volgende opdracht uit vanaf de shell-prompt:
$ psql -U postgres -d postgres -f /tmp/dvdrental/restore.sql
Hiermee wordt de voorbeelddatabase in het primaire knooppunt hersteld. Als we controleren vanuit OmniDB, kunnen we zien dat de database is gemaakt:
Conclusie
We hebben nu een volledig functionerend PostgreSQL-cluster en een OmniDB-instantie die in AWS draait. OmniDB kan verbinding maken met beide knooppunten van het cluster. We hebben ook een database hersteld in het primaire knooppunt dat wordt gerepliceerd naar de stand-by.
Het instellen van de omgeving is nu voltooid. In het tweede deel van dit artikel beginnen we met het maken van een dashboard voor prestatiebewaking voor de primaire instantie.