Zaplnění disku při upgradu primárních klíčů

[bsman123]

Dobrý den,
snažím se upgradovat DB (Zabbix 5.X -> 6.X, upgrade primárních klíčů), ale operace nedoběhne pro zaplnění disku při skriptu history_pk_uint.sql (https://www.zabbix.com/documentation...ql-timescaledb). Nesetkal se někdo se stejným případem?

Abych nemusel ostrý DB server odstavit po dobu upgradu, vytvořil jsem nový, na kterém jsem provedl přes pg_dump/pg_restore (se zohledněním Timescale) import dat.

Podrobněji:

• upgrade primárních klíčů prováděn na Debian 12 s PostgreSQL 13 (poslední dostupná minor. verze) a Timescale 2.X (poslední dostupná minor. verze)
• z ostrého DB serveru (Centos 7) data exportována pomocí pg_dump (dle dokumentace Timescale rozděleno na dump s exportem rolí a dump s exportem dat) a importována bez chyb (žádná chybová hláška při importu) přes pg_restore
  • oba servery mají identickou verzi PostgreSQL (major & minor číslo) i Timescale (major & minor číslo)
  • dump dat má 60GB
• upgrade primárních klíčů prováděn přesně podle https://www.zabbix.com/documentation...ql-timescaledb ve variantě s kompresí
• skript history_pk.sql doběhne bez chyb, dočasné CSV má 8GB
• skript history_pk_uint.sql nedoběhne kvůli vyčerpání volného místa diskového oddílu
  • dočasné CSV má 53GB
  • diskový oddíl má 300GB, po vytvoření CSV je stále cca 189GB volného
  • temp tabulka vytvářená skriptem má cca 88GB
  • po vytvoření temp tabulky jsem dočasné CSV smazal, abych přidal trochu volného místa, ale stejně došlo k zaplnění disku (tedy měl cca 242GB volného k dispozici)

Nesetkal se někdo s něčím podobným? Případně jak velký disk je potřeba? Provozováno je to ve virtualizaci a abych server mohl nechat na rychlých discích, nemohu se s kapacitou příliš roztahovat. Teoreticky mohu oddíl pro DB natáhnout na 400GB, ale otázkou je, jestli neřeším nějaký bug a nevyčerpám to i tak.

Předem děkuji

[hermanekt]

Ahoj,

je to normalni. Tvori se ti totiz jeste index. Musis aby to bylo 100% spravne zvetsit disk. Muzes docasne pridat partisnu an kterou hodis vse co je ve /var/lib/pgsql a namountujes a udelas klice. Pak odmountujes prekoporujes na puvodni disk a docasny disk muzes zrusit. Podle me ti chybi tak 20gb volneho mista ale zbytecne jen pro tenhle upgrade natahovat disk...

Tom

[bsman123]

Díky za radu. Bývá tahle tabulka největší? Jestli mám očekávat podobné trable s těmi dalšími skripty také.

[hermanekt]

Je to tak, jak projdes uint tak jsi podle me ok. Zatim jsem to nevidel jinak.

[bsman123]

Děkuji za dobrou radu! Připojil jsem si další dočasný disk a upravil si oficiální skripty tak, aby dočasné CSV a temp tabulky umísťoval do toho externího disku. Upgrade proběhl, ale významě se liší velikosti DB:

• server v produkci (CentOS 7): /var/lib/pgsql/13/data = cca 42GB
• resore DB na novém serveru (Debian 12): /var/lib/postgresql/13/main = cca 195GB

Lehké navýšení bych pochopil, ale toto je enormní... Neřešil jste něco podobného? Zatím jsem nad tím hlubší analýzu nedělal, že bych například počítal velikost tabulek.

Díky

[hermanekt]

Zdravim, to bude nejspise tim, ze TimescaleDB jeste neudelal znovuzabaleni dat. Az se to zabali tak to spadne na cca puvodni velikost tech 42GB. Pokud se to ani po par dnech nespusti, tak bych urcite zkontrolovat stav TimescaleDB extenze v PostgreSQL.

Projdi si jeste tento zaklad: https://docs.timescale.com/use-times...oubleshooting/

Tom

PS: Hned se to nebali, resi si to primo extenze nikoliv Housekeeper.