Kontrola stávající verze TimescaleDB

Než začnete s aktualizací, zkontrolujte, jakou verzi TimescaleDB máte aktuálně nainstalovanou a aktivní v databázích.

Příkaz pro kontrolu nainstalované verze rozšíření TimescaleDB:

sudo -u postgres psql -c "SELECT default_version, installed_version FROM pg_available_extensions WHERE name = 'timescaledb';"

Tento dotaz zobrazí verze, které jsou dostupné a aktuálně nainstalované. Například, můžete vidět nainstalovanou verzi 2.11.2.

Aktualizace balíčků TimescaleDB

Pro aktualizaci samotných balíčků TimescaleDB, včetně dodatečných komponent jako jsou TimescaleDB tools a TimescaleDB loader, použijte následující příkaz:

sudo dnf upgrade timescaledb-*

Tento příkaz zajistí, že všechny součásti TimescaleDB, které máte nainstalované (včetně nástrojů a loaderu), budou aktualizovány na nejnovější verzi. To vám umožní plně využívat všechny nové funkce a vylepšení, které TimescaleDB nabízí.

Identifikace databází, které používají TimescaleDB

Dalším krokem je identifikace databází, které používají rozšíření TimescaleDB. Můžete to provést pomocí dotazu v PostgreSQL:

sudo -u postgres psql -t -c "SELECT datname FROM pg_database WHERE datistemplate = false;" | 
while read dbname; do 
  sudo -u postgres psql -d "$dbname" -c "SELECT '$dbname' as database, extname as extension FROM pg_extension WHERE extname = 'timescaledb';"; 
done

Tento příkaz prochází všechny databáze (kromě šablonových) a kontroluje, zda obsahují rozšíření TimescaleDB. Pokud ano, vypíše název databáze a rozšíření.

To znamená, že rozšíření TimescaleDB je používáno v databázi zabbix, jak je vidět na řádku s výsledkem (1 row). Tento výstup potvrzuje, že databáze zabbix má aktivní rozšíření TimescaleDB, a je tedy potřeba ji zahrnout do aktualizačního procesu.

Aktualizace rozšíření TimescaleDB v databázích

Po aktualizaci balíčků a identifikaci databází je třeba provést aktualizaci rozšíření TimescaleDB v jednotlivých databázích. To provedete následujícím SQL příkazem pro každou databázi, která používá TimescaleDB:

sudo -u postgres psql -d <vaše_databáze> -c "ALTER EXTENSION timescaledb UPDATE;"

Tento příkaz aktualizuje rozšíření na nejnovější verzi v konkrétní databázi. Ujistěte se, že nahradíte <vaše_databáze> názvem databáze, kterou chcete aktualizovat.

Pokud během aktualizace narazíte na chybu s hláškou:

ERROR: loader version out-of-date
HINT: Please restart the database to upgrade the loader version.

Je potřeba restartovat PostgreSQL server. Ujistěte se, že nahradíte číslo verze v příkazu podle vaší aktuální verze PostgreSQL serveru:

sudo systemctl restart postgresql-<verze>.service

Například pro PostgreSQL 18 použijte:

sudo systemctl restart postgresql-18.service

Po restartu serveru opakujte příkaz pro aktualizaci rozšíření TimescaleDB:

sudo -u postgres psql -d <vaše_databáze> -c "ALTER EXTENSION timescaledb UPDATE;"

Tímto způsobem zajistíte, že rozšíření TimescaleDB bude úspěšně aktualizováno a bude plně funkční.

Restart PostgreSQL serveru po aktualizaci

Po úspěšné aktualizaci rozšíření TimescaleDB je doporučeno restartovat PostgreSQL server, aby byly všechny změny plně aplikovány a nové verze komponent správně načteny.

Ujistěte se, že nahradíte číslo verze v příkazu podle vaší aktuální verze PostgreSQL serveru:

sudo systemctl restart postgresql-<verze>.service

Například pro PostgreSQL 18 použijte:

sudo systemctl restart postgresql-18.service

Tento krok zajistí, že všechny změny, které byly provedeny během aktualizace, budou plně účinné a databázový server bude připraven pro další provoz.

Automatická aktualizace rozšíření TimescaleDB ve všech databázích (volitelný)

Pokud máte více databází, které používají rozšíření TimescaleDB, a chcete automatizovat proces jejich aktualizace, můžete použít následující příkaz. Tento příkaz provede aktualizaci rozšíření TimescaleDB automaticky ve všech databázích, kde je toto rozšíření aktuálně nainstalováno.

Automatická aktualizace rozšíření TimescaleDB

Následující příkaz prohledá všechny databáze na serveru, zkontroluje, zda v nich je nainstalováno rozšíření TimescaleDB, a pokud ano, provede jeho aktualizaci:

sudo -u postgres psql -t -c "SELECT datname FROM pg_database WHERE datistemplate = false;" | 
while read dbname; do 
  if sudo -u postgres psql -d "$dbname" -tAc "SELECT 1 FROM pg_extension WHERE extname = 'timescaledb'" | grep -q 1; then 
    sudo -u postgres psql -d "$dbname" -c "ALTER EXTENSION timescaledb UPDATE;"; 
  fi; 
done

Co tento příkaz dělá:

• Výběr databází: Vybere všechny databáze kromě šablonových (template0 a template1).
• Kontrola rozšíření: U každé databáze nejprve zkontroluje, zda je rozšíření TimescaleDB nainstalováno.
• Aktualizace rozšíření: Pokud je rozšíření TimescaleDB nainstalováno, provede jeho aktualizaci na nejnovější verzi.

Zkopírujte tento kompletní příkaz a spusťte ho v terminálu. Tento příkaz zajistí, že aktualizace proběhne pouze v databázích, kde je rozšíření TimescaleDB aktuálně nainstalováno.

Pokud při pokusu o aktualizaci rozšíření TimescaleDB uvidíte následující chybu:

ERROR: loader version out-of-date
HINT: Please restart the database to upgrade the loader version.

Je potřeba restartovat PostgreSQL server a akci opakovat. Ujistěte se, že nahradíte číslo verze v příkazu podle vaší aktuální verze PostgreSQL serveru:

sudo systemctl restart postgresql-<verze>.service

Například pro PostgreSQL 18 použijte:

sudo systemctl restart postgresql-18.service

Po restartu PostgreSQL serveru a opětovném spuštění příkazu na aktualizaci byste měli vidět potvrzení:

ALTER EXTENSION

Tím se potvrdí, že aktualizace rozšíření TimescaleDB proběhla úspěšně.

Restart aplikací (volitelný)

Po provedení aktualizace je doporučeno restartovat aplikace, které se připojují k databázím s TimescaleDB. Tím zajistíte, že aplikace správně načtou novou verzi rozšíření a předejdete možným problémům s kompatibilitou.

sudo systemctl restart vaše_aplikace

Ověření funkčnosti a optimalizace

Po aktualizaci rozšíření a restartu aplikací zkontrolujte, zda vše funguje podle očekávání. Doporučujeme provést základní dotazy a zkontrolovat, že aplikace pracuje bez problémů.

Navíc můžete provést další optimalizaci, například reindexaci, pokud došlo k významným změnám v datových strukturách nebo indexech.

Další Doporučení

• Testování na testovacím prostředí: Před aktualizací na produkčním prostředí doporučujeme provést testovací aktualizaci na testovacím serveru, abyste minimalizovali riziko problémů v produkci.
• Sledování výkonu: Po aktualizaci sledujte výkon TimescaleDB, abyste zjistili, zda došlo k nějakým změnám, a případně upravte nastavení výkonu podle potřeby.
• Záloha před aktualizací: I když se jedná o menší aktualizaci, doporučujeme provést zálohu databází před provedením změn, abyste měli možnost návratu v případě problémů.
• Procházení changelogu: Seznamte se s novinkami a změnami v nové verzi TimescaleDB, abyste věděli, jaké nové funkce můžete využít a co je potřeba upravit.

Tímto způsobem zajistíte, že aktualizace TimescaleDB proběhne hladce a že vaše databáze budou i nadále plně funkční a optimalizované.

The post Jak na aktualizaci TimescaleDB appeared first on initMAX s.r.o..

Záloha stávající databáze

Před zahájením aktualizace databáze existují dvě možnosti zálohování. Vyberte si tu, která vám více vyhovuje:

• Snapshot virtuálního stroje (VM): 

Pokud používáte PostgreSQL na VM, vytvoření snapshotu celé VM je rychlý a bezpečný způsob zálohy. Tato varianta je zvláště vhodná, pokud používáte různé rozšíření, jako je například TimescaleDB, kde je proces zálohování složitější a není součástí tohoto návodu. Snapshot vám umožní rychle obnovit celý systém do původního stavu, což může být výhodné v případě komplikací během upgradu.

• Klasická záloha databáze pomocí pg_dumpall:

Tato metoda vytvoří textovou zálohu všech databází na serveru.

sudo -u postgres pg_dumpall > /cesta/k/zaloze/zaloha.sql

Důležité: Zkontrolujte, že cesta, kam zálohu ukládáte, má dostatek volného místa. Zálohu je vhodné uložit mimo databázový server (například na síťový disk nebo jiný externí úložiště), aby byla chráněna v případě selhání serveru.

Obě varianty mají své výhody, proto si vyberte tu, která lépe vyhovuje vašim potřebám a prostředí.

Přidání PostgreSQL repozitáře

Pro instalaci nejnovější verze PostgreSQL na RHEL/Rocky Linux 9 je potřeba přidat oficiální PostgreSQL repozitář. Tento krok zajistí, že budete mít přístup k nejnovějším balíčkům PostgreSQL.

Stáhněte a nainstalujte PostgreSQL repozitář RPM balíček:

sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm

Tento balíček přidá do systému oficiální PostgreSQL repozitář.

Zakázání výchozího PostgreSQL modulu:

Distribuce RHEL a Rocky Linux mohou mít ve výchozím nastavení povolený modul PostgreSQL, který může obsahovat starší verze. Abyste zajistili, že se nainstaluje novější verze PostgreSQL z přidaného repozitáře, je třeba zakázat tento výchozí modul:

sudo dnf -qy module disable postgresql

Tímto příkazem zakážete starší moduly PostgreSQL, čímž zajistíte, že se při instalaci použije balíček z přidaného repozitáře.

Po přidání repozitáře a zakázání staršího modulu jste připraveni k instalaci nejnovější verze PostgreSQL.

Instalace nové verze PostgreSQL

Po přidání repozitáře je čas nainstalovat novou verzi PostgreSQL.

Aktualizace seznamu balíčků:

Nejprve aktualizujte seznam balíčků, aby systém získal informace o nejnovějších verzích dostupných v nově přidaném repozitáři PostgreSQL:

sudo dnf update

Instalace nové verze PostgreSQL:

Nainstalujte konkrétní verzi PostgreSQL, kterou chcete používat. Například, pokud instalujete PostgreSQL 18:

dnf install -y postgresql18-server postgresql18-contrib

Tento příkaz nainstaluje potřebné balíčky PostgreSQL serveru, včetně nástrojů pro správu a inicializaci databází.

Inicializace databáze:

Po úspěšné instalaci nové verze PostgreSQL je nutné inicializovat databázový cluster, což vytvoří potřebnou adresářovou strukturu a inicializační soubory. Použijte příkaz pro inicializaci:

sudo /usr/pgsql-18/bin/postgresql-18-setup initdb

Nahraďte verzi „18“ odpovídajícím číslem, pokud instalujete jinou verzi PostgreSQL. Tento krok je důležitý, protože připraví prostředí pro migraci dat ze staré verze.

Poznámka: Je velmi důležité, aby nově inicializovaná databáze měla stejné nastavení jako původní databáze. To znamená, že pokud na staré verzi nebyly povoleny například kontrolní součty datových bloků (checksums), nemůžete je zapnout při inicializaci nové verze. Pokud by nastavení nového clusteru bylo odlišné, mohl by pg_upgrade selhat nebo způsobit problémy při migraci dat.

Důležité: V tomto kroku nespouštějte novou verzi PostgreSQL ihned po instalaci a inicializaci. Pokud byste novou verzi nyní spustili, mohlo by dojít ke kolizi portů, protože stará verze PostgreSQL stále běží na stejném portu (standardně port 5432). Nová verze musí zůstat vypnutá, dokud nedokončíte migraci dat a neprovedete případné úpravy portů nebo nakonfigurujete službu tak, aby běžela vedle stávající instance.

Kontrola dostupného místa na disku

Před provedením upgradu PostgreSQL je důležité zkontrolovat, zda máte dostatek volného místa na disku. Migrace dat může vyžadovat významné množství prostoru, zejména pokud máte velké databáze.

