OmniDB to graficzne narzędzie do zarządzania bazami danych typu open source opracowane przez firmę 2ndQuadrant, światowego lidera technologii i usług PostgreSQL. OmniDB to oparte na przeglądarce, uniwersalne narzędzie klienckie, które może zarządzać głównymi silnikami baz danych, takimi jak PostgreSQL, MariaDB, MySQL i Oracle. Inne silniki, które wkrótce będą obsługiwane, to SQLite, Firebird, MS SQL Server i IBM DB2.
Jak każde doskonałe oprogramowanie klienckie bazy danych, OmniDB zapewnia również użytkownikom kilka wspaniałych funkcji. Obejmują one możliwość tworzenia i dostosowywania pulpitów nawigacyjnych monitorowania wydajności bazy danych. W tej dwuczęściowej serii artykułów dowiemy się, jak używać wbudowanych jednostek monitorujących OmniDB – powszechnie znanych jako „widżety” w terminologii pulpitu nawigacyjnego – do tworzenia pulpitów nawigacyjnych do sprawdzania stanu wydajności dla klastra replikacji PostgreSQL 12.
Środowisko testowe
Nasze środowisko testowe to dwuwęzłowy klaster PostgreSQL 12 działający w AWS VPC w regionie us-east-1. VPC obejmuje trzy strefy dostępności i trzy podsieci. Każda podsieć znajduje się w oddzielnej Strefie Dostępności (AZ). Węzeł podstawowy i zapasowy znajdują się w dwóch z tych podsieci. Oba węzły są typu instancji t2.large EC2 i będą działać z otwartym kodem źródłowym PostgreSQL 12. Węzeł podstawowy zostanie zreplikowany do węzła rezerwowego.
Pojawi się również „węzeł monitorujący” z najnowszą wersją narzędzia do zarządzania bazą danych OmniDB firmy 2ndQuadrant. Ten węzeł nie będzie częścią klastra PostgreSQL, ale będzie hostowany w trzeciej podsieci VPC, w innym AZ. OmniDB będzie mógł łączyć się zarówno z węzłem głównym, jak i węzłem rezerwowym i sprawdzać ich wydajność. Węzeł OmniDB będzie instancją t2.medium EC2.
Wszystkie trzy węzły będą działały pod kontrolą systemu Red Hat Enterprise Linux (RHEL) 8. Poniższy obraz przedstawia uproszczoną architekturę:
Scenariusz testowy
Po skonfigurowaniu klastra i OmniDB zarejestrujemy oba węzły PostgreSQL w OmniDB. Następnie zapoznamy się z niektórymi standardowymi jednostkami monitorowania w OmniDB i zobaczymy metryki wydajności z obu węzłów klastra. Następnie uruchomimy test obciążenia w węźle podstawowym za pomocą pgbench. W idealnym przypadku test obciążenia powinien zostać zainicjowany z oddzielnej maszyny, ale w tym przypadku uruchomimy go lokalnie. Zobaczymy wtedy, jak panel monitorowania OmniDB pokazuje zmiany w różnych licznikach wydajności wraz ze zmianą obciążenia.
Konfigurowanie środowiska
Krok 1:Instalowanie klastra replikacji PostgreSQL 12
Aby utworzyć dwuwęzłowy klaster PostgreSQL, postępujemy zgodnie z krokami opisanymi we wcześniej opublikowanym blogu 2ndQuadrant. Czytelnik może zapoznać się z tym artykułem, aby zobaczyć, jak zainstalowaliśmy trzywęzłowy klaster z węzłem-świadkiem przy użyciu innego produktu drugiego kwadrantu o nazwie repmgr . W naszej obecnej konfiguracji wykonujemy te same kroki, używając repmgr do utworzenia klastra dwuwęzłowego zamiast trzywęzłowego. Ponadto klaster replikacji nie będzie miał żadnego węzła-świadka. Aby uprościć sprawę, ten artykuł nie pokazuje szczegółowych kroków instalacji i konfiguracji.
Po skonfigurowaniu naszego klastra możemy potwierdzić jego działanie, odpytując widok pg_stat_replication z węzła podstawowego:
SELECT username, client_addr, application_name, state, sent_lsn, write_lsn,replay_lsnFROM pg_stat_replication;
Krok 2:Instalacja i konfiguracja serwera OmniDB
Dostęp do OmniDB uzyskuje się za pomocą adresu URL, co oznacza, że za kulisami uruchamia własny serwer WWW. Istnieją dwa rodzaje OmniDB:
- Aplikacja OmniDB :Jest to zwykle uruchamiane ze stacji roboczej i zachowuje się jak normalna aplikacja komputerowa. OmniDB uruchamia serwer WWW na losowym porcie i nie ma potrzeby dodatkowej konfiguracji.
- Serwer OmniDB :Służy do instalowania OmniDB na serwerze sieciowym w trybie wielu użytkowników. W trybie serwera możemy określić numer portu dostępu do adresu URL, szyfrowanie adresu URL SSL, równoważenie obciążenia i odwrotny serwer proxy, dostęp przez SSH do węzłów bazy danych oraz tworzenie kont użytkowników w celu uzyskania dostępu.
W naszym scenariuszu testowym zainstalujemy serwer OmniDB w węźle OmniDB EC2. Najpierw pobieramy najnowszy pakiet ze strony OmniDB:
# wget https://www.omnidb.org/dist/2.17.0/omnidb-server_2.17.0-centos7-amd64.rpm
Następnie rozpoczynamy instalację. Tutaj instalujemy OmniDB jako użytkownik root, ale możesz użyć dowolnego innego użytkownika, o ile ma on odpowiednie uprawnienia:
# rpm -ivh omnidb-server_2.17.0-centos7-amd64.rpmVerifying... ############################# #### [100%]Przygotowywanie... ############################### [100%]Aktualizacja / instalowanie... 1:omnidb-server-2.17.0-0 ################################# [ 100%]
Po zainstalowaniu pakietu możemy uruchomić OmniDB z wiersza poleceń:
# omnidb-server
Pokazuje serwer startujący:
Uruchamianie websocket OmniDB...Sprawdzanie dostępności portu...Uruchamianie serwera websocket na porcie 25482 .Uruchamianie serwera OmniDB...Sprawdzanie dostępności portu...Uruchamianie serwera OmniDB 2.17.0 o godzinie 127.0.0.1:8000 .Rozpoczęcie migracji bazy danych użytkowników z wersji 0.0.0 do wersji 2.17.0...OmniDB pomyślnie zmigrowało bazę użytkowników z wersji 0.0.0 do wersji 2.17.0Otwórz OmniDB w swojej ulubionej przeglądarce Naciśnij Ctrl+C, aby wyjść
Widzimy, że OmniDB wybrał domyślny port serwera WWW 8000 i domyślny serwer gniazda WWW na porcie 25482.
Naciskamy Ctrl+C, aby zatrzymać proces serwera i przejść do katalogu domowego użytkownika root. Widzimy ukryty folder o nazwie .omnidb . Pod tym folderem znajduje się podkatalog o nazwie omnidb-server . W podkatalogu omnidb-server znajduje się kilka plików:
# ls -la ~ …drwxr-xr-x. 3 root root 27 czerwca 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/ …-p-p--p--. 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-p--p--. 1 root root 0 Jun 13 02:49 omnidb.db.bak_2.17.0-rw-r--r--. 1 root root 579 13 czerwca 02:49 omnidb.log
Po uruchomieniu procesu serwera OmniDB inicjuje te pliki. Baza danych metadanych OmniDB nazywa się omnidb.db . Jest to baza danych SQLite i zawiera informacje o połączeniach z bazą danych, użytkownikach OmniDB i tak dalej. omnidb.conf plik zawiera opcje konfiguracyjne dla serwera OmniDB. Jeśli otworzymy ten plik w edytorze, wygląda on następująco:
# Plik konfiguracyjny serwera OmniDB [serwer WWW]# Jaki adres nasłuchuje serwer WWW, 0.0.0.0 nasłuchuje wszystkich adresów powiązanych z maszynąadres_słuchania =127.0.0.1 # Port serwera WWW, jeśli port jest używany, zostanie wybrany inny losowy port listening_port =8000 # Port Websocket, jeśli port jest używany, zostanie wybrany inny losowy port websocket_port =25482 # Port External Websocket, użyj tego parametru, jeśli usługa OmniDB nie jest bezpośrednio widoczna przez klienta# external_websocket_port =25482# Parametry bezpieczeństwa# is_ssl =True wymaga parametrów ssl_certificate_file i ssl_key_file# Jest to wysoce zalecane w celu ochrony informacji is_ssl = e b> ssl_certificate_file =/ścieżka/do/pliku_certyfikatu ssl_key_file =/ścieżka/do/pliku_klucza # Zaufane źródła, użyj tego parametru, jeśli OmniDB jest skonfigurowany z SSL i jest dostępny przez inną domenęcsrf_trusted_origins =origin1,origin2,origin3# Ścieżka URL dostępu do OmniDB, domyślnie jest pustapath = [queryserver]# Maksymalna liczba wątków, które mogą być używane przez każde żądanie zaawansowanego wyszukiwania obiektówthread_pool_max_workers =2 # Liczba sekund między każdym żądaniem podania hasła. Domyślnie:30 minutpwd_timeout_total =1800
OmniDB uruchamia dwa procesy serwerowe. Jeden to serwer WWW, który wyświetla interfejs użytkownika, drugi to serwer websocket. Serwer websocket jest używany przez kilka funkcji aplikacji, takich jak zapytania, konsola i debugowanie.
Z pliku konfiguracyjnego widzimy, że domyślnie serwer OmniDB akceptuje ruch lokalny (127.0.0.1) na porcie serwera WWW 8000. Zmienimy to na WSZYSTKIE adresy IP. O ile maszyna nie znajduje się za odwrotnym serwerem proxy, zdecydowanie zaleca się stosowanie szyfrowania SSL dla połączeń HTTP z serwerem. Jednak w naszym przykładzie zostawimy is_ssl parametr na „Fałsz”, ponieważ zniszczymy tę maszynę po zakończeniu naszych testów. Zmienimy również port serwera WWW na 8080 i zachowamy domyślną wartość portu serwera websocket 25482.
Po wprowadzeniu zmian plik konfiguracyjny powinien wyglądać tak:
Po wprowadzeniu i zapisaniu zmian uruchamiamy kolejną aplikację o nazwie omnidb-config-server . To narzędzie może być użyte do wykonania dodatkowej konfiguracji, takiej jak:
- Odkurzanie bazy danych SQLite Baza danych OmniDB
- Zresetuj starą bazę danych i utwórz nową
- Usuń pliki tymczasowe
- Utwórz nowy katalog domowy dla bazy danych i pliku konfiguracyjnego
- Utwórz superużytkownika do logowania się do OmniDB
Chociaż będziemy logować się do OmniDB przy użyciu konta administratora, które jest tworzone domyślnie, utworzymy tutaj kolejnego superużytkownika. Może to być przydatne, jeśli chcemy tworzyć indywidualne konta DBA w OmniDB. Poniższy fragment pokazuje to:
# omnidb-config-server --createsuperuser=dba [email protected]$$w0rd123Tworzenie superużytkownika...Utworzono superużytkownika.
Po utworzeniu superużytkownika ponownie rozpoczynamy proces omnidb-server:
# omnidb-serverUruchamianie serwera OmniDB websocket...Sprawdzanie dostępności portu...Uruchamianie serwera Websocket na porcie 25482.Uruchamianie serwera OmniDB...Sprawdzanie dostępności portu...Uruchamianie serwera OmniDB 2.17.0 o godzinie 0.0.0.0:8080. Baza danych użytkowników w wersji 2.17.0 jest już zgodna z wersją serwera.Otwórz OmniDB w swojej ulubionej przeglądarce Naciśnij Ctrl+C, aby wyjść
Zanim uzyskamy dostęp do interfejsu OmniDB, dodamy również port 8080 i port 25482 do grupy bezpieczeństwa instancji EC2:
Krok 3:Dostęp do interfejsu OmniDB
Przeglądanie do adresu publicznego i węzła OmniDB wyświetla teraz ekran logowania:
Określamy domyślną nazwę użytkownika „admin” i jego hasło „admin”. To pozwala nam zalogować się do głównego interfejsu OmniDB. Pierwszy ekran jest pokazany poniżej:
Następnie klikamy ikonę „Zarządzaj użytkownikami” w prawym górnym rogu ekranu:
I zmień domyślne hasło administratora:
Po zakończeniu klikamy przycisk „Zapisz dane”, aby zaktualizować hasło. Jak widać, z tego ekranu możemy również tworzyć nowych użytkowników.
W lewym górnym rogu ekranu klikamy link „Połączenia”, a następnie w wyświetlonym oknie dialogowym klikamy przycisk „Nowe połączenie”:
Następnie określamy szczegóły połączenia dla głównego węzła PostgreSQL i klikamy przycisk „Zapisz dane”:
Po zapisaniu połączenia klikamy ikonę połączenia (zielony znacznik wyboru) w kolumnie „Działania”.
Spowoduje to otwarcie nowej zakładki pokazującej połączenie z bazą danych. Jak pokazano tutaj, jesteśmy połączeni z głównym węzłem PostgreSQL tutaj:
Postępujemy zgodnie z tym samym procesem, aby zarejestrować węzeł gotowości:
Krok 4:Przywracanie przykładowej bazy danych
Przywracamy teraz przykładową bazę danych w podstawowej instancji PostgreSQL. Ta baza danych nazywa się „DVDRental” i można ją bezpłatnie pobrać ze strony samouczka PostgreSQL. Rozpakowaliśmy pobrany plik i rozpakowaliśmy pliki źródłowe do podkatalogu w folderze /tmp węzła podstawowego:
[przykł[email protected] dvdrental] # ls -latotal 2796drwxr-xr-x. 2 root root 280 16 czerwca 11:32 .drwxrwxrwt. 9 root root 257 16 czerwca 11:31 ..-rw-------. 1 postgres postgres 57147 12 maja 2019 3055.dat-rw-------. 1 postgres postgres 8004 12 maja 2019 3057.dat-rw-------. 1 postgres postgres 483 12 maja 2019 3059.dat-rw-------. 1 postgres postgres 333094 12 maja 2019 3061.dat-rw-------. 1 postgres postgres 149469 12 maja 2019 3062.dat-rw-------. 1 postgres postgres 26321 12 maja 2019 3063.dat-rw-------. 1 postgres postgres 46786 12 maja 2019 3065.dat-rw-------. 1 postgres postgres 21762 12 maja 2019 3067.dat-rw-------. 1 postgres postgres 3596 12 maja 2019 3069.dat-rw-------. 1 postgres postgres 140422 12 maja 2019 3071.dat-rw-------. 1 postgres postgres 263 12 maja 2019 3073.dat-rw-------. 1 postgres postgres 718644 12 maja 2019 3075.dat-rw-------. 1 postgres postgres 1214420 12 maja 2019 3077.dat-rw-------. 1 postgres postgres 271 12 maja 2019 3079.dat-rw-------. 1 postgres postgres 57 12 maja 2019 3081.dat-rw-------. 1 postgres postgres 45872 12 maja 2019 r. restore.sql-rw-------. 1 postgres postgres 55111 12 maja 2019 toc.dat
Następnie uruchamiamy następujące polecenia powłoki w podstawowej instancji PostgreSQL (PG-Node1). Te polecenia wprowadzają pewne zmiany w pliku restore.sql:
- Usuń wszystkie wystąpienia „$$PATH$$/”. Dzięki temu skrypt może znaleźć wszystkie pliki danych w tym samym katalogu
- Zmień wszystkie wystąpienia „English_United States.1252” na „en_US.UTF-8”. Zapewnia to brak błędów spowodowanych brakiem lokalizacji podczas działania skryptu.
- Zmień polecenie „DROP DATBASE dvdrental” na „DROP DATBASE IF EXISTS dvdrental”, aby nie wyświetlał się błąd nieprawidłowej bazy danych.
# 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 JEŚLI ISTNIEJE dvdrental;/g' /tmp/dvdrental/restore.sql
Następnie przełączamy się na użytkownika postgres i uruchamiamy następujące polecenie z wiersza poleceń:
$ psql -U postgres -d postgres -f /tmp/dvdrental/restore.sql
Spowoduje to przywrócenie przykładowej bazy danych w węźle podstawowym. Jeśli sprawdzimy z OmniDB, zobaczymy, że baza danych została utworzona:
Wniosek
Mamy teraz w pełni działający klaster PostgreSQL oraz instancję OmniDB działającą w AWS. OmniDB może łączyć się z obydwoma węzłami klastra. Przywróciliśmy również bazę danych w węźle podstawowym, który jest replikowany do rezerwowego.
Konfiguracja środowiska została zakończona. W drugiej części tego artykułu zaczniemy tworzyć panel monitorowania wydajności dla głównej instancji.
