OmniDB è uno strumento di gestione di database grafico open source sviluppato da 2ndQuadrant, leader mondiale nelle tecnologie e nei servizi PostgreSQL. OmniDB è uno strumento client universale basato su browser in grado di gestire i principali motori di database come PostgreSQL, MariaDB, MySQL e Oracle. Altri motori presto supportati includono SQLite, Firebird, MS SQL Server e IBM DB2.
Come ogni eccellente software client di database, OmniDB offre anche agli utenti alcune fantastiche funzionalità. Questi includono la possibilità di creare e personalizzare dashboard di monitoraggio delle prestazioni del database. In questa serie di articoli in due parti, impareremo come utilizzare le unità di monitoraggio integrate di OmniDB, comunemente note come "widget" in termini di dashboard, per creare dashboard di controllo dello stato delle prestazioni per un cluster di replica PostgreSQL 12.
L'ambiente di prova
Il nostro ambiente di test è un cluster PostgreSQL 12 a due nodi, in esecuzione in un AWS VPC nella regione us-east-1. Il VPC si estende su tre zone di disponibilità e dispone di tre sottoreti. Ogni sottorete si trova in una zona di disponibilità (AZ) separata. Il nodo primario e quello di standby si trovano in due di queste sottoreti. I nodi sono entrambi di tipo t2.large EC2 ed eseguiranno PostgreSQL 12 open source. Il nodo primario verrà replicato sul nodo standby.
Ci sarà anche un "nodo di monitoraggio" che esegue l'ultima versione dello strumento di gestione del database OmniDB di 2ndQuadrant. Questo nodo non farà parte del cluster PostgreSQL, ma sarà ospitato nella terza sottorete del VPC, in un'altra AZ. OmniDB sarà in grado di connettersi sia al nodo master che a quello standby e verificarne le prestazioni. Il nodo OmniDB sarà un'istanza EC2 t2.medium.
Tutti e tre i nodi eseguiranno Red Hat Enterprise Linux (RHEL) 8. L'immagine seguente mostra l'architettura semplificata:
Lo scenario di prova
Dopo aver configurato il cluster e OmniDB, registreremo entrambi i nodi PostgreSQL in OmniDB. Acquisteremo quindi familiarità con alcune delle unità di monitoraggio standard in OmniDB e visualizzeremo le metriche delle prestazioni da entrambi i nodi del cluster. Eseguiremo quindi un test di carico nel nodo primario utilizzando pgbench. Idealmente, il test di carico dovrebbe essere avviato da una macchina separata, ma in questo caso lo eseguiremo localmente. Vedremo quindi come la dashboard di monitoraggio di OmniDB mostra le modifiche nei vari contatori delle prestazioni al variare del carico.
Impostazione dell'ambiente
Passaggio 1:installazione di un cluster di replica PostgreSQL 12
Per creare un cluster PostgreSQL a due nodi, stiamo seguendo i passaggi descritti in un blog 2ndQuadrant pubblicato in precedenza. Il lettore può controllare questo articolo per vedere come abbiamo installato un cluster a tre nodi con un nodo di controllo utilizzando un altro prodotto 2ndQuadrant chiamato repmgr . Per la nostra configurazione attuale, stiamo seguendo gli stessi passaggi usando repmgr per creare un cluster a due nodi invece di uno a tre nodi. Inoltre, il cluster di replica non avrà alcun nodo di controllo. Per semplificare le cose, questo articolo non mostra i passaggi dettagliati di installazione e configurazione.
Una volta che il nostro cluster è impostato, possiamo confermarne il funzionamento eseguendo una query su pg_stat_replication view dal nodo primario:
SELECT usename, client_addr, application_name, state, sent_lsn, write_lsn,replay_lsnFROM pg_stat_replication;
Fase 2:installazione e configurazione di un server OmniDB
OmniDB è accessibile tramite un URL, il che significa che dietro le quinte esegue un proprio server web. Esistono due versioni di OmniDB:
- Applicazione OmniDB :in genere viene eseguito da una workstation e si comporta come una normale applicazione desktop. OmniDB esegue il server web su una porta casuale e non è necessaria alcuna configurazione aggiuntiva.
- Server OmniDB :serve per installare OmniDB su un server di rete per una modalità multiutente. Nella modalità server, possiamo specificare il numero di porta per l'accesso all'URL, la crittografia SSL dell'URL, il bilanciamento del carico e il proxy inverso, l'accesso SSH passthrough ai nodi del database e la creazione di account utente per l'accesso.
Per il nostro scenario di test, installeremo un server OmniDB nel nodo OmniDB EC2. Innanzitutto, stiamo scaricando l'ultimo pacchetto dal sito OmniDB:
# wget https://www.omnidb.org/dist/2.17.0/omnidb-server_2.17.0-centos7-amd64.rpm
Successivamente, iniziamo l'installazione. Qui stiamo installando OmniDB come utente root, ma puoi utilizzare qualsiasi altro utente purché disponga dei diritti corretti:
# rpm -ivh omnidb-server_2.17.0-centos7-amd64.rpmVerifica in corso... #################################### #### [100%]Preparazione in corso... ########################################### [100%]Aggiornamento / installazione... 1:omnidb-server-2.17.0-0 ######################################## [ 100%]
Una volta installato il pacchetto, possiamo avviare OmniDB dal prompt dei comandi:
# server omnidb
Questo mostra l'avvio del server:
Avvio websocket OmniDB... Verifica disponibilità porta...Avvio server websocket alla porta 25482 .Avvio del server OmniDB...Verifica della disponibilità delle porte...Avvio del server OmniDB 2.17.0 alle 127.0.0.1:8000 .Avvio della migrazione del database utente dalla versione 0.0.0 alla versione 2.17.0...OmniDB ha migrato correttamente il database utente dalla versione 0.0.0 alla versione 2.17.0Apri OmniDB nel tuo browser preferitoPremi Ctrl+C per uscire
Possiamo vedere che OmniDB ha scelto una porta del server web predefinita di 8000 e un server websocket predefinito alla porta 25482.
Premiamo Ctrl+C per interrompere il processo del server e passare alla home directory dell'utente root. Possiamo vedere che c'è una cartella nascosta chiamata .omnidb . Sotto questa cartella, c'è una sottodirectory chiamata omnidb-server . All'interno della sottodirectory omnidb-server, ci sono alcuni file:
# ls -la ~ …drwxr-xr-x. 3 radice radice 27 giu 13 02:49 .omnidb ……# ls -la ~/.omnidb …drwxr-xr-x. 2 root root 106 13 giu 02:49 omnidb-server # ls -la ~/.omnidb/omnidb-server/ …-rw-r--r--. 1 radice radice 131072 13 giugno 02:49 db.sqlite3-rw-r--r--. 1 radice radice 1209 13 giugno 02:49 omnidb.conf -rw-r--r--. 1 radice radice 116736 13 giugno 02:49 omnidb.db -rw-r--r--. 1 radice radice 0 13 giugno 02:49 omnidb.db.bak_2.17.0-rw-r--r--. 1 radice radice 579 13 giu 02:49 omnidb.log
Una volta avviato il processo del server, OmniDB inizializza questi file. Il database dei metadati OmniDB si chiama omnidb.db . Questo è un database SQLite e contiene informazioni sulle connessioni al database, sugli utenti OmniDB e così via. omnidb.conf contiene le opzioni di configurazione per il server OmniDB. Se apriamo questo file in un editor, apparirà come segue:
# File di configurazione del server OmniDB[server web]# Quale indirizzo ascolta il server web, 0.0.0.0 ascolta tutti gli indirizzi associati alla macchinaindirizzo_ascolto =127.0.0.1 # Porta del server web, se la porta è in uso verrà selezionata un'altra porta casualeporta_ascolto =8000 # Porta Websocket, se la porta è in uso verrà selezionata un'altra porta casualewebsocket_port =25482 # Porta Websocket esterna, utilizzare questo parametro se OmniDB non è direttamente visibile dal client# external_websocket_port =25482# Parametri di sicurezza# is_ssl =True richiede parametri ssl_certificate_file e ssl_key_file# Questo è altamente raccomandato per proteggere le informazioniis_ssl =False file_certificato_ssl =/percorso/del/file_certificato file_chiave_ssl =/percorso/del/file_chiave # Origini attendibili, utilizzare questo parametro se OmniDB è configurato con SSL ed è accessibile da un altro dominiocsrf_trusted_origins =origin1,origin2,origin3# Percorso URL per accedere a OmniDB, il valore predefinito è vuotopercorso = [queryserver]# Numero massimo di thread che possono essere utilizzati da ciascuna richiesta di ricerca di oggetti avanzatathread_pool_max_workers =2 # Numero di secondi tra ogni richiesta di password richiesta. Predefinito:30 minutipwd_timeout_total =1800
OmniDB esegue due processi server. Uno è un server web che mostra l'interfaccia utente, l'altro è il server websocket. Il server websocket è utilizzato da diverse funzionalità dell'applicazione, come query, console e debug.
Dal file di configurazione, possiamo vedere che per impostazione predefinita il server OmniDB accetta il traffico locale (127.0.0.1) sulla porta del server web 8000. Lo cambieremo in TUTTI gli indirizzi IP. A meno che la macchina non sia dietro un proxy inverso, si consiglia vivamente di utilizzare la crittografia SSL per le connessioni HTTP al server. Nel nostro esempio, tuttavia, lasceremo is_ssl parametro su "False" perché abbatteremo questa macchina una volta che i nostri test saranno terminati. Cambieremo anche la porta del server web su 8080 e manterremo la porta del server websocket sul valore predefinito di 25482.
Una volta apportate le modifiche, il file di configurazione dovrebbe assomigliare a questo:
;>Con le modifiche apportate e salvate, eseguiamo un'altra applicazione chiamata omnidb-config-server . Questo strumento può essere utilizzato per eseguire alcune configurazioni extra come:
- Aspirazione del database SQLite Database OmniDB
- Reimposta il vecchio database e creane uno nuovo
- Elimina i file temporanei
- Crea una nuova home directory per il database e il file di configurazione
- Crea un superutente per accedere a OmniDB
Anche se accederemo a OmniDB utilizzando l'account utente amministratore creato per impostazione predefinita, creeremo un altro superutente qui. Questo può essere utile se vogliamo creare account DBA individuali in OmniDB. Lo snippet di seguito mostra questo:
# omnidb-config-server --createsuperuser=dba [email protected]$$w0rd123Creazione superutente...Creato superutente.
Con il superutente creato, iniziamo nuovamente il processo omnidb-server:
# omnidb-serverAvvio websocket OmniDB...Verifica disponibilità porta...Avvio server websocket alla porta 25482.Avvio server OmniDB...Verifica disponibilità porta...Avvio server OmniDB 2.17.0 a 0.0.0.0:8080. La versione del database utente 2.17.0 corrisponde già alla versione del server. Apri OmniDB nel tuo browser preferito Premi Ctrl+C per uscire
Prima di accedere all'interfaccia OmniDB, aggiungiamo anche la porta 8080 e la porta 25482 al gruppo di sicurezza dell'istanza EC2:
Fase 3:accesso all'interfaccia OmniDB
Navigando all'indirizzo pubblico e al nodo OmniDB ora viene mostrata la schermata di accesso:
Specifichiamo il nome utente predefinito di "admin" e la sua password, "admin". Questo ci consente di accedere all'interfaccia principale di OmniDB. La prima schermata è mostrata di seguito:
Successivamente, facciamo clic sull'icona "Gestisci utenti" nell'angolo in alto a destra dello schermo:
E cambia la password predefinita dell'utente amministratore:
Una volta fatto, clicchiamo sul pulsante "Salva dati" per aggiornare la password. Come puoi vedere, possiamo anche creare nuovi utenti da questa schermata.
Dall'angolo in alto a sinistra dello schermo, facciamo clic sul collegamento "Connessioni", quindi dalla finestra di dialogo risultante, facciamo clic sul pulsante "Nuova connessione":
Specifichiamo quindi i dettagli di connessione per il nodo PostgreSQL primario e facciamo clic sul pulsante "Salva dati":
Una volta salvata la connessione, clicchiamo sull'icona della connessione (segno di spunta verde) dalla colonna "Azioni".
Si apre una nuova scheda che mostra la connessione al database. Come mostrato qui, siamo collegati al nodo PostgreSQL primario qui:
Seguiamo la stessa procedura per registrare il nodo standby:
Fase 4:ripristino di un database di esempio
Ora stiamo ripristinando un database di esempio nell'istanza PostgreSQL primaria. Questo database si chiama “DVDRental” ed è scaricabile gratuitamente dal sito PostgreSQL Tutorial. Abbiamo decompresso il file scaricato ed estratto i file di origine in una sottodirectory nella cartella /tmp del nodo primario:
[[email protected] dvdrental] # ls -latotal 2796drwxr-xr-x. 2 radice radice 280 16 giugno 11:32 .drwxrwxrwt. 9 radice radice 257 16 giu 11:31 ..-rw-------. 1 postgres postgres 57147 12 maggio 2019 3055.dat-rw-------. 1 postgres postgres 8004 12 maggio 2019 3057.dat-rw-------. 1 postgres postgres 483 12 maggio 2019 3059.dat-rw-------. 1 postgres postgres 333094 12 maggio 2019 3061.dat-rw-------. 1 postgres postgres 149469 12 maggio 2019 3062.dat-rw-------. 1 postgres postgres 26321 12 maggio 2019 3063.dat-rw-------. 1 postgres postgres 46786 12 maggio 2019 3065.dat-rw-------. 1 postgres postgres 21762 12 maggio 2019 3067.dat-rw-------. 1 postgres postgres 3596 12 maggio 2019 3069.dat-rw-------. 1 postgres postgres 140422 12 maggio 2019 3071.dat-rw-------. 1 postgres postgres 263 12 maggio 2019 3073.dat-rw-------. 1 postgres postgres 718644 12 maggio 2019 3075.dat-rw-------. 1 postgres postgres 1214420 12 maggio 2019 3077.dat-rw-------. 1 postgres postgres 271 12 maggio 2019 3079.dat-rw-------. 1 postgres postgres 57 12 maggio 2019 3081.dat-rw-------. 1 postgres postgres 45872 12 maggio 2019 restore.sql-rw-------. 1 postgres postgres 55111 12 maggio 2019 toc.dat
Successivamente, eseguiamo i seguenti comandi della shell nell'istanza PostgreSQL primaria (PG-Node1). Questi comandi apportano alcune modifiche al file restore.sql:
- Rimuovi tutte le occorrenze di “$$PATH$$/”. Ciò garantisce che lo script possa trovare tutti i file di dati nella stessa directory
- Cambia tutte le occorrenze di “English_United States.1252” in “en_US.UTF-8”. Ciò garantisce che non vi siano errori dovuti a una locale mancante durante l'esecuzione dello script.
- Cambia il comando "DROP DATBASE dvdrental" in "DROP DATBASE IF EXISTS dvdrental", in modo che non vengano visualizzati errori di database non validi.
# 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
Successivamente, passiamo all'utente postgres ed eseguiamo il seguente comando dal prompt della shell:
$ psql -U postgres -d postgres -f /tmp/dvdrental/restore.sql
Ciò ripristina il database di esempio nel nodo primario. Se controlliamo da OmniDB, possiamo vedere che il database è stato creato:
Conclusione
Ora abbiamo un cluster PostgreSQL completamente funzionante e un'istanza OmniDB in esecuzione in AWS. OmniDB può connettersi a entrambi i nodi del cluster. Abbiamo anche ripristinato un database nel nodo primario che viene replicato in standby.
La configurazione dell'ambiente è ora completa. Nella seconda parte di questo articolo, inizieremo a creare un dashboard di monitoraggio delle prestazioni per l'istanza principale.