Zkontrolujte volné místo na disku pomocí příkazu:

df -h 

Tento příkaz zobrazí přehled o využití diskového prostoru na jednotlivých oddílech. Zvláštní pozornost věnujte oddílům, kde jsou umístěny databázové soubory a konfigurační soubory PostgreSQL, například /var/lib/pgsql nebo jiný specifický adresář, kde máte uložené databáze.

Odhad potřebného místa:

Upgrady a migrace mohou dočasně vyžadovat dvojnásobek místa než je aktuální velikost databází, protože se během procesu mohou vytvářet dočasné kopie a zálohy dat. Pokud tedy vaše databáze zabírá 50 GB, měli byste mít k dispozici alespoň dalších 50 GB volného místa.

Výjimka: Pokud při migraci použijete parametr -k s nástrojem pg_upgrade, nebudou se vytvářet kopie datových souborů, ale místo toho se použijí hardlinky. To znamená, že nebudete potřebovat tolik volného místa na disku a migrace bude rychlejší. Na druhou stranu, data budou sdílena mezi starým a novým clusterem, což znemožní bezpečné spuštění staré verze PostgreSQL po migraci. Stará data tedy nebudou automaticky zálohována.

Uvolnění místa (volitelně):

Pokud zjistíte, že na disku není dostatek místa, můžete zvážit následující kroky:

• Odstranění nepotřebných souborů a starých záloh.
• Přesun dat na externí úložiště.
• Zvýšení kapacity disku, pokud je to možné.

Dostatečné volné místo na disku je klíčové pro úspěšný upgrade bez přerušení služby nebo ztráty dat.

Instalace rozšíření a přenos konfigurace

Před samotnou migrací dat je klíčové připravit prostředí nové verze PostgreSQL. Tento krok zahrnuje instalaci potřebných rozšíření (extensions) a přenos konfigurace ze staré verze. Správná instalace a konfigurace zajišťují, že po migraci bude databáze fungovat stejně jako předtím, včetně všech specifických nastavení a funkcí.

Instalace rozšíření

Pokud používáte rozšíření v PostgreSQL, například TimescaleDB nebo PostGIS, je důležité nainstalovat stejné verze těchto rozšíření i v nové verzi PostgreSQL. Použití nesprávné nebo nekompatibilní verze rozšíření může způsobit chyby a nestabilitu systému.

Zjištění dostupných rozšíření:

Namísto příkazu \dx použijte SQL dotaz, který vypíše všechna dostupná rozšíření v systému, včetně těch, která ještě nejsou aktivována:

sudo -u postgres psql -c "SELECT * FROM pg_available_extensions;"

Tento příkaz zobrazí seznam všech dostupných rozšíření, včetně jejich verze a stavu instalace. Například u TimescaleDB byste měli vidět něco podobného:

Instalace stejné verze TimescaleDB do nové verze PostgreSQL:

Po instalaci nové verze PostgreSQL je nutné nainstalovat stejnou verzi TimescaleDB, jakou jste používali dříve. Zajistěte, aby verze TimescaleDB byla kompatibilní s novou verzí PostgreSQL a aby byla stejná jako v původní instalaci.

Příklad instalace konkrétní verze TimescaleDB:

sudo dnf install timescaledb-2-postgresql-<verze>-<konkrétní_verze> timescaledb-2-loader-postgresql-<verze>-<konkrétní_verze>

Důležité: Ověřte, že instalovaná verze TimescaleDB odpovídá verzi, kterou jste používali před upgradem, aby nedošlo k nekompatibilitám a problémům při migraci dat.

Instalace PostGIS do nové verze PostgreSQL:

Pokud používáte PostGIS, nainstalujte ho do nové verze PostgreSQL stejným způsobem jako ostatní rozšíření:

sudo dnf install postgresql-<verze>-postgis

Zajistěte, že verze PostGIS je kompatibilní s novou verzí PostgreSQL.

Přenos konfigurace

Po instalaci rozšíření je dalším krokem přenést konfiguraci ze staré verze PostgreSQL do nové. Tím zajistíte, že všechna vlastní nastavení zůstávají zachována.

Přeneste obsah souboru postgresql.conf:

Tento soubor obsahuje nastavení serveru, jako je paměť, připojení, logování, a další. Před upgradem si uložte kopii tohoto souboru a po instalaci nové verze PostgreSQL přeneste potřebná nastavení. Zohledněte však nové změny a funkce, které mohou v nové verzi PostgreSQL přinést optimalizaci.Příklad přenosu nastavení:

sudo cp /var/lib/pgsql/<stará_verze>/data/postgresql.conf /var/lib/pgsql/<nová_verze>/data/

Po přenosu soubor zkontrolujte a upravte podle aktuální potřeby a možností nové verze.

Přeneste pravidla z pg_hba.conf:

Tento soubor definuje pravidla pro připojení k databázi a ověřování uživatelů. Přeneste vlastní pravidla do nové verze PostgreSQL:

sudo cp /var/lib/pgsql/<stará_verze>/data/pg_hba.conf /var/lib/pgsql/<nová_verze>/data/

Opět, po přenosu soubor zkontrolujte a ověřte, že pravidla odpovídají vašim bezpečnostním potřebám.

Přeneste další konfigurační soubory (pokud je máte):

Pokud používáte další vlastní konfigurační soubory nebo úpravy, nezapomeňte je přenést a aktualizovat v nové verzi.

Ověření připravenosti prostředí

Po instalaci rozšíření a přenosu konfigurace ověřte, že nové prostředí je připravené pro migraci dat. Zkontrolujte, zda jsou všechna rozšíření správně nainstalována a aktivována a zda je konfigurace správně načtena.

Nyní jste připraveni na migraci dat do nové verze PostgreSQL.

Migrace dat / Upgrade

Nyní, když je nová verze PostgreSQL nainstalována a připravena, je čas provést migraci dat ze staré verze do nové. Tento proces zahrnuje přesun datových souborů z původního datového adresáře do nového a zajištění, že všechna data a konfigurace jsou správně přenesena.

Zastavení staré verze PostgreSQL

Než začnete s migrací, je důležité zastavit běžící instanci staré verze PostgreSQL. Tento krok zajistí, že během migrace nebudou do databáze zapisována žádná nová data.

sudo systemctl stop postgresql-<stará_verze>

Nahraďte <stará_verze> číslem verze, kterou aktuálně používáte (např. postgresql-13).

Kontrola před migrací pomocí pg_upgrade --check

Před samotnou migrací dat je velmi užitečné spustit pg_upgrade s parametrem --check. Tento parametr provede kontrolu kompatibility mezi starým a novým databázovým clusterem, aniž by skutečně prováděl migraci dat. Pomůže vám identifikovat problémy, které by mohly způsobit selhání migrace, a upozorní na nastavení, která je třeba opravit.

sudo -u postgres /usr/pgsql-<nová_verze>/bin/pg_upgrade -k -b /usr/pgsql-<stará_verze>/bin -B /usr/pgsql-<nová_verze>/bin -d /var/lib/pgsql/<stará_verze>/data -D /var/lib/pgsql/<nová_verze>/data --check

Vysvětlení parametrů:

• -k: Použití stávajících dat pomocí hardlinků, což urychluje migraci a šetří místo.
• -b: Cesta k binárním souborům staré verze PostgreSQL.
• -B: Cesta k binárním souborům nové verze PostgreSQL.
• -d: Cesta k datovému adresáři staré verze PostgreSQL.
• -D: Cesta k datovému adresáři nové verze PostgreSQL.
• --check: Provádí kontrolu kompatibility mezi starým a novým clusterem bez provedení migrace, upozorní na případné problémy, které je třeba opravit před migrací.

Kontrola kompatibility:

• Tento příkaz zkontroluje, zda jsou stará a nová verze PostgreSQL kompatibilní pro migraci. Pokud zjistí problémy, jako jsou nekompatibilní rozšíření, různé nastavení checksumů nebo jiná konfliktní nastavení, oznámí vám to.

Bezpečné ověření:

• Protože --check neprovádí žádné změny, můžete ho bezpečně spustit, abyste se ujistili, že migrace proběhne hladce. Pokud se objeví nějaké problémy, můžete je opravit před skutečnou migrací.

Identifikace nastavení:

• Parametr --check vám také pomůže identifikovat, zda jsou klíčová nastavení, jako například checksumy, nastavena stejně ve starém i novém clusteru. Tím předejdete problémům, které by mohly způsobit selhání migrace.

Doporučení:

Před tím, než spustíte skutečnou migraci pomocí pg_upgrade, vždy spusťte pg_upgrade --check, abyste odhalili případné problémy předem a mohli je vyřešit. Tento krok vám může ušetřit čas a minimalizovat riziko komplikací během migrace.

Použití pg_upgrade

Nástroj pg_upgrade je určen pro bezpečný a efektivní přesun dat ze staré verze PostgreSQL do nové. Přidáním volby -k dojde k vytvoření hardlinků mezi starými a novými datovými soubory, což znamená, že data nejsou fyzicky kopírována ani použita jako záloha. Tento postup výrazně urychluje migraci a umožňuje nové databázi okamžitě používat tato data. Pokud byste se pokusili spustit starý cluster po migraci, PostgreSQL zjistí, že data již používá nová verze, a odmítne starý cluster spustit, čímž zabrání potenciálním konfliktům a poškození dat.

Příklad příkazu pg_upgrade:

sudo -u postgres /usr/pgsql-<nová_verze>/bin/pg_upgrade -k -b /usr/pgsql-<stará_verze>/bin -B /usr/pgsql-<nová_verze>/bin -d /var/lib/pgsql/<stará_verze>/data -D /var/lib/pgsql/<nová_verze>/data

Vysvětlení parametrů:

• -k: Použití stávajících dat pomocí hardlinků, což urychluje migraci a šetří místo.
• -b: Cesta k binárním souborům staré verze PostgreSQL.
• -B: Cesta k binárním souborům nové verze PostgreSQL.
• -d: Cesta k datovému adresáři staré verze PostgreSQL.
• -D: Cesta k datovému adresáři nové verze PostgreSQL.

Nahraďte <stará_verze> a <nová_verze> čísly verzí, které používáte. Tento příkaz provede migraci dat z původního datového adresáře do nového, přičemž zachová strukturu databáze a data.

Při použití nástroje pg_upgrade (i s parametrem -k) nedochází k přesunu dat ze starého datového adresáře do nového. Místo toho se data kopírují nebo hardlinkují (v závislosti na použití parametrů a systému souborů), a nová verze PostgreSQL používá svůj vlastní datový adresář.

Jak to funguje:

• Bez parametru -k: Pokud nepoužijete parametr -k, pg_upgrade zkopíruje data ze starého adresáře (např. /var/lib/pgsql/12/) do nového adresáře (např. /var/lib/pgsql/18/). To znamená, že data jsou přenesena do nového adresáře a starý adresář s daty může být po migraci odstraněn.
• S parametrem -k: Při použití parametru -k s nástrojem pg_upgrade jsou data sdílena mezi starým a novým clusterem pomocí hardlinků. To znamená, že stará data nejsou fyzicky kopírována, ale oba clustery odkazují na stejné datové bloky. Při pokusu o spuštění staré verze PostgreSQL automaticky detekuje, že data již byla použita jinou verzí, a starý cluster odmítne naběhnout. Nová verze PostgreSQL však bude fungovat normálně. Tento parametr tedy šetří místo a urychluje migraci, ale nelze ho použít jako záložní mechanismus pro starou verzi, protože starý cluster nebude možné znovu spustit.

Základní podmínky pro parametr -k:

• Souborový systém musí podporovat hardlinky: Parametr -k lze použít pouze v případě, že používáte souborový systém, který podporuje hardlinky (např. ext4, XFS apod.). Hardlinky umožňují, aby nový datový adresář odkazoval na stejné fyzické datové bloky jako starý datový adresář, což znamená, že data nejsou kopírována, ale sdílena mezi verzemi.
• Jednotný souborový systém: Oba datové adresáře (starý i nový) musí být na stejném souborovém systému. Hardlinky totiž nemohou odkazovat na soubory na různých souborových systémech.

Výhody použití parametru -k:

• Výrazně rychlejší migrace: Protože při použití hardlinků nedochází k fyzickému kopírování dat, migrace pomocí pg_upgrade s parametrem -k je výrazně rychlejší než standardní migrace. Data nejsou znovu zapisována na disk, což zkracuje dobu trvání procesu.
• Nižší nároky na volné místo: Protože hardlinky odkazují na stejná data, nepotřebujete tolik volného místa na disku jako při plném kopírování dat. To vám umožní provést migraci i v prostředích s omezeným volným prostorem.

