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:

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

Niestety,  od pewnego momentu uruchomienie tego polecenia kończy się błędem:

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:

• uruchamiać psql podając pełną ścieżkę do tej komendy

• zmodyfikować zmienną PATH, tak aby ścieżka wskazująca na /usr/pgsql-13/bin znalazła się przed /usr/bin. Generalnie nie jest to zalecane, bo… w ten sposób można „przykryć” inne polecenia systemowe, ale… polecenia postgresa są specyficzne (nie przykryją innych komend systemu), a ponadto zmiana jest wykonywana tylko dla jednego użytkownika, no więc… można zaryzykować. Najłatwiej zrobić to w .bash_profile, lub jeśli korzystasz z pgsql_profile, to tam:

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

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:

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ą:

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:

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:

Domyślne opcje polecenia find związane z szukaniem pliku po dacie modyfikacji pracują z wykorzystaniem okresów 24-godzinnych. Zazwyczaj to nie problem, bo np. usuwając stare pliki z katalogu /tmp można jako kryterium przyjąć „pliki starsze niż 30 dni”. To czy plik zmodyfikowany o 9:30 złapie się do usunięcia dzisiaj czy jutro nie ma żadnego znaczenia 🙂

Co jednak zrobić jeśli chcesz z jakiegoś powodu znaleźć pliki zmodyfikowane w określonym czasie (godzina, minuta, sekunda)? Otóż z pomocą przychodzi parameter -newerXY.

Szczegóły znajdziesz w helpie, a tutaj przykładowa komenda wyszukująca pliki zmodyfikowane między 9:30, a 9:32

Jeśli stworzyłeś kilka tablespace w bazie postgresql i chcesz sporządzić kopię korzystając z pg_basebackup w formacie plain, to możesz spotkać problem w postaci błędu:

O co chodzi?

Backup w formacie plain kopiuje pliki i katalogi 1-1. Nie ma problemu z danymi znajdującymi się w katalogu data clustra SQL. Tutaj Postgres jest na tyle mądry, że wie, że należy go przekopiować do katalogu z kopią. Niestety co do pozostały tablespace, domyślnie jest tak, że kopia katalogu ma być wykonana w tym samym miejscu (sic!). Tego się oczywiście nie da zrobić wykonując kopię lokalnie na maszynie z zainstalowanym postgresem. Wydaje mi się to co najmniej dziwne, że taka jest logika wykonywania kopii, ale najwyraźniej chłopaki, którzy to robili mieli ku temu jakieś istotne powody – nie wnikam w to.

Jak obejść ten problem?

Na całe szczęście mamy w poleceniu pg_basebackup opcję, która pozwala wskazać do jakich katalogów mają być zapisane odpowiednie tablespace. Jest to opcja T. W tym przypadku komenda mogła by wyglądać tak:

Tablespace znajdujący się w katalogu /home/4pg/app_data zostanie teraz skopiowany do /home/pg_archives/sunday_plain/app_data i podobnie będzie z katalogiem /home/4pg/temp_tblspc, który zostanie skopiowany do /home/pg_archives/sunday_plain/temp_tblspc.

Dziękuję za wskazówki na innych blogach i forach:

https://www.percona.com/blog/2018/12/21/backup-restore-postgresql-cluster-multiple-tablespaces-using-pg_basebackup/

https://programmer.ink/think/introduction-to-temporary-tablespaces-of-postgresql-and-greenplum.html

pg_basebackup: error: directory “dir_abc” exists but is not empty OR ERROR: tablespace “ABC” is not empty