OmniDB est un outil de gestion de base de données graphique open source développé par 2ndQuadrant, un leader mondial des technologies et services PostgreSQL. OmniDB est un outil client universel basé sur un navigateur qui peut gérer les principaux moteurs de base de données tels que PostgreSQL, MariaDB, MySQL et Oracle. Les autres moteurs qui seront bientôt pris en charge incluent SQLite, Firebird, MS SQL Server et IBM DB2.
Comme tout excellent logiciel client de base de données, OmniDB offre également aux utilisateurs des fonctionnalités intéressantes. Celles-ci incluent la possibilité de créer et de personnaliser des tableaux de bord de surveillance des performances de la base de données. Dans cette série d'articles en deux parties, nous apprendrons à utiliser les unités de surveillance intégrées d'OmniDB - communément appelées "widgets" en termes de tableau de bord - pour créer des tableaux de bord de vérification de l'état des performances pour un cluster de réplication PostgreSQL 12.
L'environnement de test
Notre environnement de test est un cluster PostgreSQL 12 à deux nœuds, exécuté dans un VPC AWS dans la région us-east-1. Le VPC s'étend sur trois zones de disponibilité et possède trois sous-réseaux. Chaque sous-réseau se trouve dans une zone de disponibilité (AZ) distincte. Le nœud principal et le nœud de secours sont situés dans deux de ces sous-réseaux. Les nœuds sont tous deux du type d'instance EC2 t2.large et exécuteront PostgreSQL 12 open source. Le nœud principal se répliquera sur le nœud de secours.
Il y aura également un "nœud de surveillance" exécutant la dernière version de l'outil de gestion de base de données OmniDB de 2ndQuadrant. Ce nœud ne fera pas partie du cluster PostgreSQL, mais sera hébergé dans le troisième sous-réseau du VPC, dans une autre AZ. OmniDB pourra se connecter à la fois au nœud maître et au nœud de secours et vérifier leurs performances. Le nœud OmniDB sera une instance EC2 t2.medium.
Les trois nœuds exécuteront Red Hat Enterprise Linux (RHEL) 8. L'image ci-dessous montre l'architecture simplifiée :
Le scénario de test
Une fois que nous aurons configuré le cluster et OmniDB, nous enregistrerons les deux nœuds PostgreSQL dans OmniDB. Nous nous familiariserons ensuite avec certaines des unités de surveillance standard d'OmniDB et afficherons les mesures de performances des deux nœuds de cluster. Nous allons ensuite exécuter un test de charge dans le nœud principal à l'aide de pgbench. Idéalement, le test de charge devrait être lancé à partir d'une machine distincte, mais dans ce cas, nous l'exécuterons localement. Nous verrons ensuite comment le tableau de bord de surveillance d'OmniDB affiche les changements dans divers compteurs de performances à mesure que la charge change.
Configuration de l'environnement
Étape 1 :Installer un cluster de réplication PostgreSQL 12
Pour créer un cluster PostgreSQL à deux nœuds, nous suivons les étapes décrites dans un blog 2ndQuadrant précédemment publié. Le lecteur peut consulter cet article pour voir comment nous avons installé un cluster à trois nœuds avec un nœud témoin à l'aide d'un autre produit 2ndQuadrant appelé repmgr . Pour notre configuration actuelle, nous suivons les mêmes étapes en utilisant repmgr pour créer un cluster à deux nœuds au lieu d'un cluster à trois nœuds. De plus, le cluster de réplication n'aura aucun nœud témoin. Pour simplifier les choses, cet article ne montre pas les étapes détaillées d'installation et de configuration.
Une fois notre cluster configuré, nous pouvons confirmer qu'il fonctionne en interrogeant la vue pg_stat_replication depuis le nœud principal :
SELECT usename, client_addr, application_name, state, sent_lsn, write_lsn,replay_lsnFROM pg_stat_replication ;
Étape 2 :Installer et configurer un serveur OmniDB
OmniDB est accessible à l'aide d'une URL, ce qui signifie qu'en coulisse, il exécute son propre serveur Web. Il existe deux versions d'OmniDB :
- Application OmniDB :Ceci est généralement exécuté à partir d'un poste de travail et se comporte comme une application de bureau normale. OmniDB exécute le serveur Web sur un port aléatoire et aucune configuration supplémentaire n'est nécessaire.
- Serveur OmniDB :Il s'agit d'installer OmniDB sur un serveur réseau pour un mode multi-utilisateurs. En mode serveur, nous pouvons spécifier le numéro de port pour accéder à l'URL, le cryptage SSL de l'URL, l'équilibrage de charge et le proxy inverse, l'accès direct SSH aux nœuds de la base de données et la création de comptes d'utilisateurs pour l'accès.
Pour notre scénario de test, nous allons installer un serveur OmniDB dans le nœud OmniDB EC2. Tout d'abord, nous téléchargeons le dernier package depuis le site OmniDB :
# wget https://www.omnidb.org/dist/2.17.0/omnidb-server_2.17.0-centos7-amd64.rpm
Ensuite, nous commençons l'installation. Ici, nous installons OmniDB en tant qu'utilisateur root, mais vous pouvez utiliser n'importe quel autre utilisateur tant qu'il dispose des droits appropriés :
# rpm -ivh omnidb-server_2.17.0-centos7-amd64.rpmVérification... ############################## #### [100 %]Préparation... ################################## [100 %]Mise à jour / installation... 1:omnidb-server-2.17.0-0 ################################# [ 100 %]
Une fois le package installé, nous pouvons démarrer OmniDB à partir de l'invite de commande :
# omnidb-server
Cela montre le démarrage du serveur :
Démarrage d'OmniDB websocket...Vérification de la disponibilité du port...Démarrage du serveur websocket sur le port 25482 .Démarrage du serveur OmniDB...Vérification de la disponibilité du port...Démarrage du serveur OmniDB 2.17.0 à 127.0.0.1:8000 .Démarrage de la migration de la base de données utilisateur de la version 0.0.0 vers la version 2.17.0...OmniDB a migré avec succès la base de données utilisateur de la version 0.0.0 vers la version 2.17.0Ouvrez OmniDB dans votre navigateur préféréAppuyez sur Ctrl+C pour quitter
Nous pouvons voir qu'OmniDB a choisi un port de serveur Web par défaut de 8000 et un serveur Websocket par défaut sur le port 25482.
Nous appuyons sur Ctrl + C pour arrêter le processus du serveur et accédez au répertoire personnel de l'utilisateur root. Nous pouvons voir qu'il existe un dossier caché nommé .omnidb . Sous ce dossier, il y a un sous-répertoire appelé omnidb-server . Dans le sous-répertoire omnidb-server, il y a quelques fichiers :
# ls -la ~ …drwxr-xr-x. 3 racine racine 27 juin 13 02:49 .omnidb ……# ls -la ~/.omnidb …drwxr-xr-x. 2 root root 106 13 juin 02:49 omnidb-server # ls -la ~/.omnidb/omnidb-server/ …-rw-r--r--. 1 racine racine 131072 13 juin 02:49 db.sqlite3-rw-r--r--. 1 racine racine 1209 13 juin 02:49 omnidb.conf -rw-r--r--. 1 racine racine 116736 13 juin 02:49 omnidb.db -rw-r--r--. 1 racine racine 0 13 juin 02:49 omnidb.db.bak_2.17.0-rw-r--r--. 1 racine racine 579 13 juin 02:49 omnidb.log
Une fois le processus serveur lancé, OmniDB initialise ces fichiers. La base de données de métadonnées OmniDB s'appelle omnidb.db . Il s'agit d'une base de données SQLite et contient des informations sur les connexions à la base de données, les utilisateurs OmniDB, etc. Le omnidb.conf Le fichier contient des options de configuration pour le serveur OmniDB. Si nous ouvrons ce fichier dans un éditeur, il ressemble à ceci :
# Fichier de configuration OmniDB Server[webserver]# Quelle adresse le serveur Web écoute, 0.0.0.0 écoute toutes les adresses liées à la machinelistening_address =127.0.0.1 # Port du serveur Web, si le port est utilisé, un autre port aléatoire sera sélectionnélistening_port =8000 # Port Websocket, si le port est utilisé, un autre port aléatoire sera sélectionnéwebsocket_port =25482 # Port Websocket externe, utilisez ce paramètre si OmniDB n'est pas directement visible par le client# external_websocket_port =25482# Paramètres de sécurité# is_ssl =True nécessite les paramètres ssl_certificate_file et ssl_key_file# Ceci est fortement recommandé pour protéger les informationsis_ssl =False ssl_certificate_file =/chemin/vers/cert_file ssl_key_file =/path/to/key_file # Origines de confiance, utilisez ce paramètre si OmniDB est configuré avec SSL et est accessible par un autre domainecsrf_trusted_origins =origin1,origin2,origin3# Chemin d'url pour accéder à OmniDB, la valeur par défaut est vide [queryserver]# Nombre maximum de threads pouvant être utilisés par chaque requête de recherche d'objet avancéethread_pool_max_workers =2 # Nombre de secondes entre chaque demande de mot de passe rapide. Par défaut :30 minutespwd_timeout_total =1800
OmniDB exécute deux processus serveur. L'un est un serveur Web qui affiche l'interface utilisateur, l'autre est le serveur websocket. Le serveur websocket est utilisé par plusieurs fonctionnalités de l'application, telles que la requête, la console et le débogage.
Dans le fichier de configuration, nous pouvons voir que, par défaut, le serveur OmniDB accepte le trafic local (127.0.0.1) sur le port 8000 du serveur Web. Nous allons le remplacer par TOUTES les adresses IP. À moins que la machine ne soit derrière un proxy inverse, il est fortement recommandé d'utiliser le cryptage SSL pour les connexions HTTP au serveur. Dans notre exemple cependant, nous laisserons le is_ssl paramètre sur "False" car nous démonterons cette machine une fois nos tests terminés. Nous allons également changer le port du serveur Web en 8080 et conserver le port du serveur Websocket à sa valeur par défaut de 25482.
Une fois les modifications apportées, le fichier de configuration devrait ressembler à ceci :
[Webserver] écouter_address =0.0.0.0Lestening_port =8080websocket_port =25482is_ssl =falssl_certificate_file =/ path / to / cert_filessl_key_file =/ path / to / key_filecsrf_trusted_origins =origin1, origin2, origin3Path =[querySo>Avec les modifications apportées et enregistrées, nous exécutons une autre application appelée omnidb-config-server . Cet outil peut être utilisé pour effectuer des configurations supplémentaires telles que :
- Vide de la base de données SQLite Base de données OmniDB
- Réinitialiser l'ancienne base de données et en créer une nouvelle
- Supprimer les fichiers temporaires
- Créer un nouveau répertoire personnel pour la base de données et le fichier de configuration
- Créer un superutilisateur pour se connecter à OmniDB
Bien que nous nous connections à OmniDB à l'aide du compte d'utilisateur administrateur créé par défaut, nous allons créer un autre superutilisateur ici. Cela peut être utile si nous voulons créer des comptes DBA individuels dans OmniDB. L'extrait ci-dessous montre ceci :
# omnidb-config-server --createsuperuser=dba [email protected]$$w0rd123Création du superutilisateur... Superutilisateur créé.
Une fois le superutilisateur créé, nous recommençons le processus omnidb-server :
# omnidb-serverDémarrage d'OmniDB websocket...Vérification de la disponibilité du port...Démarrage du serveur websocket au port 25482.Démarrage du serveur OmniDB...Vérification de la disponibilité du port...Démarrage du serveur OmniDB 2.17.0 à 0.0.0.0:8080. La version 2.17.0 de la base de données utilisateur correspond déjà à la version du serveur.Ouvrez OmniDB dans votre navigateur préféréAppuyez sur Ctrl+C pour quitter
Avant d'accéder à l'interface OmniDB, nous ajoutons également le port 8080 et le port 25482 au groupe de sécurité de l'instance EC2 :
Étape 3 :Accéder à l'interface OmniDB
La navigation vers l'adresse publique et le nœud OmniDB affiche maintenant l'écran de connexion :
Nous spécifions le nom d'utilisateur par défaut « admin » et son mot de passe, « admin ». Cela nous permet de nous connecter à l'interface principale d'OmniDB. Le premier écran est illustré ci-dessous :
Ensuite, nous cliquons sur l'icône "Gérer les utilisateurs" dans le coin supérieur droit de l'écran :
Et changez le mot de passe par défaut de l'utilisateur admin :
Une fois cela fait, nous cliquons sur le bouton "Enregistrer les données" pour mettre à jour le mot de passe. Comme vous pouvez le voir, nous pouvons également créer de nouveaux utilisateurs à partir de cet écran.
Dans le coin supérieur gauche de l'écran, nous cliquons sur le lien "Connexions", puis dans la boîte de dialogue résultante, cliquez sur le bouton "Nouvelle connexion":
Nous spécifions ensuite les détails de connexion pour le nœud PostgreSQL principal et cliquons sur le bouton « Enregistrer les données » :
Une fois la connexion enregistrée, on clique sur l'icône de connexion (coche verte) de la colonne "Actions".
Cela ouvre un nouvel onglet montrant la connexion à la base de données. Comme indiqué ici, nous sommes connectés au nœud PostgreSQL principal ici :
Nous suivons le même processus pour enregistrer le nœud de secours :
Étape 4 :Restauration d'un exemple de base de données
Nous sommes en train de restaurer un exemple de base de données dans l'instance PostgreSQL principale. Cette base de données s'appelle "DVDRental" et est téléchargeable gratuitement sur le site du didacticiel PostgreSQL. Nous avons décompressé le fichier téléchargé et extrait les fichiers source dans un sous-répertoire sous le dossier /tmp du nœud principal :
[[email protected] dvdrental] # ls -latotal 2796drwxr-xr-x. 2 root root 280 16 juin 11:32 .drwxrwxrwt. 9 root root 257 16 juin 11:31 ..-rw-------. 1 postgres postgres 57147 12 mai 2019 3055.dat-rw-------. 1 postgres postgres 8004 12 mai 2019 3057.dat-rw-------. 1 postgres postgres 483 12 mai 2019 3059.dat-rw-------. 1 postgres postgres 333094 12 mai 2019 3061.dat-rw-------. 1 postgres postgres 149469 12 mai 2019 3062.dat-rw-------. 1 postgres postgres 26321 12 mai 2019 3063.dat-rw-------. 1 postgres postgres 46786 12 mai 2019 3065.dat-rw-------. 1 postgres postgres 21762 12 mai 2019 3067.dat-rw-------. 1 postgres postgres 3596 12 mai 2019 3069.dat-rw-------. 1 postgres postgres 140422 12 mai 2019 3071.dat-rw-------. 1 postgres postgres 263 12 mai 2019 3073.dat-rw-------. 1 postgres postgres 718644 12 mai 2019 3075.dat-rw-------. 1 postgres postgres 1214420 12 mai 2019 3077.dat-rw-------. 1 postgres postgres 271 12 mai 2019 3079.dat-rw-------. 1 postgres postgres 57 12 mai 2019 3081.dat-rw-------. 1 postgres postgres 45872 12 mai 2019 restore.sql-rw-------. 1 postgres postgres 55111 12 mai 2019 toc.dat
Ensuite, nous exécutons les commandes shell suivantes dans l'instance PostgreSQL principale (PG-Node1). Ces commandes apportent quelques modifications au fichier restore.sql :
- Supprimez toutes les occurrences de "$$PATH$$/". Cela garantit que le script peut trouver tous les fichiers de données dans le même répertoire
- Remplacez toutes les occurrences de "English_United States.1252" par "en_US.UTF-8". Cela garantit qu'il n'y a pas d'erreurs dues à des paramètres régionaux manquants lors de l'exécution du script.
- Remplacez la commande "DROP DATBASE dvdrental" par "DROP DATBASE IF EXISTS dvdrental", afin qu'aucune erreur de base de données non valide ne s'affiche.
# 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
Ensuite, nous passons à l'utilisateur postgres et exécutons la commande suivante à partir de l'invite du shell :
$ psql -U postgres -d postgres -f /tmp/dvdrental/restore.sql
Cela restaure l'exemple de base de données dans le nœud principal. Si nous vérifions depuis OmniDB, nous pouvons voir que la base de données est créée :
Conclusion
Nous avons maintenant un cluster PostgreSQL entièrement fonctionnel et une instance OmniDB s'exécutant dans AWS. OmniDB peut se connecter aux deux nœuds du cluster. Nous avons également restauré une base de données dans le nœud principal qui est en cours de réplication sur le serveur de secours.
La configuration de l'environnement est maintenant terminée. Dans la deuxième partie de cet article, nous commencerons à créer un tableau de bord de surveillance des performances pour l'instance principale.