Nevýhody a na co si dát pozor při použití parametru -k

• Sdílení dat mezi starým a novým clusterem: Když použijete parametr -k, dojde k hardlinkování dat mezi starým a novým datovým adresářem. To znamená, že i když jsou data dostupná ve dvou různých adresářích (např. /var/lib/pgsql/12/ a /var/lib/pgsql/18/), jedná se o stejná fyzická data na disku. Po migraci však PostgreSQL automaticky detekuje, že data již byla použita jinou verzí, a starý cluster se vůbec nespustí. Tím se zabrání možným problémům, které by mohly nastat, pokud by oba clustery pracovaly nad stejnými daty.
• Starý PostgreSQL cluster nelze znovu spustit: Po použití parametru -k není možné znovu spustit starý PostgreSQL cluster (např. PostgreSQL 12). Při pokusu o spuštění staré verze PostgreSQL automaticky detekuje, že data již byla použita jinou verzí, a starý cluster odmítne naběhnout.

Po úspěšné migraci dat můžete novou verzi PostgreSQL spustit. To můžete provést příkazem:

sudo systemctl start postgresql-<nová_verze>

Tím aktivujete novou verzi PostgreSQL, která nyní běží s migrovanými daty. Nezapomeňte také povolit automatické spuštění při startu systému, pokud jste tak ještě neučinili:

sudo systemctl enable postgresql-<nová_verze>

Nyní je vaše nová databáze připravena k plnému provozu.

Analýza a údržba databáze po migraci

Po úspěšné migraci dat je vhodné provést analýzu a optimalizaci databáze. Tento krok zajistí, že statistiky databáze jsou aktualizované a že je dosaženo optimálního výkonu.

Analýza a údržba databáze po migraci

Po migraci spusťte příkaz vacuumdb, který provede analýzu a údržbu všech databází v několika fázích. Tento příkaz pomůže zlepšit výkon databáze tím, že optimalizuje interní struktury po migraci:

sudo -u postgres /usr/pgsql-<verze>/bin/vacuumdb --all --analyze-in-stages

Tento příkaz provede analýzu databází v několika fázích, což je méně náročné na systémové prostředky než kompletní jednorázová analýza.

Výhody použití vacuumdb –analyze-in-stages

Tato možnost provádí analýzu v několika fázích, což umožňuje rychlejší přístup k validním statistikám a zároveň minimalizuje zatížení systému. Tento krok je obzvláště užitečný po migraci, kdy je potřeba aktualizovat statistiky pro optimalizaci výkonu.

Reindexace po migraci

Při migraci mezi verzemi PostgreSQL, zejména z verzí 13 – 18, je důležité provést reindexaci databáze. Reindexace je klíčová z důvodu změn ve struktuře B-tree indexů, které byly postupně optimalizovány. Tento krok zajistí, že vaše indexy budou plně aktualizovány a optimalizovány pro novou verzi PostgreSQL, což může významně zlepšit výkon.

Proč reindexovat?

• PostgreSQL 13: Tato verze přinesla zlepšení v algoritmech B-tree indexů, včetně de-duplication, což znamená, že po migraci z této verze a novějších je reindexace doporučena. Hlavními benefity těchto vylepšení jsou úspora místa na disku a lepší využití RAM, což přispívá k celkovému zlepšení výkonu databáze.
• PostgreSQL 14: V této verzi došlo k dalším vylepšením algoritmů indexace, optimalizaci správy volného prostoru v indexech a efektivnějšímu využití operační paměti. Reindexace po migraci zajistí lepší konzistenci výkonu a snížení zbytečného zatížení databázového systému.
• PostgreSQL 15: Tato verze přinesla významná vylepšení v paralelní reindexaci a snížení režie při aktualizacích indexů. Díky tomu dochází k výraznému zrychlení operací s indexy, což se přímo projeví v celkově lepší odezvě databáze. Doporučená reindexace po migraci pomůže tyto výhody plně využít.
• PostgreSQL 16: Verze 16 přinesla vylepšení ve vacuumování indexů a snížení vzájemného blokování, což dále zvyšuje výkon indexů a souběžnost operací v databázi. Reindexace po migraci zajistí plné využití těchto optimalizací a plynulejší provoz databáze.
• PostgreSQL 17: Verze 17 dále optimalizovala mechanismy indexace, včetně pokročilého řízení fragmentace indexů a dynamického přizpůsobení indexů aktuálním pracovním zátěžím. Reindexace po přechodu na tuto verzi zajistí maximální využití nových funkcí, sníží fragmentaci a povede k významným úsporám výkonu a zdrojů.
• PostgreSQL 18: Po upgradu je cíleně doporučeno reindexovat indexy používané full‑textovým vyhledáváním a rozšířením pg_trgm, pokud má cluster jako výchozí poskytovatele kolací ICU/builtin (tj. ne libc); změny v práci s kolacemi mohou ovlivnit výsledky a reindexace zajistí konzistentní chování. Současně tato verze přináší „skip scan“ pro vícesloupcové B‑tree indexy, což je optimalizace plánovače využitelná i se stávajícími indexy (kvůli ní reindexace není nutná). 

Jak provést reindexaci:

Po úspěšné migraci doporučujeme spustit reindexaci celé databáze:

sudo -u postgres reindexdb --all

Kdy je reindexace nutná:

• Migrace z PostgreSQL 13 a novější: Změny ve struktuře B-tree indexů znamenají, že reindexace po migraci z těchto verzí je důležitá pro dosažení optimálního výkonu.

Tímto krokem zajistíte, že vaše indexy jsou plně optimalizovány a že budete schopni plně využít výkonových vylepšení, která přinášejí nové verze PostgreSQL.

Optimalizace výkonu (Performance Tuning)

Po upgradu databáze je vhodné znovu přezkoumat a optimalizovat parametry pro dosažení co nejlepšího výkonu. To je zvláště důležité, pokud došlo ke zlepšení hardwarové konfigurace nebo pokud jsou v nové verzi PostgreSQL k dispozici nové funkce, které mohou výkon ovlivnit.

Paměťové nastavení

Nastavení paměťových parametrů je zásadní pro optimalizaci výkonu PostgreSQL:

• shared_buffers: Tento parametr určuje množství paměti, kterou PostgreSQL používá pro sdílené datové bloky. Doporučuje se nastavit tento parametr na hodnotu odpovídající přibližně 25 % dostupné RAM.
• work_mem: Tento parametr ovlivňuje množství paměti přidělené jednotlivým operacím třídění a hašování. Pro složitější dotazy nebo více souběžných uživatelů může být nutné tento parametr zvýšit.
• maintenance_work_mem: Tento parametr určuje množství paměti přidělené údržbovým operacím, jako je například indexování a autovacuum. Zvýšení této hodnoty může urychlit tyto operace, zejména u větších databází.

Změny v kompresi:

• WAL komprese (PostgreSQL 14 a novější): PostgreSQL 14 přidává podporu pro kompresi WAL souborů pomocí algoritmů Zstandard (ZSTD) a LZ4. To umožňuje výrazně snížit velikost WAL logů, což vede k úspoře místa na disku a potenciálně i ke zlepšení výkonu při přenosu logů přes síť.
• TOAST komprese (PostgreSQL 15): PostgreSQL 15 zavádí podporu komprese dat v TOAST tabulkách pomocí algoritmu LZ4. TOAST (The Oversized-Attribute Storage Technique) se používá pro ukládání velkých hodnot, jako jsou velké textové řetězce nebo binární data. Komprese LZ4 je rychlá a účinná, což může vést ke snížení velikosti uložených dat a zlepšení výkonu při jejich čtení a zápisu.
• Rozšířená podpora komprese (PostgreSQL 16): Verze 16 přináší další optimalizace komprese dat, včetně vylepšeného řízení komprese TOAST dat a flexibilnějších možností komprese u partitionovaných tabulek. To vede k dalším úsporám místa a rychlejšímu zpracování dat.
• Adaptivní komprese (PostgreSQL 17): PostgreSQL 17 zavádí adaptivní kompresi, která dynamicky vybírá nejvhodnější kompresní algoritmus podle typu a povahy dat. Tato funkce automaticky maximalizuje účinnost komprese, snižuje nároky na prostor na disku a optimalizuje rychlost přístupu k datům.
• Ověřování komprimovaných záloh pg_verifybackup (PostgreSQL 18): Nástroj pg_verifybackup nově umí přímo ověřit zálohy vytvořené v tar formátu včetně komprimovaných archivů (gzip/lz4/zstd) bez nutnosti je nejdřív rozbalit. Ověření WALu zatím zůstává jen pro „plain“ zálohy, u tar archivů je proto vhodné přidat –no-parse-wal. To zrychluje a zjednodušuje kontrolu záloh, pokud používáš kompresi na úrovni pg_basebackup.

Autovacuum

Autovacuum je důležitý proces, který zajišťuje údržbu databáze tím, že automaticky provádí operace, jako je odstraňování mrtvých řádků a aktualizace statistik. Po upgradu databáze byste měli zkontrolovat nastavení autovacuum a případně je upravit tak, aby odpovídala novým požadavkům na výkon.

• Frekvence a prahové hodnoty: Pokud databáze často provádí velké množství změn, zvažte snížení prahových hodnot pro spuštění autovacuum, aby se častěji spouštělo.
• Paralelní běh: Zvyšte počet paralelních autovacuum procesů, pokud je to možné, což může zlepšit výkon při údržbě databáze s mnoha tabulkami.

Logování

Pokud potřebujete sledovat výkon nebo ladit problémy, upravte nastavení logování. To vám umožní sledovat dotazy, které zpomalují databázi, nebo identifikovat další problémy:

• log_min_duration_statement: Nastavte tento parametr na dobu, po kterou by měl být dotaz logován, pokud trvá déle než zadaná hodnota. Může vám to pomoci identifikovat pomalé dotazy.
• log_checkpoints, log_autovacuum_min_duration: Tyto parametry mohou pomoci sledovat činnosti, které mohou ovlivňovat výkon, jako jsou checkpointy nebo dlouhé autovacuum operace.

Použití TimescaleDB Tuneru

Pokud používáte TimescaleDB, můžete využít jejich nástroj TimescaleDB Tuner pro automatickou optimalizaci nastavení výkonu. Tento nástroj analyzuje vaši konfiguraci a doporučí optimální nastavení pro parametry, jako jsou shared_buffers, work_mem, maintenance_work_mem a další.

Nástroj TimescaleDB Tuner můžete spustit pomocí následujícího příkazu:

timescaledb-tune

Tento nástroj projde vaši aktuální konfiguraci a poskytne doporučení pro úpravu nastavení. Kromě základních doporučení umožňuje tuner také nastavit volitelné parametry, které mohou dále optimalizovat výkon databáze. Doporučujeme projít tyto parametry a přizpůsobit je podle specifických potřeb vašeho systému a hardwarového prostředí.

Použitím těchto parametrů můžete dosáhnout optimálního nastavení databáze po upgradu a zajistit, že bude fungovat efektivně i při vyšším zatížení.

Ověření funkčnosti

Po provedení všech úprav a migrací je důležité ověřit, že nová verze PostgreSQL běží správně a že jsou všechna data dostupná. Tento krok zajistí, že migrace proběhla úspěšně a že databáze funguje podle očekávání.

Ověření verze PostgreSQL

Zkontrolujte, že nová verze PostgreSQL je správně nainstalována a spuštěna. K tomu můžete použít příkaz:

sudo -u postgres psql -c "SELECT version();"

Ujistěte se, že zobrazená verze odpovídá verzi, na kterou jste aktualizovali.

Ověření přístupu k databázi

Připojte se k databázi a zkontrolujte, že je dostupná. Ověřte, že se můžete připojit k databázi, procházet tabulky a provádět základní dotazy.

Kontrola dat

Prověřte, zda jsou všechna data správně migrována. Ověřte integritu dat a správnost konfigurace. Můžete zkontrolovat klíčové tabulky a data, která jsou pro vaše aplikace nejdůležitější.

Ověření rozšíření a funkcionalit

Ujistěte se, že všechna používaná rozšíření (např. TimescaleDB, PostGIS) jsou správně nainstalována a funkční. Zkontrolujte také, zda konfigurace zůstala konzistentní s vašimi požadavky.

Testování výkonu

Pokud jste provedli úpravy nastavení výkonu, zkontrolujte, zda se tyto změny projevily pozitivně na výkonu databáze. Spusťte několik testů, abyste zjistili, že systém běží hladce a bez problémů.

Kontrola logů

