Zakładając, że PEM został zainstalowany już podczas wstępnej instalacji EDB, to w celu uruchomienia tego narzędzia wystarczy uruchomić skrypt konfiguracyjny:
/usr/edb/pem/bin/configure-pem-server.sh
Skrypt grzecznie pyta o wszelkie opcje konfiguracyjne. Na moim testowym serwerze wyglądało to tak: Czytaj dalej »
Aby skonfigurować Profilera w pierwszej kolejności należy zmodyfikować opcję shared_preload_libraries w postgresql.conf. Modyfikacja polega na dodaniu $libdir/sql-profiler,$libdir/index_advisor
Niestety ta modyfikacja wymaga wykonania restartu serwera
pg_ctl restart
Po restarcie można skontrolować ustawienie z posiomu psql:
edb=# select name, setting from pg_settings where name = 'shared_preload_libraries'; name | setting --------------------------+---------------------------------------------------------------------------------------------- shared_preload_libraries | $libdir/dbms_pipe,$libdir/edb_gen,$libdir/dbms_aq,$libdir/sql-profiler,$libdir/index_advisor (1 rows)
Kolejny krok, to uruchomienie skryptów, które konfigurują profilera (i przy okazji index advisora)
edb-psql -f /usr/edb/as13/share/contrib/sql-profiler.sql edb edb-psql -f /usr/edb/as13/share/contrib/index_advisor.sql
Teraz można już przejść do PEM. W wersji 13 Profiler znajduje się w Tools >> Server >> SQL Profiler. Po utworzeniu sesji profilera od razy i prawie na żywo można ją obserwować. Prawie na żywo, bo żeby zobaczyć nowe przechwycone polecenia należy kliknąć „Refresh”. Narzędzie pozwala analizować zapytania użytkowników, czas trwania i obciążenie generowane przez te zapytania, a nawet podejrzeć wykorzystane plany zapytań:
Do instalacji PostgreSQL EDB na konkretnej wersji konkretnego systemu operacyjnego trzeba używać odpowiednich paczek instalacyjnych i uruchamiać je w odpowiedniej kolejności z dobrze dobranymi parametrami. To bywa kłopotliwe.
Na szczęście EDB udostępnia stronę, na której wystarczy wybrać żądane parametry instalacji, a sam skrypt instalacyjny zostanie wygenerowany automatycznie. Np. tak wygląda instalacja na Red Hat 8:
# Install the repository configuration
dnf -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm
# Replace 'USERNAME:PASSWORD' below with your username and password for the EDB repositories
# Visit https://www.enterprisedb.com/user to get your username and password
sed -i "s@<username>:<password>@USERNAME:PASSWORD@" /etc/yum.repos.d/edb.repo
# Install EPEL repository
dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
# Enable the codeready-builder-for-rhel-8-*-rpms repository since EPEL packages may depend on packages from it
ARCH=$( /bin/arch )
subscription-manager repos --enable "codeready-builder-for-rhel-8-${ARCH}-rpms"
# Disable the built-in PostgreSQL module:
dnf -qy module disable postgresql
# Install selected packages
dnf -y install edb-as13-server edb-pem
# Initialize Database cluster
PGSETUP_INITDB_OPTIONS="-E UTF-8" /usr/edb/as13/bin/edb-as-13-setup initdb
# Start Database server
systemctl start edb-as-13
# Connect to the database server
# sudo su - enterprisedb
# psql postgres
# Configure PEM
/usr/edb/pem/bin/configure-pem-server.sh
# You can now connect to PEM at https://127.0.0.1:8443/pem
Oto link do strony https://repos.enterprisedb.com/
Podczas instalacji EDB jest potrzebna nazwa użytkownika i haslo, jakie otrzymuje się po rejestracji w EDB. Te dane można odczytać z tej strony:
https://www.enterprisedb.com/user/
Do wylistowania baz danych w clustrze PostgreSQL można użyć skrótowego polecenia
\l
Niestety, od pewnego momentu uruchomienie tego polecenia kończy się błędem:
postgres=# \l ERROR: column d.daticu does not exist LINE 6: d.daticu as "ICU", ^ HINT: Perhaps you meant to reference the column "d.datacl".
Co się stało?
Na serwerze wcześniej był zainstalowany PostgreSQL 13 w wersji Community (czysty postgres).
Później na tym samym serwerze został zainstalowany Enterprise DB Advanced Server (czyli postgres „na sterydach” publikowany przez EDB). Podczas tej instalacji do katalogu /usr/bin został wkopiowany plik psql właśnie od EDB.
EDB budując własną dystrybucję PostgreSQL dodało pewne kolumny do tabel systemowych, w szczególności do tabeli pg_database.
Kiedy uruchamiasz psql, to w pierwszej kolejności jest przeszukiwana ścieżka /usr/bin, więc uruchamiany jest program od EDB. W tym programie skrót „\l” jest skojarzony z zapytaniem, które ma wydobyć z tabeli pg_database kolumnę daticu, a standardowy PostgreSQL jej po prostu nie ma.
Co z tym zrobić? Przede wszystkim należałoby pogrozić palcem EDB, bo to bardzo zły zwyczaj, żeby psuć inne instalacje swoją instalacją. Podstawowa dystrybucja Postgresa postąpiła o wiele mądrzej. Skoro już jednak się stało, jak się stało, to można albo:
/usr/pgsql-13/bin/psql
PATH=/usr/pgsql-13/bin:$PATH
Aby uruchamiając komendy korzystające albo administrujące postgresem, bez wpisywania długich komend z licznymi argumentami, można w środowisku zdefiniować kilka zmiennych środowiskowych. Ich wartości będą wykorzystywane podczas uruchamiania komend:
PGDATA – ścieżka wskazująca na lokalizację katalogu data, np.: /var/lib/pgsql/13/data
PGPORT – port, na którym nasłuchuje serwer, np. 5432
PGUSER – nazwa użytkownika, którą należy wykorzystywać, np.: postgres
PGDATABASE – domyślna baza danych, np. postgres
Nie zapominajmy też o zmiennej systemowej PATH, która powinna zawierać odnośnik do katalogu bin np. /usr/pgsql-13/bin
Odpowiednie polecenia można umieścić w pliku profilu użytkownika .bash_profile
PATH=$PATH:/usr/pgsql-13/bin PGDATA=/var/lib/pgsql/13/data export PGDATA export PATH export PGPORT=5432
Istnieje jednak ryzyko, że podczas konfiguracji, aktualizacji, reinstalacji PostgreSQL, ten plik może zostać zamazany. Na szczęście w pliku powinna znaleźć się również taka linijka:
# If you want to customize your settings, # Use the file below. This is not overridden # by the RPMS. [ -f /var/lib/pgsql/.pgsql_profile ] && source /var/lib/pgsql/.pgsql_profile
Dlatego zdecydowanie lepiej będzie umieścić własne definicje zmiennych środowiskowych w pliku .pgsql_profile
Komenda lsof pozwala na wyświetlenie otwartych na systemie plików. Taka informacja przydaje się czasami. Np. kiedy chcesz odmontować system plików, ale jakiś proces otworzył plik w tym systemie plików i blokuje twoją operację.
Ponieważ w Linuxie wszystko jest plikiem, to można sprawdzić, czy jakiś proces otworzył zasoby związane z siecią. Dlatego żeby sprawdzić na jakich portach nasłuchują lokalne procedy można posłużyć się komendą:
lsof -i -P -n | grep LISTEN
Za co odpowiadają opcje?
-i listuje tylko pliki związane z zasobami sieciowymi
-P powstrzymuje komendę przed zamianą numeru portu na jego dobrze znaną nazwę, jak np http, ssh itp.
-n powstrzymuje komendę przez zamianą adresu IP na skojarzoną z nim nazwę
Oto przykładowy wynik:
[root@dbserv10 ~]# lsof -i -P -n | grep LISTEN systemd-r 704 systemd-resolve 12u IPv4 15140 0t0 TCP *:5355 (LISTEN) systemd-r 704 systemd-resolve 14u IPv6 15143 0t0 TCP *:5355 (LISTEN) postmaste 1051 postgres 6u IPv4 25950 0t0 TCP *:5432 (LISTEN) postmaste 1051 postgres 7u IPv6 25951 0t0 TCP *:5432 (LISTEN) sshd 6436 root 4u IPv4 44026 0t0 TCP *:22 (LISTEN) sshd 6436 root 6u IPv6 44028 0t0 TCP *:22 (LISTEN) edb-postm 14602 enterprisedb 6u IPv4 153377 0t0 TCP *:5444 (LISTEN) edb-postm 14602 enterprisedb 7u IPv6 153378 0t0 TCP *:5444 (LISTEN)
Oto pełny komunikat błędu:
[root@dbserv10 ~]# dnf -y install edb-as13-server edb-pem
Updating Subscription Management repositories.
Unable to read consumer identity
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Extra Packages for Enterprise Linux Modular 8.2 140 kB/s | 70 kB 00:00
Errors during downloading metadata for repository 'epel-modular’:
– Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 18.159.254.57)
– Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 18.185.136.17)
– Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 85.236.55.6)
Error: Failed to download metadata for repo 'epel-modular’: Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 18.185.136.17)
W pliku /etc/yum/vars/releasever można „na sztywno” zdefiniować release, dla którego należy dopasować pakiety podczas instalacji. Tymczasem w plikach repo, jest wykorzystywana zmienna $releasever, z domyślną wartością „8” (w przypadku RedHat 8).
Jeśli instalacja odbywa się w oparciu o takie repo, to instalacja kończy się błędem jak powyżej. Żeby wyeliminować błąd wystarczy zamienić w plikach repo $releasever na wartość 8. Można to zrobić poleceniem sed:
sed -i 's/$releasever/8/g' /etc/yum.repos.d/epel-modular.repo
