OmniDB ist ein grafisches Open-Source-Datenbankverwaltungstool, das von 2ndQuadrant, einem weltweit führenden Anbieter von PostgreSQL-Technologien und -Diensten, entwickelt wurde. OmniDB ist ein browserbasiertes, universelles Client-Tool, das wichtige Datenbank-Engines wie PostgreSQL, MariaDB, MySQL und Oracle verwalten kann. Weitere Engines, die bald unterstützt werden, sind SQLite, Firebird, MS SQL Server und IBM DB2.
Wie jede hervorragende Datenbank-Client-Software bietet auch OmniDB den Benutzern einige großartige Funktionen. Dazu gehört die Möglichkeit, Dashboards zur Überwachung der Datenbankleistung zu erstellen und anzupassen. In dieser zweiteiligen Artikelserie erfahren wir, wie Sie die integrierten Überwachungseinheiten von OmniDB – in Dashboard-Begriffen allgemein als „Widgets“ bezeichnet – verwenden, um Dashboards zur Überprüfung des Leistungszustands für einen PostgreSQL 12-Replikationscluster zu erstellen.
Die Testumgebung
Unsere Testumgebung ist ein PostgreSQL 12-Cluster mit zwei Knoten, der in einer AWS-VPC in der Region us-east-1 ausgeführt wird. Die VPC erstreckt sich über drei Verfügbarkeitszonen und hat drei Subnetze. Jedes Subnetz befindet sich in einer separaten Availability Zone (AZ). Der Primär- und der Standby-Knoten befinden sich in zwei dieser Subnetze. Die Knoten sind beide vom Typ t2.large EC2-Instance und führen Open-Source-PostgreSQL 12 aus. Der primäre Knoten wird auf den Standby-Knoten repliziert.
Es wird auch einen „Überwachungsknoten“ geben, auf dem die neueste Version des OmniDB-Datenbankverwaltungstools von 2ndQuadrant ausgeführt wird. Dieser Knoten ist nicht Teil des PostgreSQL-Clusters, sondern wird im dritten Subnetz der VPC in einer anderen AZ gehostet. OmniDB kann sich sowohl mit dem Master- als auch mit dem Standby-Knoten verbinden und deren Leistung überprüfen. Der OmniDB-Knoten ist eine t2.medium EC2-Instance.
Auf allen drei Knoten wird Red Hat Enterprise Linux (RHEL) 8 ausgeführt. Das folgende Bild zeigt die vereinfachte Architektur:
Das Testszenario
Sobald wir den Cluster und OmniDB eingerichtet haben, registrieren wir beide PostgreSQL-Knoten in OmniDB. Anschließend machen wir uns mit einigen der standardmäßigen Überwachungseinheiten in OmniDB vertraut und zeigen Leistungsmetriken von beiden Cluster-Knoten an. Wir führen dann einen Lasttest im primären Knoten mit pgbench durch. Idealerweise sollte der Belastungstest von einem separaten Computer aus initiiert werden, aber in diesem Fall führen wir ihn lokal aus. Wir werden dann sehen, wie das Überwachungs-Dashboard von OmniDB die Änderungen in verschiedenen Leistungsindikatoren anzeigt, wenn sich die Last ändert.
Einrichten der Umgebung
Schritt 1:Installieren eines PostgreSQL 12-Replikationsclusters
Um einen PostgreSQL-Cluster mit zwei Knoten zu erstellen, befolgen wir die in einem zuvor veröffentlichten 2ndQuadrant-Blog beschriebenen Schritte. Der Leser kann diesen Artikel lesen, um zu sehen, wie wir einen Drei-Knoten-Cluster mit einem Witness-Knoten mithilfe eines anderen 2ndQuadrant-Produkts namens repmgr installiert haben . Für unser aktuelles Setup führen wir die gleichen Schritte aus und verwenden repmgr, um einen Zwei-Knoten-Cluster anstelle eines Drei-Knoten-Clusters zu erstellen. Außerdem hat der Replikationscluster keinen Zeugenknoten. Um die Dinge einfach zu halten, zeigt dieser Artikel keine detaillierten Installations- und Konfigurationsschritte.
Sobald unser Cluster eingerichtet ist, können wir seine Funktionsfähigkeit bestätigen, indem wir die pg_stat_replication-Ansicht vom primären Knoten abfragen:
SELECT usename, client_addr, application_name, state, sent_lsn, write_lsn,replay_lsn FROM pg_stat_replication;
Schritt 2:Installieren und Konfigurieren eines OmniDB-Servers
Auf OmniDB wird über eine URL zugegriffen, was bedeutet, dass hinter den Kulissen ein eigener Webserver ausgeführt wird. Es gibt zwei Varianten von OmniDB:
- OmniDB-Anwendung :Dies wird normalerweise von einer Workstation aus ausgeführt und verhält sich wie eine normale Desktop-Anwendung. OmniDB führt den Webserver auf einem zufälligen Port aus, und es ist keine zusätzliche Einrichtung erforderlich.
- OmniDB-Server :Dies dient der Installation von OmniDB auf einem Netzwerkserver für einen Mehrbenutzermodus. Im Servermodus können wir die Portnummer für den Zugriff auf die URL, die SSL-Verschlüsselung der URL, den Lastausgleich und den Reverse-Proxy, den SSH-Passthrough-Zugriff auf Datenbankknoten und die Erstellung von Benutzerkonten für den Zugriff angeben.
Für unser Testszenario installieren wir einen OmniDB-Server im OmniDB EC2-Knoten. Zuerst laden wir das neueste Paket von der OmniDB-Site herunter:
# wget https://www.omnidb.org/dist/2.17.0/omnidb-server_2.17.0-centos7-amd64.rpm
Als nächstes starten wir die Installation. Hier installieren wir OmniDB als Root-Benutzer, aber Sie können jeden anderen Benutzer verwenden, solange er die richtigen Rechte hat:
# rpm -ivh omnidb-server_2.17.0-centos7-amd64.rpm Verifying... ################################# [100%] Preparing... ################################# [100%] Updating / installing... 1:omnidb-server-2.17.0-0 ################################# [100%]
Sobald das Paket installiert ist, können wir OmniDB über die Eingabeaufforderung starten:
# omnidb-server
Dies zeigt den Serverstart:
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
Wir können sehen, dass OmniDB einen Standard-Webserver-Port von 8000 und einen Standard-Websocket-Server auf Port 25482 ausgewählt hat.
Wir drücken Strg+C, um den Serverprozess zu stoppen und zum Home-Verzeichnis des Root-Benutzers zu navigieren. Wir können sehen, dass es einen versteckten Ordner namens .omnidb gibt . Unterhalb dieses Ordners befindet sich ein Unterverzeichnis namens omnidb-server . Im Unterverzeichnis omnidb-server befinden sich einige Dateien:
# 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
Sobald der Serverprozess startet, initialisiert OmniDB diese Dateien. Die OmniDB-Metadatendatenbank heißt omnidb.db . Dies ist eine SQLite-Datenbank und enthält Informationen zu Datenbankverbindungen, OmniDB-Benutzern usw. Die omnidb.conf Datei enthält Konfigurationsoptionen für den OmniDB-Server. Wenn wir diese Datei in einem Editor öffnen, sieht sie wie folgt aus:
# 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 führt zwei Serverprozesse aus. Einer ist ein Webserver, der die Benutzeroberfläche anzeigt, der andere ist der Websocket-Server. Der Websocket-Server wird von mehreren Funktionen der Anwendung verwendet, z. B. Abfrage, Konsole und Debugging.
Aus der Konfigurationsdatei können wir ersehen, dass der OmniDB-Server standardmäßig lokalen Datenverkehr (127.0.0.1) auf dem Webserver-Port 8000 akzeptiert. Wir werden dies in ALLE IP-Adressen ändern. Sofern sich der Computer nicht hinter einem Reverse-Proxy befindet, wird dringend empfohlen, SSL-Verschlüsselung für HTTP-Verbindungen zum Server zu verwenden. In unserem Beispiel lassen wir jedoch is_ssl Parameter auf „False“ setzen, weil wir diese Maschine abreißen werden, sobald unsere Tests abgeschlossen sind. Wir werden auch den Webserver-Port auf 8080 ändern und den Websocket-Server-Port auf seinem Standardwert von 25482 belassen.
Sobald Änderungen vorgenommen wurden, sollte die Konfigurationsdatei wie folgt aussehen:
[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
Mit den vorgenommenen und gespeicherten Änderungen führen wir eine andere Anwendung namens omnidb-config-server aus . Dieses Tool kann verwendet werden, um einige zusätzliche Konfigurationen durchzuführen, wie zum Beispiel:
- Aufräumen der SQLite-Datenbank OmniDB-Datenbank
- Setzen Sie die alte Datenbank zurück und erstellen Sie eine neue
- Temporäre Dateien löschen
- Erstellen Sie ein neues Home-Verzeichnis für die Datenbank und die Konfigurationsdatei
- Erstellen Sie einen Superuser für die Anmeldung bei OmniDB
Obwohl wir uns mit dem standardmäßig erstellten Admin-Benutzerkonto bei OmniDB anmelden, erstellen wir hier einen weiteren Superuser. Dies kann nützlich sein, wenn wir einzelne DBA-Konten in OmniDB erstellen möchten. Das folgende Snippet zeigt dies:
# omnidb-config-server --createsuperuser=dba [email protected]$$w0rd123 Creating superuser... Superuser created.
Nachdem der Superuser erstellt wurde, starten wir den Omnidb-Server-Prozess erneut:
# 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
Bevor wir auf die OmniDB-Schnittstelle zugreifen, fügen wir auch Port 8080 und Port 25482 zur Sicherheitsgruppe der EC2-Instanz hinzu:
Schritt 3:Zugriff auf die OmniDB-Oberfläche
Beim Navigieren zur öffentlichen Adresse und zum OmniDB-Knoten wird jetzt der Anmeldebildschirm angezeigt:
Wir geben den Standardbenutzernamen „admin“ und sein Passwort „admin“ an. Dadurch können wir uns bei der Hauptschnittstelle von OmniDB anmelden. Der erste Bildschirm ist unten dargestellt:
Als nächstes klicken wir auf das Symbol „Benutzer verwalten“ in der oberen rechten Ecke des Bildschirms:
Und ändern Sie das Standardpasswort des Admin-Benutzers:
Sobald dies erledigt ist, klicken wir auf die Schaltfläche „Daten speichern“, um das Passwort zu aktualisieren. Wie Sie sehen können, können wir über diesen Bildschirm auch neue Benutzer erstellen.
In der linken oberen Ecke des Bildschirms klicken wir auf den Link „Verbindungen“ und dann im daraufhin angezeigten Dialogfeld auf die Schaltfläche „Neue Verbindung“:
Anschließend geben wir die Verbindungsdetails für den primären PostgreSQL-Knoten an und klicken auf die Schaltfläche „Daten speichern“:
Sobald die Verbindung gespeichert ist, klicken wir auf das Verbindungssymbol (grünes Häkchen) in der Spalte „Aktionen“.
Dies öffnet eine neue Registerkarte, die die Datenbankverbindung anzeigt. Wie hier gezeigt, sind wir hier mit dem primären PostgreSQL-Knoten verbunden:
Wir folgen demselben Prozess, um den Standby-Knoten zu registrieren:
Schritt 4:Wiederherstellen einer Beispieldatenbank
Wir stellen jetzt eine Beispieldatenbank in der primären PostgreSQL-Instanz wieder her. Diese Datenbank heißt „DVDRental“ und kann kostenlos von der PostgreSQL-Tutorial-Site heruntergeladen werden. Wir haben die heruntergeladene Datei entpackt und die Quelldateien in ein Unterverzeichnis im Ordner /tmp des primären Knotens extrahiert:
[[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
Als Nächstes führen wir die folgenden Shell-Befehle in der primären PostgreSQL-Instanz (PG-Node1) aus. Diese Befehle nehmen einige Änderungen an der Datei restore.sql vor:
- Entfernen Sie alle Vorkommen von „$$PATH$$/“. Dadurch wird sichergestellt, dass das Skript alle Datendateien im selben Verzeichnis finden kann
- Ändern Sie alle Vorkommen von „English_United States.1252“ in „en_US.UTF-8“. Dadurch wird sichergestellt, dass beim Ausführen des Skripts keine Fehler aufgrund eines fehlenden Gebietsschemas auftreten.
- Ändern Sie den „DROP DATBASE dvdrental“-Befehl zu „DROP DATBASE IF EXISTS dvdrental“, damit kein ungültiger Datenbankfehler angezeigt wird.
# 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
Als nächstes wechseln wir zum Postgres-Benutzer und führen den folgenden Befehl am Shell-Prompt aus:
$ psql -U postgres -d postgres -f /tmp/dvdrental/restore.sql
Dadurch wird die Beispieldatenbank auf dem primären Knoten wiederhergestellt. Wenn wir von OmniDB prüfen, können wir sehen, dass die Datenbank erstellt wurde:
Schlussfolgerung
Wir haben jetzt einen voll funktionsfähigen PostgreSQL-Cluster und eine OmniDB-Instance, die in AWS ausgeführt wird. OmniDB kann eine Verbindung zu beiden Knoten des Clusters herstellen. Wir haben auch eine Datenbank im primären Knoten wiederhergestellt, die auf den Standby-Knoten repliziert wird.
Die Einrichtung der Umgebung ist nun abgeschlossen. Im zweiten Teil dieses Artikels beginnen wir mit der Erstellung eines Leistungsüberwachungs-Dashboards für die primäre Instanz.
