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

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

find . -newermt '2021-05-30 09:30' -and -not -newermt '2021-05-30 09: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:

[postgres@dbserv10 ~]$ pg_basebackup -Xs -Fp -P -D /home/pg_archives/sunday_plain/
pg_basebackup: error: directory "/home/4pg/app_data" exists but is not empty
pg_basebackup: removing contents of data directory "/home/pg_archives/sunday_plain/"

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:

[postgres@dbserv10 ~]$ pg_basebackup -Xs -Fp -P -D /home/pg_archives/sunday_plain/ 
-T "/home/4pg/app_data=/home/pg_archives/sunday_plain/app_data" 
-T "/home/4pg/temp_tblspc=/home/pg_archives/sunday_plain/temp_tblspc"

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

Zdarza się (często), że w Idle, który jest domyślnym i bodajże najprostszym edytorem skryptów Pythona, nie działają podpowiedzi. Czasami pomaga proste uruchomienie skryptu przed jego dalszym pisaniem (Idle uświadamia sobie wtedy z jakimi zmiennymi ma do czynienie i „zaskakuje”), ale czasami to nie pomaga.

1. Poszukaj w Finder pliku autocomplete_w.py . Jeżeli plików o takiej samej nazwie jest więcej, to pewnie jest zainstalowanych kilka wersji Pythona. W takim przypadku wybierz ten zgodny z właśnie wykorzystywaną wersją (zgodną z Idle) np.:

~/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/idlelib/autocomplete_w.py

2. Otwórz plik autocomplete_w.py i znajdź w nim dwie sąsiadujące linie::

listbox.pack(side=LEFT, fill=BOTH, expand=True)
acw.lift()

3. Wstaw między nie dodatkową linijke::

acw.update_idletasks()

4. Zapisz plik i trzymaj kciuki, aby po naciśnięciu klawisza ⇥ zobaczyć okienko z  autouzupełnieniem

Jedną z popularniejszych usług w Azure są maszyny wirtualne (Virtual Machines – VM). Budując rozwiązanie dla klienta i wpasowując je w jego wymagania, określamy dostępność maszyny. Ten parametr jest wpisany w Service Level Agreement (SLA). Na maszynach wirtualnych mogą być oparte kolejne serwisy i zależnie od zdefiniowanej architektury, te serwisy mogą oferować lepsze SLA. Wejściowym parametrem do obliczenia SLA dla całego rozwiązania pozostaje jednak SLA maszyn wirtualnych. Co mamy do wyboru?

• Pojedynczą maszynę, która oferuje dostępność na poziomie 99.9%
• Dwie lub więcej maszyn w tym samym availability set – 99.95%. Co istotne oznacza to już dostępość dla Availability Set – dostępność pojedynczej maszyny to nadal 99.9%.
• Jeśli by te maszyny rozrzucić jeszcze w różnych availability zones, to ich dostępność wzrośnie do 99.99%.

Co istotne podane tu wartości dotyczą konfiguracji maszyny opartej o storage premium lub ultra. Jeśli zdecydowalibyśmy się korzystać ze standard HDD, to gwarantowany czas dotępności spadnie do 95% w przypadku pojedynczej maszyny.

SLA dotyczy „gołego” systemu operacyjnego, to jakby włączyć w domu laptopa z czystym windows i nic na nim nie robić. Na VM  będzie oczywiście pracować aplikacja i jej dostępność to już inna sprawa. Sama zaś maszyna może być narażona na ataki malware, które również nie są brane pod uwagę przez Microsoft – w końcu samo zarządzanie systemem operacyjnym w modelu IaaS pozostaje po stronie klienta.