Projděte logovací soubory PostgreSQL, abyste ověřili, že během migrace ani po spuštění nové verze nedošlo k žádným chybám. Logy můžete najít v adresáři, který je specifikován v nastavení postgresql.conf (typicky /var/lib/pgsql/<verze>/data/log nebo podobné umístění). Zaměřte se na jakákoliv varování nebo chyby, které by mohly naznačovat problémy s migrací nebo výkonem.

sudo tail -f /var/lib/pgsql/<verze>/data/log/*.log

Sledujte logy a zkontrolujte, zda neobsahují žádné závažné chyby nebo varování.

Úklid po migraci a důležité poznámky

Po úspěšné migraci a ověření správné funkčnosti nové verze PostgreSQL je důležité provést úklid, aby se uvolnilo místo na disku a odstranily se staré, již nepotřebné soubory a verze PostgreSQL.

Odstranění starých datových souborů

Pokud jste použili pg_upgrade, může být vygenerován skript pro odstranění starých datových souborů. Tento skript můžete spustit následujícím příkazem:

./delete_old_cluster.sh

Poznámka: Tento příkaz trvale odstraní staré datové soubory, takže se ujistěte, že migrace proběhla úspěšně a že již nepotřebujete přístup k původním datům.

Odebrání staré verze PostgreSQL

Pokud již starou verzi PostgreSQL nepotřebujete a neplánujete ji používat v budoucnu, můžete ji odebrat ze systému:

 dnf remove postgresql<stará_verze>-server

Tímto příkazem se odstraní stará verze PostgreSQL a její balíčky.

Poznámka: Při odstraňování staré verze PostgreSQL je vhodné odstranit i všechny balíčky rozšíření (extenzí), které jsou s touto verzí spojené, pokud existují. Tím zajistíte, že na systému nezůstanou nepotřebné balíčky, které již nebudete používat.

Revize systémových služeb

Ujistěte se, že stará verze PostgreSQL není zaregistrovaná jako systémová služba, která by se mohla nechtěně spustit. Můžete to ověřit příkazem:

sudo systemctl list-unit-files | grep postgresql

Pokud vidíte služby staré verze, deaktivujte je:

sudo systemctl disable postgresql-<stará_verze>

Aktualizace dokumentace a skriptů

Pokud máte skripty nebo dokumentaci, které odkazují na starou verzi PostgreSQL, nezapomeňte je aktualizovat, aby odkazovaly na novou verzi. To zahrnuje zálohovací skripty, monitorovací nástroje, a další související konfigurace. Zvláštní pozornost věnujte následujícím oblastem:

• Zálohovací skripty: Ujistěte se, že všechny zálohovací skripty odkazují na správnou verzi PostgreSQL a že jsou přizpůsobeny novým funkcím nebo změnám, které mohou mít vliv na proces zálohování (např. změny v podporovaných příkazech nebo optimalizace zálohování).
• Monitorovací nástroje: Aktualizujte jakýkoli software nebo nástroje, které monitorují výkon databáze, aby byly kompatibilní s novou verzí PostgreSQL. Zkontrolujte, zda všechny monitorovací metriky a výstrahy odpovídají nové verzi a jejím parametrům.
• Automatizační skripty: Pokud používáte skripty pro automatizaci správy databáze (např. skripty pro správu replikace, údržbu databáze nebo nasazování nových funkcí), aktualizujte je, aby byly plně kompatibilní s novou verzí PostgreSQL.

Seznámení se s novinkami a změnami

Před provedením migrace je vždy vhodné seznámit se s novinkami, změnami a očekávaným chováním nové verze PostgreSQL. Doporučujeme:

• Číst changelog: Přečtěte si oficiální changelog PostgreSQL pro danou verzi, aby vás žádné změny nepřekvapily a abyste byli připraveni na nové funkce, změny v chování, nebo odstraněné funkce.
• Zúčastnit se našich webinářů: Pravidelně pořádáme zdarma webináře, kde vás informujeme o novinkách v PostgreSQL a co očekávat po migraci. Je to skvělá příležitost, jak se seznámit s novými funkcemi a získat odpovědi na své otázky od odborníků.

Tento návod by měl být komplexní a pokrývat všechny důležité aspekty upgradu PostgreSQL na RHEL/Rocky Linux 9. Můžete jej přizpůsobit konkrétním potřebám a prostředí vaší organizace.

The post Jak aktualizovat PostgreSQL na nejnovější verzi appeared first on initMAX s.r.o..

POZOR: Současná verze TimescaleDB NEFUNGUJE s nejnovější verzí PostgreSQL (18)

Výhody TimescaleDB v Zabbixu

TimescaleDB přináší do Zabbixu několik zásadních výhod, které zvyšují výkon a efektivitu při práci s velkými objemy časových dat:

• Škálovatelnost a Výkon: TimescaleDB je navrženo tak, aby efektivně spravovalo velké množství časových dat. Díky architektuře hypertables umožňuje rychlé zápisy a čtení dat, což je klíčové pro systémy monitorování, jako je Zabbix, které generují obrovské množství metrik.
• Komprese dat: TimescaleDB nabízí schopnost komprese historických dat, což snižuje nároky na úložiště a může vést až k 90% úspoře místa na disku. Komprese však znemožňuje změnu již zkomprimovaných dat; pro případnou úpravu je nutné data nejprve dekomprimovat, provést změnu a poté opět komprimovat.
• Snadná správa: TimescaleDB je plně kompatibilní s PostgreSQL, což znamená, že správci, kteří jsou obeznámeni s PostgreSQL, se snadno zorientují i v TimescaleDB. Implementace je jednoduchá a přidává jen minimální režijní náklady na správu databáze. Dále je možné některá nastavení TimescaleDB upravovat přímo v administraci Zabbixu, konkrétně v sekci Administration > Housekeeping.

Tabulky v Zabbixu využívající TimescaleDB

Zabbix používá TimescaleDB k ukládání velkého množství časových dat, která jsou rozdělena do několika klíčových tabulek. Aby byl tento proces efektivní a dobře spravovaný, využívá se speciální struktura zvaná hypertable, která je navržena pro práci s časovými daty v TimescaleDB. Pro usnadnění konverze existujících tabulek na hypertables a optimalizaci správy těchto dat obsahuje soubor /usr/share/zabbix-sql-scripts/postgresql/timescaledb/schema.sql skript s potřebnými příkazy. Tento skript automatizuje převod klíčových tabulek Zabbixu na hypertables, což zajišťuje efektivní práci s velkými objemy dat.

Poznámka: Od verze Zabbixu 7.2 se skript schema.sql pro TimescaleDB nachází v následující cestě:
/usr/share/zabbix/sql-scripts/postgresql/timescaledb/schema.sql.

Každý příkaz ve skriptu využívá funkci create_hypertable, která je klíčová pro převod běžných tabulek PostgreSQL na hypertables. Hypertable funguje tak, že data automaticky spravuje v menších podtabulkách, zvaných chunky. Toto dělení umožňuje efektivní dotazování a ukládání dat, což je nezbytné pro rychlý přístup k velkým množstvím časových sérií. Proces konverze tabulek na hypertables zahrnuje několik důležitých parametrů:

• Název tabulky (např. 'history_text'): Určuje, která konkrétní tabulka bude převedena na hypertable. V případě tabulky history_text se jedná o textová data, jako jsou zprávy a logy, která jsou v Zabbixu monitorována.
• Časový sloupec (např. 'clock'): Tento parametr definuje sloupec obsahující časové značky (timestamp), které jsou klíčové pro rozdělení dat do jednotlivých chunků. Sloupec 'clock' specifikuje čas, kdy byla data zaznamenána, což umožňuje jejich správné rozdělení a třídění.
• chunk_time_interval (např. 86400): Tento parametr určuje časový interval v sekundách pro jednotlivé chunky. Hodnota 86400 sekund odpovídá jednomu dni. To znamená, že veškerá data shromážděná během jednoho dne budou uložena v jednom chunku. Tento interval lze přizpůsobit podle požadavků na výkon a množství dat, které je třeba zpracovat.
• migrate_data (např. true): Když je tento parametr nastaven na true, všechna existující data v tabulce jsou automaticky migrována do nové struktury chunků. Tato funkce je důležitá při konverzi již existujících tabulek na hypertables, aby nedošlo ke ztrátě dat.
• if_not_exists (např. true): Tento parametr zajišťuje, že pokud hypertable již existuje, příkaz ji nebude znovu vytvářet, což zabraňuje možným chybám a ztrátám dat. Pokud hypertable ještě neexistuje, bude nově vytvořena.

Použitím těchto nastavení TimescaleDB zajišťuje efektivní správu a přístup k velkým objemům časových dat, což je nezbytné pro systémy jako Zabbix, které generují a analyzují velké množství metrik. Níže jsou uvedeny klíčové tabulky, které byly přeměněny na hypertables pro zajištění lepšího výkonu a efektivity:

• history: Uchovává numerická data s plovoucí desetinnou čárkou.

PERFORM create_hypertable('history', 'clock', chunk_time_interval => 86400, migrate_data => true, if_not_exists => true);

• history_uint: Ukládá celá čísla.

PERFORM create_hypertable('history_uint', 'clock', chunk_time_interval => 86400, migrate_data => true, if_not_exists => true);

• history_log: Obsahuje logovací informace.

PERFORM create_hypertable('history_log', 'clock', chunk_time_interval => 86400, migrate_data => true, if_not_exists => true);

• history_text: Ukládá textová data, jako jsou zprávy a logy.

PERFORM create_hypertable('history_text', 'clock', chunk_time_interval => 86400, migrate_data => true, if_not_exists => true);

• history_str: Uchovává krátké textové řetězce.

PERFORM create_hypertable('history_str', 'clock', chunk_time_interval => 86400, migrate_data => true, if_not_exists => true);

• history_bin: Uchovává binární data. (Od verze 7.0.2)

PERFORM create_hypertable('history_bin', 'clock', chunk_time_interval => 86400, migrate_data => true, if_not_exists => true);

• auditlog: Obsahuje logovací informace o aktivitách uživatelů. (Od verze 7.0)

PERFORM create_hypertable('auditlog', 'auditid', chunk_time_interval => 604800, time_partitioning_func => 'cuid_timestamp', migrate_data => true, if_not_exists => true);

• trends: Ukládá agregované historické údaje o metrikách.

PERFORM create_hypertable('trends', 'clock', chunk_time_interval => 2592000, migrate_data => true, if_not_exists => true);

• trends_uint: Ukládá agregovaná historická data pro metriky celých čísel.

PERFORM create_hypertable('trends_uint', 'clock', chunk_time_interval => 2592000, migrate_data => true, if_not_exists => true);

Instalace TimescaleDB v Zabbixu

Příprava na instalaci

Před zahájením instalace TimescaleDB je nutné mít nainstalovaný PostgreSQL a také balíček zabbix-sql-scripts z oficiálního repozitáře pro konkrétní používanou verzi Zabbixu. Zatímco Zabbix jako takový nemusí být nutně nainstalován, zmíněný balíček zabbix-sql-scripts je nezbytný, protože obsahuje potřebné SQL skripty pro konfiguraci databáze. U PostgreSQL se doporučuje instalace z oficiálního repozitáře PostgreSQL, spíše než použití systémového repozitáře, aby byla zajištěna kompatibilita a přístup k nejnovějším funkcím a opravám zabezpečení.

Je důležité poznamenat, že všechny následující příkazy a nastavení se provádějí pouze na serveru PostgreSQL. Instalace TimescaleDB z oficiálního repozitáře TimescaleDB, který podporuje komunitní verzi licence, umožňuje přístup k pokročilým funkcím, jako je komprese dat. Díky komunitní licenci mají uživatelé možnost využívat kompresi, což může výrazně snížit nároky na úložiště a zlepšit výkon dotazů na historická data.

Přidání oficiálního repozitáře TimescaleDB

Pro instalaci TimescaleDB z oficiálního repozitáře je třeba přidat repozitář do systému. Na distribucích založených na RHEL, jako je Rocky Linux, postupujte následovně:

tee /etc/yum.repos.d/timescale_timescaledb.repo <<EOL
[timescale_timescaledb]
name=timescale_timescaledb
baseurl=https://packagecloud.io/timescale/timescaledb/el/$(rpm -E %{rhel})/\$basearch
repo_gpgcheck=1
gpgcheck=0
enabled=1
gpgkey=https://packagecloud.io/timescale/timescaledb/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300
EOL

Nainstalujme TimescaleDB.

Nahraďte číslo verze (16) odpovídající verzí PostgreSQL, kterou používáte.

dnf install timescaledb-2-postgresql-16 timescaledb-2-loader-postgresql-16

Spustíme utility timescaledb-tune a jako parametr jí předáme vyšší hodnotu maximálního množství připojení (--max-conns), které pro tyto testovací účely nastavíme na 125.

Tato utility slouží k přizpůsobení výchozího nastavení PostgreSQL relativně výkonu a adekvátnímu nastavení parametrů PostgreSQL pro fungování s TimescaleDB.

Zároveň nám tato utility pomocí instalačního průvodce pomůže vybrat aktuální a platný konfigurační soubor PostgreSQL a nastaví i automatické načítání knihoven TimescaleDB.

Prosím, odpovídejte „ano“ (y) na všechny otázky. Pozor, automatický tuner předpokládá, že PostgreSQL běží na samostatném serveru, a proto může být potřeba případně upravit parametry.

Nahraďte číslo verze (16) odpovídající verzí PostgreSQL, kterou používáte.

timescaledb-tune --pg-config /usr/pgsql-16/bin --max-conns=125

Následně restartujeme systémovou službu pro PostgreSQL:

Nahraďte číslo verze (16) odpovídající verzí PostgreSQL, kterou používáte.

systemctl restart postgresql-16.service

Zbývá již jen vytvořit a aktivovat samotnou TimescaleDB:

Pozor, během vývoje došlo ke změně cesty z původní /usr/share/zabbix-sql-scripts/postgresql/timescaledb.sql na novou /usr/share/zabbix-sql-scripts/postgresql/timescaledb/schema.sql.

Poznámka: Od verze Zabbixu 7.2 se skript schema.sql pro TimescaleDB nachází v následující cestě:
/usr/share/zabbix/sql-scripts/postgresql/timescaledb/schema.sql.

Ignorování varování: Při spuštění skriptu schema.sql na verzi TimescaleDB 2.9.0 a vyšší mohou být zobrazena varování o nedodržení osvědčených postupů. Tato varování lze ignorovat, protože konfigurace bude úspěšně dokončena i přes ně.

Dlouhá doba migrace: Migrace existujících historických dat, trendů a audit logů může trvat dlouho. !!! Během této doby musí být Zabbix server a frontend vypnutý !!!, aby byla zajištěna konzistence dat.

Pro verzi Zabbixu 7.0 a starší:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
cat /usr/share/zabbix-sql-scripts/postgresql/timescaledb/schema.sql | sudo -u zabbix psql zabbix

Od verze Zabbixu 7.2:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
cat /usr/share/zabbix/sql-scripts/postgresql/timescaledb/schema.sql | sudo -u zabbix psql zabbix

Dodatečné informace

Nastavení parametrů čištění (Administration > Housekeeping): Skript schema.sql nastavuje následující parametry čištění:

• Override item history period: Povolit přepsání období uchování historie položek.
• Override item trend period: Povolit přepsání období uchování trendů.

Aby bylo možné použít partitioned housekeeping pro historii a trendy, musí být obě tyto možnosti povoleny. Je také možné povolit přepsání pouze pro historii nebo pouze pro trendy. Pokud bude nastavení aplikováno bude nastavení pro historii a trendy na úrovni itemu ignorovano.

Další parametry ve skriptu schema.sql: Tento skript nastavuje také dva další parametry:

• Enable compression: Povolit kompresi.
• Compress records older than 7 days: Komprimovat záznamy starší než 7 dnů.

Pro úspěšné odstranění komprimovaných dat pomoci housekeeper musí být povoleny jak možnosti Override item history period, tak Override item trend period. Pokud je přepsání deaktivováno a tabulky mají komprimované chunky, správce údržby nebude odstraňovat data z těchto tabulek a v sekcích Housekeeping a System information se zobrazí varování o nesprávné konfiguraci​

V případě, že uvidíte v Zabbix Server log souboru zprávu o tom, že je verze TimescaleDB příliš nová, pak to není žádný velký problém. Zabbix nedokáže dostatečně rychle reagovat na nejnovější verze TimescaleDB tak, aby ji ve svém kódu nastavil jako podporovanou, ovšem kompatibilita je Zabbixem zaručena a námi ověřena.

Pokud se chceme vyhnout zprávám o nekompatibilitě v log souboru Zabbixu, pak stačí otevřít konfigurační soubor Zabbix serveru v cestě /etc/zabbix/zabbix_server.conf a zde upravte následující konfigurační parametr:

AllowUnsupportedDBVersions=1

Soubor s tímto nastavením uložte a znovu nastartujte systémovou službu Zabbix serveru.

systemctl restart zabbix-server

A to je vše! Podařilo se Vám zprovoznit rozšíření pro TimescaleDB a máte základní databázový performance tuning. Následující kroky by měly smeřovat k zálohování a monitoringu DB.

The post Implementace TimescaleDB v Zabbixu: Výhody, Klíčové Tabulky a Instalace appeared first on initMAX s.r.o..

Článek počítá s tím, že pokud jsou k dispozici volitelné patche (float a primární klíče), pak byly do DB již aplikovány.
Pokud si nejste jisti, pak informace o tomto stavu se zobrazuje zároveň i ve frontendu v sekci System information, např. políčko: „Database history tables upgraded: No“.

Dopředu upozorňujeme, že migraci děláte pouze na vlastní nebezpečí a neneseme žádnou odpovědnost za případné škody způsobené neodborným zásahem.

Každá verze Zabbixu i databáze má svá konkrétní specifika, která je nutné brát v potaz už při návrhu migračního plánu a jednotlivých činností. Dle našich zkušeností se velká část problémů po migraci (například s promazáváním) může projevit až později. Doporučujeme tedy, abyste nás před zásahem do produkčního prostředí raději kontaktovali pro případnou konzultaci. Rádi vám s celým procesem bezchybné migrace a následnými kroky pomůžeme.

PostgreSQLZabbix

21. 11. 2024

Migrace Zabbix databáze z MySQL do PostgreSQL krok za krokem

Zhlédnout záznam

Kontrola verzí

Jako vůbec první krok před samotnou migrací je třeba vědět konkrétní aktuálně BĚŽÍCÍ verzi Zabbix serveru. Tedy nikoliv to, co nám zobrazuje patička ve webovém frontendu.

Toto nejbezpečněji zjistíme v logu samotného Zabbix serveru při jeho startu:

cat /var/log/zabbix/zabbix_server.log | grep "Starting Zabbix Server. Zabbix"

Výstup tohoto příkazu v našem případě vypadá následovně:

1933256:20240510:164211.482 Starting Zabbix Server. Zabbix 7.0.0 (revision 9bc845eca94)

Jako další možnost je zjištění verze instalačních balíčků podpůrných knihoven Zabbixu pro MySQL, což je ilustrováno příkazem níže.

Toto ale nemusí být skutečná, aktuálně běžící verze!

rpm -qa | grep zabbix-server-mysql

Výstup tohoto příkazu vypadá takto:

zabbix-server-mysql-7.0.0.release1.el9.x86_64

Dalším způsobem zjištění verze Zabbix serveru je pak kontrola verze samotným spouštěcím souborem. Ovšem i tato informace může být za jistých okolností zavádějící a nemusí to být verze aktuálně spuštěná.

zabbix_server -V

Výstup pak vypadá následovně:

zabbix_server (Zabbix) 7.0.0
Revision 9bc845eca94 30 January 2024, compilation time: Jan 30 2024 00:00:00

Přípravné kroky

MySQL triggery

Zabbix od verze 6.0.11 obsahuje databázové triggery a s těmi se musí při migraci počítat. Následující sadou příkazů tedy zjistíme, jestli se to naší databázové instance bude také týkat.

Přihlásíme se do mysql konzole:

mysql

Přepneme se do databáze ‚zabbix‘:

use zabbix;

Následně zavoláme příkaz SHOW TRIGGERS, který nám případně zobrazí použité databázové triggery:

SHOW TRIGGERS\G

Pokud je výstup tohoto příkazu následující, pak část s instalací triggerů níže v návodu můžete s klidem vynechat.

Empty set (0.00 sec)

Ukázku z výstupu tohoto příkazu v Zabbixu verze 6.0.11 vidíte zde. V tuto chvíli už se níže zmíněné kapitole o migraci triggerů nevyhnete.

*************************** 1. row ***************************
             Trigger: hosts_name_upper_insert
               Event: INSERT
               Table: hosts
           Statement: set new.name_upper=upper(new.name)
              Timing: BEFORE
             Created: 2024-02-27 09:59:58.09
            sql_mode: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
             Definer: zabbix@localhost
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: utf8mb4_bin
*************************** 2. row ***************************
             Trigger: hosts_name_upper_update
               Event: UPDATE
               Table: hosts
           Statement: begin
if new.name<>old.name
then
set new.name_upper=upper(new.name);
end if;
end
              Timing: BEFORE
             Created: 2024-02-27 09:59:58.10
            sql_mode: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
             Definer: zabbix@localhost
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: utf8mb4_bin
*************************** 3. row ***************************
             Trigger: items_name_upper_insert
               Event: INSERT
               Table: items
           Statement: set new.name_upper=upper(new.name)
              Timing: BEFORE
             Created: 2024-02-27 10:00:00.76
            sql_mode: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
             Definer: zabbix@localhost
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: utf8mb4_bin
*************************** 4. row ***************************
             Trigger: items_name_upper_update
               Event: UPDATE
               Table: items
           Statement: begin
if new.name<>old.name
then
set new.name_upper=upper(new.name);
end if;
end
              Timing: BEFORE
             Created: 2024-02-27 10:00:00.77
            sql_mode: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
             Definer: zabbix@localhost
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: utf8mb4_bin
4 rows in set (0.01 sec)

Instalace závislostí

Nejprve přidáme oficiální repozitář PostgreSQL, který pro instalaci doporučujeme. Instalační balíčky z repozitářů od RedHat se podstatně liší.

To provedeme následujícím příkazem:

yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm

Nainstalujeme PostgreSQL v Zabbixem podporované verzi, kterou zjistíme v matici kompatiblity na stránkách Zabbixu:

yum install postgresql18-server

Inicializujeme databázový server PostgreSQL následujícím příkazem:

/usr/pgsql-18/bin/postgresql-18-setup initdb

Spustíme službu PostgreSQL a nastavíme její spouštění po startu:

systemctl enable postgresql-18
systemctl start postgresql-18

Nainstalujeme utilitu pgloader, kterou použijeme k samotné migraci dat:

yum install pgloader

Pomocí následujícího příkazu zkontrolujeme verzi pgloaderu:

pgloader -V

Výstup bude pak vypadat následovně:

pgloader version "3.6.7"

Příprava na migraci

Nyní vytvoříme dočasnou složku, která nám bude sloužit k uchování konfiguračních souborů použitých při následné migraci a otevřeme ji:

mkdir /tmp/zabbix-db-migration/ && cd $_

Parsování schématu

Pro samotnou migraci dat budeme potřebovat soubor s databázovým schématem, tento nalezneme v oficiálních zdrojových kódech Zabbixu pro vaši konkrétní verzi.

Tento příkaz je nezbytně nutné přizpůsobit přímo vaší verzi Zabbix!

Stále se nacházíme v naší dočasné složce, vytvořené pro migraci a zdrojový kód pro naši verzi 7.0.0 tedy stáhneme sem, a to následujícím příkazem:

wget https://cdn.zabbix.com/zabbix/sources/stable/7.0/zabbix-7.0.0.tar.gz

Stáhnutý archiv se zdrojovým kódem Zabbixu rozbalíme:

tar -zxvf zabbix-7.0.0.tar.gz

Otevřeme si složku v následující cestě, kde nalezneme databázová schémata:

cd /tmp/zabbix-db-migration/zabbix-7.0.0/database/postgresql/

Z jednotného souboru schématu vybereme pouze operace vytvářející tabulky a triggery, a uložíme je do separátního souboru:

grep -v 'ALTER TABLE ONLY' schema.sql | grep -v INSERT | grep -v 'CREATE INDEX' | grep -v 'CREATE UNIQUE INDEX' > /tmp/zabbix-db-migration/create_tables.sql

Tento soubor nyní obsahuje nejen CREATE TABLE operace, ale i operace a funkce pro triggery, které řešíme individuálně. Část, která triggery vytváří tedy z tohoto souboru odebereme:

sed -i '/create\ or\ replace\ function/,$d' /tmp/zabbix-db-migration/create_tables.sql

A z tohoto jednotného schématu pak právě vybereme pouze operace související s triggery:

awk '/INSERT INTO dbversion/{p=1;next} /ALTER TABLE/{p=0} p' schema.sql > /tmp/zabbix-db-migration/triggers.sql

A nyní můžeme postoupit dále. Ze stejného souboru s databázovým schématem vybreme pouze operace pro vytváření indexů a uložíme je v separátním souboru:

grep -E 'CREATE INDEX|CREATE UNIQUE INDEX' schema.sql > /tmp/zabbix-db-migration/create_index.sql

Opět z tohoto jednotného souboru se schématem vybereme pouze ALTER operace a uložíme je do separátního souboru:

grep 'ALTER TABLE ONLY' schema.sql > /tmp/zabbix-db-migration/alter_table.sql

Příprava PostgreSQL

Následně vytvoříme databázového uživatele pro Zabbix, budeme vyzváni k zadání hesla:

sudo -u postgres createuser --pwprompt zabbix

Vytvoříme zabbix databázi:

sudo -u postgres createdb -O zabbix zabbix

Vytvoříme zabbix schéma:

sudo -u postgres psql --host=127.0.0.1 --dbname=zabbix --username=zabbix -f /tmp/zabbix-db-migration/create_tables.sql

Kvůli kompatibilitě s utilitou pgloader dočasně nastavíme encryption hash na ‚md5‘ a změníme heslo vytvořenému databázovému uživateli tak, aby se v daném hash algorytmu přegenerovalo. Pro jednoduchost použijte ideálně stejné heslo, jako jsme zadávali při vytváření tohoto uživatele.

sudo -u postgres psql -c "SET password_encryption='md5';"
sudo -u postgres psql -c "ALTER ROLE zabbix WITH PASSWORD '***********';"

Příprava MySQL

V případě, že naše MySQL používá již změněný formát přihlašování, pak je stejně jako u PostgreSQL pro potřeby pgloader třeba změnit způsob přihlašování databázového uživatele pro Zabbix a zároveň mu přegenerovat heslo. To uděláme následujícím způsobem.

Nejprve otevřeme konfigurační soubor MySQL serveru. Pokud používáte jinou verzi, např. MariaDB nebo Percona, pak se umístění může lišit.

nano /etc/my.cnf.d/mysql-server.cnf

A zde dočasně upravíme v sekci [mysqld] následující direktivu:

[mysqld]
...
default-authentication-plugin=mysql_native_password

Nyní musíme zrestartovat MySQL:

systemctl restart mysqld

A nyní můžeme změnit způsob přihlašování uživatele pro Zabbix a přegenerovat mu heslo. Nezapomeňte v příkazu níže změnit heslo na své vlastní!

mysql -e "ALTER USER 'zabbix'@'localhost' IDENTIFIED WITH mysql_native_password BY '*********';"

Připravíme konfiguraci – SQL skript pro pgloader, tudíž tento soubor vytvořte:

nano /tmp/zabbix-db-migration/pgloader.conf

A tento soubor vyplňte následujícím obsahem. Nezapomeňte si v tomto skriptu změnit hesla (označená pomocí hvězdiček) na vaše vlastní, validní hesla do obou databází:

LOAD DATABASE
FROM mysql://zabbix:**********@127.0.0.1/zabbix
INTO postgresql://zabbix:**********@127.0.0.1/zabbix
WITH include no drop,
truncate,
create no tables,
create no indexes,
no foreign keys,
reset sequences,
data only,
prefetch rows = 100,
batch rows = 1000,
batch concurrency = 1
ALTER SCHEMA 'zabbix' RENAME TO 'public';

Migrace

Nyní se můžeme pustit do samotné migrace. V tuto chvíli doporučujeme udělat si zálohu zdrojové MySQL databáze a přesvědčte se, že máte dostatečné volné místo na disku.

Nejprve zastavíme službu Zabbix serveru a Apache web serveru pro Zabbix frontend:

systemctl stop zabbix-server httpd

Vytvoříme v naší dočasné složce složku pro migrovaná data z MySQL:

mkdir /tmp/zabbix-db-migration/data

A následně spustíme pgloader s námi vytvořeným konfiguračním souborem:

pgloader --root-dir=/tmp/zabbix-db-migration/data /tmp/zabbix-db-migration/pgloader.conf

Pokud pgloader při běhu zahlásí nějaké výstražné zprávy (Warning), pak je můžete směle ignorovat – ničemu nevadí. Naopak problémy, které jsou závažnější, a se kterými se ale také můžete setkat jsou např.: malý objem dostupného místa na disku, časové prodlevy mezi databázemi (timeouts), příliš nízká rychlost zápisu na disk (nízké iops). I tyto problémy lze vyřešit, ovšem vyžadují další analýzu a následný tuning přímo na míru.

Příklad výstupu tohoto příkazu naleznete zde:

2024-05-10T16:55:38.010000+01:00 LOG pgloader version "3.6.7~devel"
2024-05-10T16:55:38.174002+01:00 LOG Migrating from #<MYSQL-CONNECTION mysql://zabbix@127.0.0.1:3306/zabbix {100685C583}>
2024-05-10T16:55:38.175002+01:00 LOG Migrating into #<PGSQL-CONNECTION pgsql://zabbix@127.0.0.1:5432/zabbix {100685C713}>
2024-05-10T16:55:38.684006+01:00 WARNING Source column "public"."history_uint"."value" is casted to type "bigint" which is not the same as "numeric", the type of current target database column "public"."history_uint"."value".
2024-05-10T16:55:38.685006+01:00 WARNING Source column "public"."item_rtdata"."lastlogsize" is casted to type "bigint" which is not the same as "numeric", the type of current target database column "public"."item_rtdata"."lastlogsize".
2024-05-10T16:55:38.686006+01:00 WARNING Source column "public"."proxy_history"."lastlogsize" is casted to type "bigint" which is not the same as "numeric", the type of current target database column "public"."proxy_history"."lastlogsize".
2024-05-10T16:55:38.686006+01:00 WARNING Source column "public"."trends_uint"."value_min" is casted to type "bigint" which is not the same as "numeric", the type of current target database column "public"."trends_uint"."value_min".
2024-05-10T16:55:38.687006+01:00 WARNING Source column "public"."trends_uint"."value_avg" is casted to type "bigint" which is not the same as "numeric", the type of current target database column "public"."trends_uint"."value_avg".
2024-05-10T16:55:38.687006+01:00 WARNING Source column "public"."trends_uint"."value_max" is casted to type "bigint" which is not the same as "numeric", the type of current target database column "public"."trends_uint"."value_max".
2024-05-10T16:56:28.778334+01:00 ERROR Database error 23505: duplicate key value violates unique constraint "changelog_pkey"
DETAIL: Key (changelogid)=(16809) already exists.
CONTEXT: COPY changelog, line 1
2024-05-10T16:56:30.691348+01:00 LOG report summary reset
                       table name     errors       rows      bytes      total time
---------------------------------  ---------  ---------  ---------  --------------
                  fetch meta data          0        198                     0.121s
                         Truncate          0        198                     0.338s
---------------------------------  ---------  ---------  ---------  --------------
                   public.history          0    3899811   133.2 MB         39.021s
              public.history_uint          0    2167293    66.0 MB         26.330s
                    public.trends          0     502182    27.5 MB          8.498s
                     public.items          0      12784     4.4 MB          1.488s
                 public.event_tag          0      13012   326.9 kB          0.942s
               public.trigger_tag          0       7365   198.8 kB          1.411s
                  public.triggers          0       5546     1.4 MB          2.027s
              public.graphs_items          0       4186   138.6 kB          2.082s
               public.history_str          0       2923   233.3 kB          2.316s
            public.item_condition          0       2445   123.0 kB          2.524s
              public.widget_field          0       1875   103.9 kB          2.777s
                    public.graphs          0       1428   154.7 kB          3.150s
               public.item_rtdata          0        957    16.0 kB          3.248s
                  public.host_tag          0        635    17.4 kB          3.486s
                    public.widget          0        467    14.2 kB          3.773s
                public.host_hgset          0        307     2.5 kB          3.991s
                  public.profiles          0        265    13.2 kB          4.305s
            public.dashboard_page          0        158     1.9 kB          4.515s
                 public.dashboard          0        154    10.5 kB          4.839s
                    public.images          0        187     1.9 MB          5.049s
            public.task_check_now          0          0                     5.063s
   public.lld_override_opdiscover          0         98     0.7 kB          5.114s
     public.lld_override_opstatus          0         98     0.7 kB          5.217s
         public.trigger_discovery          0         82     2.0 kB          5.339s
              public.users_groups          0         64     0.5 kB          5.407s
                public.user_ugset          0         61     0.3 kB          5.525s
           public.graph_discovery          0         47     1.1 kB          5.643s
           public.hosts_templates          0         31     0.5 kB          5.809s
                   public.problem          0         34     3.4 kB          6.004s
                    public.hstgrp          0         26     1.5 kB          6.212s
                    public.module          0         27     0.9 kB          6.343s
                     public.hgset          0         19     1.3 kB          6.497s
               public.host_rtdata          0         13     0.1 kB          6.690s
               public.expressions          0         10     0.5 kB          6.691s
               public.escalations          0         15     0.7 kB          6.847s
                public.permission          0          7     0.0 kB          6.810s
                public.conditions          0          6     0.1 kB          6.961s
                    public.usrgrp          0          6     0.2 kB          6.958s
                   public.regexps          0          5     0.2 kB          7.101s
               public.graph_theme          0          4     0.9 kB          7.071s
             public.opmessage_grp          0          4     0.0 kB          7.248s
              public.httpstepitem          0          3     0.0 kB          7.275s
                   public.scripts          0          3     0.3 kB          7.423s
             public.sysmaps_links          0          3     0.4 kB          7.411s
              public.acknowledges          0          1     0.0 kB          7.573s
            public.interface_snmp          0          2     0.1 kB          7.510s
                     public.proxy          0          2     0.1 kB          7.738s
                     public.ugset          0          2     0.1 kB          7.531s
                   public.dchecks          0          1     0.0 kB          7.727s
              public.autoreg_host          0          0                     7.722s
        public.config_autoreg_tls          0          1     0.0 kB          7.899s
             public.connector_tag          0          0                     7.852s
      public.corr_condition_group          0          0                     7.925s
    public.corr_condition_tagpair          0          0                     8.054s
            public.corr_operation          0          0                     8.049s
            public.dashboard_user          0          0                     8.200s
                    public.dhosts          0          1     0.0 kB          8.190s
                 public.dservices          0          1     0.2 kB          8.298s
               public.globalmacro          0          1     0.0 kB          8.291s
           public.group_discovery          0          0                     8.472s
               public.history_log          0          0                     8.467s
                  public.httpstep          0          1     0.1 kB          8.693s
                  public.httptest          0          1     0.1 kB          8.688s
              public.httptest_tag          0          0                     8.849s
              public.icon_mapping          0          0                     8.821s
    public.lld_override_ophistory          0          0                     9.102s
     public.lld_override_opperiod          0          0                     8.981s
        public.lld_override_optag          0          0                     9.132s
     public.lld_override_optrends          0          0                     9.350s
              public.maintenances          0          1     0.0 kB          9.347s
        public.maintenances_hosts          0          1     0.0 kB          9.557s
                 public.opcommand          0          0                     9.548s
             public.opcommand_hst          0          0                     9.736s
                   public.opgroup          0          1     0.0 kB          9.738s
             public.opmessage_usr          0          0                     9.954s
                public.optemplate          0          1     0.0 kB          9.950s
            public.proxy_dhistory          0          0                    10.057s
                    public.report          0          0                    10.101s
               public.report_user          0          0                    10.120s
                public.scim_group          0          0                    10.198s
            public.service_alarms          0          0                    10.219s
       public.service_problem_tag          0          0                    10.271s
               public.service_tag          0          0                    10.329s
            public.services_links          0          0                    10.363s
     public.sla_excluded_downtime          0          0                    10.401s
           public.sla_service_tag          0          0                    10.487s
        public.sysmap_element_url          0          0                    10.484s
                public.sysmap_url          0          0                    10.618s
             public.sysmap_usrgrp          0          0                    10.537s
     public.sysmaps_link_triggers          0          0                    10.622s
                      public.task          0          0                    10.677s
        public.task_close_problem          0          0                    10.752s
       public.task_remote_command          0          0                    10.763s
               public.task_result          0          0                    10.812s
                     public.token          0          0                    10.864s
           public.user_scim_group          0          0                    10.940s
    public.userdirectory_idpgroup          0          0                    10.955s
       public.userdirectory_media          0          0                    11.072s
      public.userdirectory_usrgrp          0          0                    11.029s
          public.valuemap_mapping          0      30621   861.6 kB         11.359s
               public.trends_uint          0     345750    11.3 MB          3.151s
                  public.item_tag          0      19823   598.5 kB          0.772s
              public.item_preproc          0      11373   603.2 kB          0.888s
                 public.functions          0       9445   268.0 kB          1.304s
            public.item_discovery          0       5629   129.7 kB          1.377s
                 public.hostmacro          0       4612   360.1 kB          1.518s
                    public.events          0       3494   252.6 kB          1.644s
                    public.alerts          0       3083   844.7 kB          1.838s
           public.trigger_depends          0       1819    32.0 kB          2.011s
                  public.auditlog          0       5350   642.1 kB          2.329s
            public.event_recovery          0       1362    27.6 kB          2.490s
               public.item_rtname          0        917    60.6 kB          2.691s
          public.media_type_param          0        555    22.0 kB          2.867s
                     public.hosts          0        318   133.3 kB          3.229s
              public.hosts_groups          0        307     3.7 kB          3.413s
              public.history_text          0        211     3.7 MB          3.957s
        public.media_type_message          0        154    41.1 kB          4.150s
            public.event_suppress          0        143     3.5 kB          4.421s
            public.lld_macro_path          0        134     4.5 kB          4.481s
               public.problem_tag          0        150     3.6 kB          4.600s
    public.lld_override_operation          0         98     2.9 kB          4.726s
              public.lld_override          0         95     3.7 kB          4.842s
    public.lld_override_condition          0         85     3.6 kB          4.946s
                     public.users          0         63     7.8 kB          5.092s
                       public.ids          0         51     1.3 kB          5.177s
            public.item_parameter          0         43     1.7 kB          5.288s
           public.group_prototype          0         28     0.9 kB          5.371s
                 public.role_rule          0         27     0.8 kB          5.505s
                 public.interface          0         24     1.1 kB          5.670s
                public.media_type          0         31   256.8 kB          5.707s
               public.hgset_group          0         19     0.1 kB          5.649s
            public.host_discovery          0         11     0.2 kB          5.789s
                public.operations          0         10     0.2 kB          5.792s
                 public.opmessage          0          8     0.1 kB          5.806s
                    public.rights          0          7     0.1 kB          5.872s
                  public.sessions          0          6     0.5 kB          5.985s
                   public.actions          0          5     0.3 kB          5.883s
          public.sysmaps_elements          0          5     0.8 kB          5.978s
               public.housekeeper          0          4     0.1 kB          5.993s
                      public.role          0          4     0.1 kB          5.966s
              public.httptestitem          0          3     0.0 kB          6.161s
                   public.sysmaps          0          3     0.2 kB          6.102s
               public.ugset_group          0          3     0.0 kB          6.098s
          public.dashboard_usrgrp          0          2     0.0 kB          6.088s
                     public.media          0          3     0.1 kB          6.262s
              public.proxy_rtdata          0          2     0.0 kB          6.239s
                    public.config          0          1     0.7 kB          6.237s
                   public.ha_node          0          1     0.1 kB          6.223s
                 public.changelog          1          0                     6.382s
                 public.connector          0          0                     6.371s
            public.corr_condition          0          0                     6.354s
        public.corr_condition_tag          0          0                     6.365s
   public.corr_condition_tagvalue          0          0                     6.487s
               public.correlation          0          0                     6.505s
                 public.dbversion          0          1     0.0 kB          6.513s
                    public.drules          0          1     0.0 kB          6.500s
             public.event_symptom          0          0                     6.610s
                public.globalvars          0          1     0.0 kB          6.631s
               public.history_bin          0          0                     6.634s
            public.host_inventory          0          1     0.3 kB          6.640s
            public.httpstep_field          0          0                     6.735s
            public.httptest_field          0          0                     6.747s
                  public.icon_map          0          0                     6.771s
       public.interface_discovery          0          0                     6.767s
  public.lld_override_opinventory          0          0                     6.868s
   public.lld_override_opseverity          0          0                     6.883s
   public.lld_override_optemplate          0          0                     6.908s
           public.maintenance_tag          0          0                     6.906s
       public.maintenances_groups          0          0                     7.003s
      public.maintenances_windows          0          1     0.0 kB          7.016s
             public.opcommand_grp          0          0                     7.036s
              public.opconditions          0          0                     7.031s
               public.opinventory          0          0                     7.129s
                     public.optag          0          0                     7.147s
        public.proxy_autoreg_host          0          0                     7.178s
             public.proxy_history          0          0                     7.191s
              public.report_param          0          0                     7.224s
             public.report_usrgrp          0          0                     7.305s
              public.script_param          0          0                     7.244s
           public.service_problem          0          0                     7.348s
       public.service_status_rule          0          0                     7.366s
                  public.services          0          0                     7.318s
                       public.sla          0          0                     7.411s
              public.sla_schedule          0          0                     7.473s
    public.sysmap_element_trigger          0          0                     7.455s
              public.sysmap_shape          0          1     0.1 kB          7.407s
               public.sysmap_user          0          0                     7.582s
       public.sysmaps_element_tag          0          0                     7.602s
                public.tag_filter          0          0                     7.517s
          public.task_acknowledge          0          0                     7.653s
                 public.task_data          0          0                     7.574s
public.task_remote_command_result          0          0                     7.725s
               public.timeperiods          0          1     0.0 kB          7.643s
             public.trigger_queue          0          0                     7.726s
             public.userdirectory          0          0                     7.770s
        public.userdirectory_ldap          0          0                     7.744s
        public.userdirectory_saml          0          0                     7.785s
                  public.valuemap          0        944    62.8 kB          7.835s
---------------------------------  ---------  ---------  ---------  --------------
          COPY Threads Completion          0          4                    51.236s
                  Reset Sequences          0          1                     0.110s
                 Install Comments          0          0                     0.000s
---------------------------------  ---------  ---------  ---------  --------------
                Total import time          1    7071507   255.7 MB         51.346s

Ve chvíli, kdy nám pgloader úspěšně doběhne, nastavení hashovacího algorytmu vrátíme zpět na bezpečnější hodnotu ‚SCRAM-SHA-256‘ a databázovému uživateli opět přegenerujeme heslo. Hvězdičky v následujícím příkazu nahraďte vámi zvoleným heslem:

sudo -u postgres psql -c "SET password_encryption='SCRAM-SHA-256';"
sudo -u postgres psql -c "ALTER ROLE zabbix WITH PASSWORD '************';"

Následně vytvoříme schéma pro indexy:

sudo -u postgres psql --host=127.0.0.1 --dbname=zabbix --username=zabbix -f /tmp/zabbix-db-migration/create_index.sql

Následně pak schéma pro alter table:

sudo -u postgres psql --host=127.0.0.1 --dbname=zabbix --username=zabbix -f /tmp/zabbix-db-migration/alter_table.sql

A nakonec i schéma pro triggers:

sudo -u postgres psql --host=127.0.0.1 --dbname=zabbix --username=zabbix -f /tmp/zabbix-db-migration/triggers.sql

Po úspěšné migraci doporučujeme spustit VACUUM:

sudo -u postgres vacuumdb --dbname=zabbix --analyze --username=postgres --jobs=$(grep -c processor /proc/cpuinfo)

Testování funkčnosti

Nejprve odstraníme podporu MySQL pro Zabbix a MySQL frontend:

yum remove zabbix-server-mysql zabbix-web-mysql

Nainstalujeme závislosti potřebné pro běh Zabbix serveru s PostgreSQL včetně frontendu.

Pozor: Reinstalací Zabbix serveru se ztratí konfigurace v souboru zabbix_server.conf! Doporučujeme zálohu!

yum install zabbix-server-pgsql zabbix-web-pgsql zabbix-apache-conf

Otevřeme konfigurační soubor Zabbix serveru:

nano /etc/zabbix/zabbix_server.conf

A zde upravíme direktivu pro přístup do databáze na nové přístupové údaje pro PostgreSQL. Hvězdičky nahraďte aktuálním heslem uživatele ‚zabbix‘:

DBPassword=*******

Odebereme starý konfigurační soubor frontendu pro MySQL:

rm /etc/zabbix/web/zabbix.conf.php

Zrestartujeme Zabbix server a Apache web server:

systemctl restart zabbix-server httpd

Zkontrolujeme log Zabbixu, abychom se ujistili, že všechno naběhlo v pořádku a bez jakýchkoliv problémů.

nano /var/log/zabbix/zabbix_server.log

Pomocí prohlížeče se připojíme na URL Zabbix frontendu a znovu frontend nastavíme, tentokrát pro PostgreSQL.

Nejprve nás přivítá úvodní obrazovka s volbou jazyka:

Následuje kontrola požadovaných verzí a nastavení, kde již můžeme vidět nainstalovanou podporu pro PostgreSQL:

V dalším kroku nás čeká nastavení databáze, kde vyplníme přihlašovací údaje vytvořené v předchozích krocích:

Vybereme název Zabbix serveru, časové pásmo a implicitní téma:

Pak už zbývá jen zkontrolovat, že máme všechno nastavené správně a tyto volby potvrdit:

A nyní máme úspěšně napojený Zabbix frontend na PostgreSQL!

V tuto chvíli můžeme zastavit MySQL server:

systemctl stop mysqld

A MySQL lze nyní i zcela odinstalovat. Data (ve standardní cestě /var/lib/mysql) nebudou smazána, ale doporučujeme je např. po 14 dnech funkčního provozu s PostgreSQL smazat.

yum remove mysql

TimescaleDB

Potom, co jsme úspěšně zmigrovali z MySQL do PostgreSQL se nám zároveň nabízí možnost ještě více zvýšit výkonnost Zabbixu pomocí TimescaleDB.

Vzhledem k tomu, že už máme rozbalený soubor se zdrojovým kódem, který obsahuje i databázová instalační schámata, můžeme rovnou přistoupit instalaci.

Začneme tím, že přidáme oficiální repozitář:

tee /etc/yum.repos.d/timescale_timescaledb.repo <<EOL
[timescale_timescaledb]
name=timescale_timescaledb
baseurl=https://packagecloud.io/timescale/timescaledb/el/$(rpm -E %{rhel})/\$basearch
repo_gpgcheck=1
gpgcheck=0
enabled=1
gpgkey=https://packagecloud.io/timescale/timescaledb/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300
EOL

Nainstalujme potřebné balíčky:

yum install timescaledb-2-postgresql-18 timescaledb-2-loader-postgresql-18

Spustíme utilitu timescaledb-tune a jako parametr jí předáme vyšší hodnotu maximálního množství připojení (--max-conns), které pro tyto testovací účely nastavíme na 125.

Tato utilita slouží k přizpůsobení výchozího nastavení PostgreSQL směrem k výkonu a adekvátnímu nastavení parametrů PostgreSQL pro fungování s TimescaleDB.

Zároveň nám tato utilit pomocí instalačního průvodce pomůže vybrat aktuální a platný konfigurační soubor PostgreSQL a nastaví i automatické načítání knihoven TimescaleDB.

Prosím, odpovídejte „ano“ (y) na všechny otázky.

timescaledb-tune --pg-config /usr/pgsql-18/bin --max-conns=125

Následně vypneme Zabbix server a restartujeme systémovou službu PostgreSQL:

systemctl stop zabbix-server
systemctl restart postgresql-18

Aktivujeme TimescaleDB pro databázi Zabbixu:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql --dbname=zabbix

A načíst data z rozbaleného souboru databázového schématu:

sudo -u postgres psql --host=127.0.0.1 --dbname=zabbix --username=zabbix -f /tmp/zabbix-db-migration/zabbix-7.0.0/database/postgresql/timescaledb/schema.sql

Nyní můžeme opětovně nastartovat službu Zabbix serveru.

systemctl start zabbix-server

V případě, že uvidíte v log souboru zprávu o tom, že je verze TimescaleDB příliš nová, pak to není žádný velký problém. Zabbix nedokáže dostatečně rychle reagovat na nejnovější verze TimescaleDB tak, aby ji ve svém kódu nastavil jako podporovanou, ovšem kompatibilita je Zabbixem zaručena a námi ověřena.

Pokud se chceme vyhnout zprávám o nekompatibilitě v log souboru Zabbixu, pak stačí otevřít konfigurační soubor Zabbix serveru v cestě /etc/zabbix/zabbix_server.conf a zde upravte následující konfigurační parametr:

AllowUnsupportedDBVersions=1

Soubor s tímto nastavením uložte a znovu nastartujte systémovou službu Zabbix serveru.

systemctl start zabbix-server

A to je vše! Nyní jste se naučili, jak zmigrovat Zabbix databázi z MySQL do PostgreSQL, dále se vám podařilo zprovoznit výkonnou TimescaleDB a máte základní performance tuning. Následující kroky by měly smeřovat k zálohování a monitoringu DB.

The post Zabbix – Migrace z MySQL do PostgreSQL appeared first on initMAX s.r.o..

NovýPostgreSQL

15. 3. 2023

Řízení přístupu do PostgreSQL prostřednictvím externího autentizačního providera

Zhlédnout záznam

Základní požadavky

Zde je výčet základních požadavků pro funkční nastavení ověřování uživatelů z Active Directory v PostgreSQL pomocí Kerberos (GSS):

1. nainstalovaný server PostgreSQL
2. nainstalovou podporu a nastavení pro Kerberos na DB serveru
3. uživatelský účet v Active Directory pro PostgreSQL
4. vytvořený Kerberos keytab pro uživatele v Active Directory
5. nastavený PostgreSQL pro Kerberos a GSSAPI
6. uživatelský účet v PostgreSQL totožný s účtem v Active Directory (nebo ldap2pg)
7. ověřovací Kerberos ticket pro DB uživatele v Active Directory

Instalace a konfigurace Kerberos

Nejprve na databázovém serveru nainstalujeme základní balíčky, které obsahují knihovny, a binární i konfigurační soubory pro podporu Kerberos.

dnf install krb5-server krb5-workstation

V případě, že chceme používat k autentizaci Kerberos i na samotném klientu (potažmo serveru), je potřeba mít zde i správně nastavený Kerberos.

Ovšem PostgreSQL samotný toto nastavení pro funkční ověřování uživatelů nepotřebuje.

Kerberos se na úrovni OS nastavuje v konfiguračním souboru /etc/krb5.conf a tento soubor může upravovat pouze privilegovaný uživatel root.

Vzorová konfigurace může kupříkladu vypadat následovně:

[logging]
default = /var/log/krb5libs.log
kdc = /var/log/krb5kdc.log
admin_server = /var/log/kadmind.log

[libdefaults]
default_realm = DEMO.INITMAX.CZ
dns_lookup_realm = false
# ticket_lifetime = 24h
# renew_lifetime = 7d
forwardable = true
udp_preference_limit = 1
default_ccache_name = KEYRING:persistent:%{uid}

[realms]
DEMO.INITMAX.CZ = {
kdc = demo.initmax.cz
admin_server = demo.initmax.cz
}

[domain_realm]
.demo.initmax.cz = DEMO.INITMAX.CZ
demo.initmax.cz = DEMO.INITMAX.CZ

Uživatelský účet v Active Directory

Na úrovni Active Directory běžným způsobem vytvoříme servisní účet, který v našem případě nazveme pg_db_srv01.

A následně vytvoříme níže zobrazeným příkazem tzv. Kerberos keytab, který k tomuto servisnímu účtu přiřadíme.

ktpass –princ POSTGRES/pgsql.demo.initmax.cz@DEMO.INITMAX.CZ -pass %heslo% -mapuser pg_db_srv01 -crypto ALL -ptype KRB5_NT_Principal -out pgsql.demo.initmax.cz.keytab

Takto vzniklý Kerberos keytab si zkopírujeme a přesuneme ho na klienta, v našem případě tedy na databázový server, například do složky /etc.

Přímo na databázovém serveru si pak můžeme ověřit, že vytvořený keytab skutečně funguje, a to následujícím příkazem:

kinit -k -t /etc/pgsql.demo.initmax.cz.keytab POSTGRES/pgsql.demo.initmax.cz@DEMO.INITMAX.CZ -V

Pokud nám příkaz kinit na konci svého běhu ve výstupu zobrazí hlášku Authenticated to Kerberos, pak je keytab funkční a my můžeme překročit ke konfiguraci samotného PostgreSQL.

Vzorový výstup výše zmíněného příkazu kinit s funkčním souborem keytab můžete vidět zde:

Using existing cache: 0
Using principal: POSTGRES/pgsql.demo.initmax.cz@DEMO.INITMAX.CZ
Using keytab: /etc/pgsql.demo.initmax.cz.keytab
Authenticated to Kerberos v5

Konfigurace PostgreSQL

Nejprve upravíme konfigurační soubor PostgreSQL (postgresql.conf) tak, aby věděl, kde mu leží náš Kerberos keytab a tudíž ho korektně načetl a použil.

K tomu slouží následující konfigurační direktiva krb_server_keyfile, jejíž hodnotu naplníme absolutní cestou ke Kerberos keytabu.

V našem případě tedy /etc/pgsql.demo.initmax.cz.keytab.

krb_server_keyfile=/etc/pgsql.demo.initmax.cz.keytab

Následně v konfiguračním souboru nastavujícím přístupy, tedy pg_hba.conf povolíme lokální i vzdálené ověřování pomocí metody GSSAPI se správně nastaveným Kerberos realm.

# IPv4 local connections:
#host all all 127.0.0.1/32 ident
host all all 0.0.0.0/0 gss include_realm=0 krb_realm=DEMO.INITMAX.CZ

Poté se připojíme k serveru pomocí psql a vytvoříme uživatele na úrovní samotného PostgreSQL a nastavíme mu požadováná oprávnění.

Pozor! Tento uživatel musí odpovídat skutečnému uživatli v Active Directory!

create user "ad_user" superuser;

Jako další krok můžeme konzoli psql opustit a příkazem kinit získáme (po zadání správného hesla) ověřovací ticket pro našeho uživatele z Active Directory serveru:

kinit ad_user

A v tuto chvíli se již pod tímto uživatelem můžeme přihlásit přímo do PostgreSQL bez nutnosti zadání hesla, jelikož se pro ověření použije ticket, získaný výše.

psql -U "ad_user" -h csas-pgsql.win.initmax.cz postgres

Nespornou nevýhodou tohoto nativního řešení pak (v závislosti na velikosti prostředí) zůstává nutnost uživatele ručně vytvářet na úrovni PostgreSQL.

Tyto činnosti je však možné zautomatizovat, a to pomocí ldap2pg, na což se podíváme v následující kapitole.

ldap2pg

Toto je nástroj, který na základě předem nastavených parametrů automatizuje vytváření, aktualizaci i odebírání rolí na PostgreSQL podle nastavení v LDAP.

ldap2pg je skript napsaný v jazyku Python, a pro svůj běh vyžaduje kromě Pythonu samotného (v2.6+ nebo v3.4+) i další závislé balíčky.

Konkrétně to jsou Pyyaml, python-ldap a python-psycopg2.

Instalace

Doporučovaná metoda instalace je v případě RHEL přímo z oficiálního repozitáře PostgreSQL (PGDG) a v případě Debian pak pomocí pip.

Pokud chceme balíčky co nejaktuálnější, pak využijeme přímo repozitář Dalibo labs.

V našem případě používáme Rocky Linux 9 a tudíž si oficiální repozitář Dalibo labs přidáme následujícím příkazem a následně obnovíme dnf cache.

dnf install -y https://yum.dalibo.org/labs/dalibo-labs-4-1.noarch.rpm
dnf makecache fast

Další možností je vytvoření repozitáře ručně. To uděláme tak, že vytvoříme nový soubor /etc/yum.repos.d/dalibolabs.repo a ten naplníme následujícím obsahem:

[dalibolabs]
name = Dalibo Labs - RHEL/CentOS/Rockylinux $releasever - $basearch
baseurl = https://yum.dalibo.org/labs/RHEL$releasever-$basearch
gpgcheck = 1
enabled = 1

Soubor uložíme a zaktualizujeme dnf cache:

dnf makecache fast

Potom, co máme přidaný repozitář, můžeme přejít k samotné instalaci ldap2pg a všech jeho závislostí:

dnf install ldap2pg

Jakmile máme ldap2pg úspěšně nainstalován, tak můžeme překročit k jeho konfiguraci.

Nastavení

ldap2pg standardně vyhledává svůj konfigurační soubor v těchto cestách:

• ldap2pg.yml v aktuálním pracovním adresáři
• ~/.config/ldap2pg.yml
• /etc/ldap2pg.yml

Lze však nastavit i cestu vlastní a to spuštění ldap2pg s parametrem --config, toto lze využít například pro spuštění několika instancí ldap2pg s různými konfiguračními soubory.

Zde můžete pro ukázku vidět příklad takové konfigurace:

postgres:
  dsn: postgres://alfa@csas-pgsql.win.initmax.cz:5432/postgres
  roles_blacklist_query:
  - postgres
  - "pg_*"
  - "rds_*"

ldap:
  uri: ldap://dc1.win.initmax.cz
  binddn: CN=Test User Alfa,OU=Users,OU=testAcounts,DC=win,DC=initmax,DC=cz
  password: "%heslo%"

sync_map:
- role:
  name: alfa
  options: LOGIN SUPERUSER
  names:
  - ad_roles
  comment: "LDAP role managed by ldap2pg."

- ldapsearch:
    base: CN=pg_DBA_users,OU=Groups,OU=testAcounts,DC=win,DC=initmax,DC=cz
  role:
    name: 'dba_{member.samaccountname}'
    options: LOGIN SUPERUSER
    parent: ad_roles
    comment: "Synced from AD: {dn}"

- ldapsearch:
    base: CN=pg_RO_users,OU=Groups,OU=testAcounts,DC=win,DC=initmax,DC=cz
  role:
    name: '{member.samaccountname}'
    options: LOGIN
    parent: ad_roles
    comment: "Synced from AD: {dn}"

Tento ukázkový konfigurační soubor obsahuje několik částí.

V části postgres: definujeme připojení k databázovému serveru a k databázi, včetně přihlašovacích údajů. Z bezpečnostních důvodů doporučujeme přihlašovací heslo v konfiguračním souboru nepoužívat, ale namísto toho uživatele ověřovat přes Kerberos ticket, jak je ukázáno právě v tomto návodu. Součástí této sekce je i direktiva roles_blacklist_query: nám určuje seznam lokálních rolí v PostgreSQL, které bude ldap2pg ignorovat. Povšimněte si možnosti využití zástupných znaků.

V části ldap: definujeme připojení k Active Directory, nebo jinému LDAP serveru. Tato sekce je v tomto konfiguračním souboru volitelná a informace o nastavení LDAP si nástroj ldap2pg umí načíst i z jakéhokoliv standardního umístění těchto systémových konfiguračních souborů (např. /etc/ldap.conf), kde je záhodno mít případně uloženo i heslo pro bind uživatel v LDAP.

Poslední sekci sync_map: pak používáme k mapování uživatelů a rolí. Na jejím začátku definujeme příklad lokální, statické role pro admin uživatele „alfa“ s právém přihlásit se a rolí SUPER USER. Zároveň v této sekci vytváříme uživatelskou roli ad_roles, do které následně přiřazujeme další, automaticky vytvořené uživatele pomocí ldap2pg (a této roli je vytvořen i takto formulovaný komentář). V podsekcích ldapsearch: pak definujeme jednotlivá BaseDN, tedy cesty ve struktuře LDAP, kde má ldap2pg uživatele hledat. Vzorově zde vytváříme databázové administrátory (ze skupiny pg_DBA_users) a uživatele pro čtení (ze skupiny pg_RO_users) s jejich příslušnými oprávěními a komentáři. Jako nadřazenou roli mají ad_roles, kterou jsme si definovali v předchozí podsekci.

Testování a spuštění

Nespornou výhodou nástoje ldap2pg je rovněž možnost si vytvořené nastavení nanečisto otestovat (tzv. dry run), a to pomocí spouštěcího parametru --dry, jehož výstup s naší vzorovou konfigurací můžete vidět zde:

Starting ldap2pg 5.8.
Using /root/ldap2pg.yml.
Connecting to LDAP server ldap://dc1.win.initmax.cz.
Trying simple bind.
Running in dry mode. Postgres will be untouched.
Inspecting roles in Postgres cluster...
Querying LDAP CN=pg_DBA_users,OU=Group... (objectClass...
Missing 'member' from CN=pg_DBA_users,OU=Groups,OU=testAcounts,DC=win,DC=initmax,DC=cz.
Considering it as an empty list.
Querying LDAP CN=pg_RO_users,OU=Groups... (objectClass...
Missing 'member' from CN=pg_RO_users,OU=Groups,OU=testAcounts,DC=win,DC=initmax,DC=cz. Considering
it as an empty list.
Nothing to do.
Comparison complete.

V případě, že test proběhl úspěšně, pak ldap2pg spustíme s parametrem --real, který už námi otestovanou konfiguraci přímo projeví konkrétními změnami v PostgreSQL.

Pro tento příkaz pak stačí už jen vytvořit pravidelně spouštěnou úlohu, například pomocí cron.

ldap2pg --real

V tuto chvíli tak máme funkční ověřování uživatelů do PostgreSQL pomocí Kerberos, včetně automatizace jejich správy z údajů v Active Directory, a to pomocí nástroje ldap2pg.

The post PostgreSQL – Řízení přístupu prostřednictvím externího autentizačního providera appeared first on initMAX s.r.o..