OmniDB je grafický nástroj pro správu databází s otevřeným zdrojovým kódem vyvinutý společností 2ndQuadrant, světovým lídrem v technologiích a službách PostgreSQL. OmniDB je univerzální klientský nástroj založený na prohlížeči, který dokáže spravovat hlavní databázové stroje jako PostgreSQL, MariaDB, MySQL a Oracle. Mezi další motory, které budou brzy podporovány, patří SQLite, Firebird, MS SQL Server a IBM DB2.
Jako každý vynikající databázový klientský software, OmniDB také umožňuje uživatelům některé skvělé funkce. Patří mezi ně možnost vytvářet a přizpůsobovat řídicí panely sledování výkonu databáze. V této dvoudílné sérii článků se naučíme, jak používat vestavěné monitorovací jednotky OmniDB – běžně známé jako „widgety“ v podmínkách řídicích panelů – k vytváření řídicích panelů pro kontrolu stavu výkonu pro replikační cluster PostgreSQL 12.
Testovací prostředí
Naše testovací prostředí je dvouuzlový cluster PostgreSQL 12, běžící na AWS VPC v regionu us-east-1. VPC se rozprostírá přes tři zóny dostupnosti a má tři podsítě. Každá podsíť je v samostatné zóně dostupnosti (AZ). Primární a záložní uzel jsou umístěny ve dvou z těchto podsítí. Oba uzly jsou typu instance t2.large EC2 a poběží open-source PostgreSQL 12. Primární uzel se replikuje do pohotovostního uzlu.
K dispozici bude také „monitorovací uzel“, na kterém bude spuštěna nejnovější verze nástroje pro správu databází OmniDB společnosti 2ndQuadrant. Tento uzel nebude součástí clusteru PostgreSQL, ale bude hostován ve třetí podsíti VPC, v jiném AZ. OmniDB se bude moci připojit k hlavnímu i záložnímu uzlu a zkontrolovat jejich výkon. Uzel OmniDB bude instancí t2.medium EC2.
Všechny tři uzly poběží Red Hat Enterprise Linux (RHEL) 8. Obrázek níže ukazuje zjednodušenou architekturu:
Testovací scénář
Jakmile máme nastaven cluster a OmniDB, zaregistrujeme oba uzly PostgreSQL v OmniDB. Poté se seznámíme s některými standardními monitorovacími jednotkami v OmniDB a prohlédneme si metriky výkonu z obou uzlů clusteru. Poté spustíme zátěžový test v primárním uzlu pomocí pgbench. V ideálním případě by zátěžový test měl být spuštěn ze samostatného počítače, ale v tomto případě jej spustíme lokálně. Potom uvidíme, jak monitorovací panel OmniDB ukazuje změny v různých čítačech výkonu při změně zatížení.
Nastavení prostředí
Krok 1:Instalace replikačního clusteru PostgreSQL 12
Chcete-li vytvořit dvouuzlový cluster PostgreSQL, postupujeme podle kroků popsaných v dříve publikovaném blogu 2ndQuadrant. Čtenář se může v tomto článku podívat, jak jsme nainstalovali tříuzlový cluster s uzlem svědka pomocí jiného produktu 2ndQuadrant s názvem repmgr . Pro naše aktuální nastavení postupujeme podle stejných kroků pomocí repmgr k vytvoření dvouuzlového clusteru namísto tříuzlového. Cluster replikace také nebude mít žádný uzel svědka. Aby to bylo jednoduché, tento článek neuvádí podrobné kroky instalace a konfigurace.
Jakmile je náš cluster nastaven, můžeme potvrdit jeho fungování dotazem na pohled pg_stat_replication z primárního uzlu:
SELECT usename, client_addr, application_name, state, sent_lsn, write_lsn, replay_lsnFROM pg_stat_replication;
Krok 2:Instalace a konfigurace serveru OmniDB
OmniDB je přístupný pomocí adresy URL, což znamená, že na pozadí provozuje vlastní webový server. Existují dvě varianty OmniDB:
- Aplikace OmniDB :Obvykle se spouští z pracovní stanice a chová se jako běžná desktopová aplikace. OmniDB spouští webový server na náhodném portu a není nutné žádné další nastavení.
- Server OmniDB :Toto je pro instalaci OmniDB na síťový server pro víceuživatelský režim. V režimu serveru můžeme zadat číslo portu pro přístup k URL, SSL šifrování URL, vyvažování zátěže a reverzní proxy, SSH průchozí přístup k databázovým uzlům a vytváření uživatelských účtů pro přístup.
Pro náš testovací scénář nainstalujeme server OmniDB do uzlu OmniDB EC2. Nejprve stahujeme nejnovější balíček z webu OmniDB:
# wget https://www.omnidb.org/dist/2.17.0/omnidb-server_2.17.0-centos7-amd64.rpm
Dále zahájíme instalaci. Zde instalujeme OmniDB jako uživatel root, ale můžete použít jakéhokoli jiného uživatele, pokud má správná práva:
# rpm -ivh omnidb-server_2.17.0-centos7-amd64.rpmOvěřování... ############################ #### [100%]Příprava... ################################ [100%]Aktualizace / instalace... 1:omnidb-server-2.17.0-0 ################################# [ 100 %]
Jakmile je balíček nainstalován, můžeme spustit OmniDB z příkazového řádku:
# omnidb-server
Toto ukazuje, že server začíná:
Spouštění websocketu OmniDB...Kontrola dostupnosti portu...Spouštění serveru websocket na portu 25482 .Spouštění serveru OmniDB...Kontrola dostupnosti portu...Spouštění serveru OmniDB 2.17.0 na 127.0.0.1:8000 .Spouštění migrace uživatelské databáze z verze 0.0.0 na verzi 2.17.0...OmniDB úspěšně migroval uživatelskou databázi z verze 0.0.0 na verzi 2.17.0Otevřete OmniDB ve svém oblíbeném prohlížečiStiskněte Ctrl+C pro ukončení
Můžeme vidět, že OmniDB zvolil výchozí port webového serveru 8000 a výchozí server websocket na portu 25482.
Stisknutím kláves Ctrl+C zastavíme proces serveru a přejdeme do domovského adresáře uživatele root. Vidíme, že existuje skrytá složka s názvem .omnidb . Pod touto složkou se nachází podadresář s názvem omnidb-server . Uvnitř podadresáře omnidb-server je několik souborů:
# ls -la ~ …drwxr-xr-x. 3 root root 27. června 13 02:49 .omnidb ……# ls -la ~/.omnidb …drwxr-xr-x. 2 root root 106. června 13 02:49 omnidb-server # ls -la ~/.omnidb/omnidb-server/ …-rw-r--r--. 1 kořenový kořen 131072 13. června 02:49 db.sqlite3-rw-r--r--. 1 kořenový kořen 1209 13. června 02:49 omnidb.conf -rw-r--r--. 1 kořenový kořen 116736 13. června 02:49 omnidb.db -rw-r--r--. 1 kořenový kořen 0 13. června 02:49 omnidb.db.bak_2.17.0-rw-r--r--. 1 kořenový kořen 579 13. června 02:49 omnidb.log
Jakmile se spustí proces serveru, OmniDB tyto soubory inicializuje. Databáze metadat OmniDB se nazývá omnidb.db . Toto je databáze SQLite a obsahuje informace o databázových připojeních, uživatelích OmniDB a tak dále. Soubor omnidb.conf obsahuje konfigurační možnosti pro server OmniDB. Pokud tento soubor otevřeme v editoru, vypadá následovně:
# Konfigurační soubor serveru OmniDB[webserver]# Na jaké adrese webový server naslouchá, 0.0.0.0 naslouchá všem adresám vázaným na strojadresa_poslechu =127.0.0.1 # Port webového serveru, pokud je používán port, bude vybrán jiný náhodný portlistening_port =8000 # Port Websocket, pokud se používá port, bude vybrán jiný náhodný portport_websocket =25482 # Externí port Websocket, použijte tento parametr, pokud OmniDB není přímo viditelný klientem# external_websocket_port =25482# Parametry zabezpečení# is_ssl =True vyžaduje parametry ssl_certificate_file a ssl_key_file# Toto se důrazně doporučuje pro ochranu informacíis_ssl Fal b> ssl_certificate_file =/cesta/k/souboru_certifikátu ssl_key_file =/cesta/k/souboru_klíčů # Důvěryhodné zdroje, použijte tento parametr, pokud je OmniDB nakonfigurován s SSL a přistupuje k němu jiná doménacsrf_trusted_origins =origin1,origin2,origin3# Cesta URL pro přístup k OmniDB, výchozí je prázdnácesta = [queryserver]# Maximální počet vláken, která může použít každý požadavek na pokročilé vyhledávání objektůthread_pool_max_workers =2 # Počet sekund mezi každou výzvou k zadání hesla. Výchozí:30 minutpwd_timeout_total =1800
OmniDB provozuje dva serverové procesy. Jedním je webový server, který zobrazuje uživatelské rozhraní, druhým je websocket server. Websocket server používá několik funkcí aplikace, jako je dotaz, konzole a ladění.
Z konfiguračního souboru můžeme vidět, že ve výchozím nastavení OmniDB server přijímá místní provoz (127.0.0.1) na portu webového serveru 8000. Změníme to na VŠECHNY IP adresy. Pokud počítač není za reverzním proxy, důrazně se doporučuje používat pro připojení HTTP k serveru šifrování SSL. V našem příkladu však ponecháme is_ssl parametr na „False“, protože po dokončení testů tento stroj zničíme. Změníme také port webového serveru na 8080 a port serveru websocket ponecháme na výchozí hodnotě 25482.
Po provedení změn by konfigurační soubor měl vypadat takto:
Po provedených a uložených změnách spustíme další aplikaci s názvem omnidb-config-server . Tento nástroj lze použít k provedení některých dalších konfigurací, například:
- Vakuování databáze SQLite databáze OmniDB
- Obnovte starou databázi a vytvořte novou
- Smažte dočasné soubory
- Vytvořte nový domovský adresář pro databázi a konfigurační soubor
- Vytvořte superuživatele pro přihlášení do OmniDB
Přestože se do OmniDB přihlásíme pomocí uživatelského účtu správce, který je vytvořen ve výchozím nastavení, vytvoříme zde dalšího superuživatele. To může být užitečné, pokud chceme vytvořit jednotlivé účty DBA v OmniDB. Níže uvedený úryvek ukazuje toto:
# omnidb-config-server --createsuperuser=dba [email protected]$$w0rd123Vytváření superuživatele...Superuser vytvořen.
S vytvořeným superuživatelem znovu spustíme proces omnidb-server:
# omnidb-serverSpouštění websocketu OmniDB...Kontrola dostupnosti portu...Spouštění serveru websocket na portu 25482.Spouštění serveru OmniDB...Kontrola dostupnosti portu...Spouštění serveru OmniDB 2.17.0 na 0.0.0.0:8080. Verze uživatelské databáze 2.17.0 již odpovídá verzi serveru. Otevřete OmniDB ve svém oblíbeném prohlížeči Stisknutím Ctrl+C ukončete
Než přistoupíme k rozhraní OmniDB, přidáme také port 8080 a port 25482 do skupiny zabezpečení instance EC2:
Krok 3:Přístup k rozhraní OmniDB
Při procházení veřejné adresy a uzlu OmniDB se nyní zobrazí přihlašovací obrazovka:
Zadáme výchozí uživatelské jméno „admin“ a jeho heslo „admin“. To nám umožní přihlásit se do hlavního rozhraní OmniDB. První obrazovka je zobrazena níže:
Dále klikneme na ikonu „Spravovat uživatele“ v pravém horním rohu obrazovky:
A změňte výchozí heslo administrátora:
Po dokončení klikneme na tlačítko „Uložit data“ a aktualizujeme heslo. Jak vidíte, z této obrazovky můžeme také vytvářet nové uživatele.
V levém horním rohu obrazovky klikneme na odkaz „Připojení“ a poté ve výsledném dialogovém okně klikneme na tlačítko „Nové připojení“:
Poté zadáme podrobnosti připojení pro primární uzel PostgreSQL a klikneme na tlačítko „Uložit data“:
Jakmile je připojení uloženo, klikneme na ikonu připojení (zelená značka zaškrtnutí) ve sloupci „Akce“.
Otevře se nová karta zobrazující připojení k databázi. Jak je zde ukázáno, jsme připojeni k primárnímu PostgreSQL uzlu zde:
Při registraci pohotovostního uzlu postupujeme podle stejného procesu:
Krok 4:Obnovení ukázkové databáze
Nyní obnovujeme ukázkovou databázi v primární instanci PostgreSQL. Tato databáze se nazývá „DVDRental“ a je volně ke stažení na webu PostgreSQL Tutorial. Rozbalili jsme stažený soubor a extrahovali zdrojové soubory do podadresáře ve složce /tmp primárního uzlu:
[[email protected] dvdrental] # ls -latotal 2796drwxr-xr-x. 2 root root 280 Jun 16 11:32 .drwxrwxrwt. 9 root root 257 Jun 16 11:31 ..-rw--------. 1 postgres postgres 57147 12. května 2019 3055.dat-rw-------. 1 postgres postgres 8004 12. května 2019 3057.dat-rw-------. 1 postgres postgres 483 12. května 2019 3059.dat-rw-------. 1 postgres postgres 333094 12. května 2019 3061.dat-rw-------. 1 postgres postgres 149469 12. května 2019 3062.dat-rw-------. 1 postgres postgres 26321 12. května 2019 3063.dat-rw-------. 1 postgres postgres 46786 12. května 2019 3065.dat-rw-------. 1 postgres postgres 21762 12. května 2019 3067.dat-rw-------. 1 postgres postgres 3596 12. května 2019 3069.dat-rw-------. 1 postgres postgres 140422 12. května 2019 3071.dat-rw-------. 1 postgres postgres 263 12. května 2019 3073.dat-rw-------. 1 postgres postgres 718644 12. května 2019 3075.dat-rw-------. 1 postgres postgres 1214420 12. května 2019 3077.dat-rw-------. 1 postgres postgres 271 12. května 2019 3079.dat-rw-------. 1 postgres postgres 57 12. května 2019 3081.dat-rw-------. 1 postgres postgres 45872 12. května 2019 restore.sql-rw-------. 1 postgres postgres 55111 12. května 2019 toc.dat
Dále spustíme následující příkazy shellu v primární instanci PostgreSQL (PG-Node1). Tyto příkazy provádějí některé změny v souboru restore.sql:
- Odeberte všechny výskyty „$$PATH$$/“. To zajistí, že skript najde všechny datové soubory ve stejném adresáři
- Změňte všechny výskyty „English_United States.1252“ na „en_US.UTF-8“. To zajišťuje, že při spuštění skriptu nedojde k žádným chybám kvůli chybějícímu národnímu nastavení.
- Změňte příkaz „DROP DATBASE dvdrental“ na „DROP DATBASE IF EXISTS dvdrental“, aby se nezobrazovala žádná neplatná chyba databáze.
# 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ále se přepneme na uživatele postgres a spustíme následující příkaz z příkazového řádku:
$ psql -U postgres -d postgres -f /tmp/dvdrental/restore.sql
Tím se obnoví ukázková databáze v primárním uzlu. Pokud zkontrolujeme z OmniDB, můžeme vidět, že databáze je vytvořena:
Závěr
Nyní máme plně funkční cluster PostgreSQL a instanci OmniDB běžící v AWS. OmniDB se může připojit k oběma uzlům clusteru. Také jsme obnovili databázi v primárním uzlu, který se replikuje do pohotovostního režimu.
Nastavení prostředí je nyní dokončeno. Ve druhé části tohoto článku začneme vytvářet řídicí panel sledování výkonu pro primární instanci.