Upgrade vaší databáze na PostgreSQL verze 10 – Co byste měli vědět

Jak se na webu objevuje stále více příspěvků o PostgreSQL 11, tím zastaralejší se můžete při používání Postgres 9 cítit. Přestože k vydání verze PostgreSQL 10 došlo teprve před několika měsíci, lidé již mluví o další verzi. Věci se hýbou, takže nechcete zůstat pozadu. V tomto blogu probereme to, co potřebujete vědět, abyste upgradovali na nejnovější verzi, Postgres 10.

Možnosti upgradu

První věc, kterou byste si měli uvědomit, než začnete, je, že existuje několik způsobů, jak provést upgrade:

1. Tradiční pg_dumpall(pg_dump) / pg_restore(psql)
2. Tradiční pg_upgrade
3. Replikace založená na spouštěči (Slony, vlastnoručně napsaná)
4. Použití pglogické replikace

Proč existuje taková rozmanitost? Protože každý z nich má jinou historii, vyžaduje různé úsilí při nastavení a nabízí různé služby. Pojďme se na každou z nich podívat blíže.

Tradiční výpis/obnovení

pg_dump t > /tmp/f
psql -p 5433 -f /tmp/f

Tradiční výpis/obnovení trvá nejdéle, a přesto je často oblíbenou volbou pro ty, kteří si mohou dovolit prostoje. Za prvé, je to stejně snadné jako vzít logickou zálohu a obnovit ji do nové, vyšší verze databáze. Dalo by se říci, že to není upgrade, opravdu, když „importujete“ svá data do „nové struktury“. V důsledku toho skončíte se dvěma nastaveními - jedním starým (nižší verze) a nově upgradovaným. Pokud proces obnovy skončí bez chyby, jste skoro tam. Pokud ne, musíte upravit stávající starý cluster, abyste odstranili všechny chyby a spustit proces znovu.

Pokud pro import používáte psql, možná budete muset sami vytvořit nějaké skripty předběžného načtení, které se před migrací spustí v novém nastavení. Například byste chtěli pg_dumpall -g získat seznam potřebných rolí k přípravě v novém nastavení, nebo naopak spustit pg_dump -x pro přeskočení oprávnění ze starého. Tento proces je na malých databázích docela jednoduchý, složitost roste s velikostí a složitostí vaší db struktury a závisí na tom, jaké funkce máte nastaveny. V zásadě, aby byla tato metoda úspěšná, musíte ji neustále zkoušet a opravovat, dokud nebude aktualizace úspěšná.

Mezi výhody použití této metody patří...

• I když s jednou vytvořenou zálohou můžete strávit dlouhou dobu, zatížení starého serveru je tak malé, jako byste si udělali jednu zálohu.
• Tato metoda je většinou pouze sekvence zálohování a obnovy (potenciálně s některými kouzly, písněmi a bubnováním)
• Použití této metody je nejstarší způsob upgradu a bylo ověřeno MNOHO lidmi

Když konečně dokončíte upgrade, musíte buď vypnout starý server, nebo se smířit se ztrátou dat (nebo alternativně přehrát DML, ke kterému došlo na starém serveru při obnově zálohy na nový server). A čas strávený tím je relativní k velikosti vaší databáze.

Můžete samozřejmě začít "používat" novou databázi před dokončením obnovy (zejména před vytvořením všech indexů - indexy často zaberou nejvíce času). Takové prostoje jsou však často nepřijatelné.

Tradiční pg_upgrade

MacBook-Air:~ vao$ /usr/local/Cellar/postgresql/10.2/bin/initdb -D tl0 >/tmp/suppressing_to_save_screen_space_read_it

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
MacBook-Air:~ vao$ /usr/local/Cellar/postgresql/10.2/bin/pg_upgrade -b /usr/local/Cellar/postgresql/9.5.3/bin -B /usr/local/Cellar/postgresql/10.2/bin -d t -D tl0 | tail
Creating script to delete old cluster                        ok

Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
    ./analyze_new_cluster.sh

Running this script will delete the old cluster’s data files:
    ./delete_old_cluster.sh

Tradiční pg_upgrade byl vytvořen, aby zkrátil čas potřebný k upgradu na hlavní verzi. V závislosti na množství vztahů, které máte, to může být až minuty (sekundy v směšných případech, jako je jedna databáze tabulek a hodiny v "opačných případech"), zejména s argumentem --link.

Sekvence přípravy se mírně liší od první metody upgradu. Chcete-li upgradovat napodobit a zkontrolovat, zda je to možné, měli byste sestavit streamovací replikaci nebo obnovit záložní server z WAL. Proč je to tak složité? Chcete si být jisti, že upgrade otestujete v databázi jako blízko stavu, jako jste původně měli. Zde nám pomůže „binární“ replikace neboli PITR. Po dokončení obnovy a recovery_target_action =promotion (PITR) nebo povýšení nově vytvořeného slave (pg_ctl promotion nebo umístění spouštěcího souboru) (streamingová replikace) můžete zkusit spustit pg_upgrade. Kontrola pg_upgrade_internal.log vám dá představu, zda byl proces úspěšný nebo ne. Kromě toho máte stejný přístup pokusu a opravy jako předchozí metoda. Akce provedené proti testovací databázi uložíte do skriptu, dokud ji úspěšně nepg_upgradujete. Navíc můžete zničit již nepotřebný test upgradované databáze, spusťte thensaved skript pro přípravu původní databáze pro provedení upgradu.

Mezi výhody použití této metody patří…

• Kratší prostoje než logické zálohování/obnovení
• Skvělý proces – pg_upgrade upgraduje původní databázi stávajícími daty a strukturou
• V minulosti se často používal a stále by byl preferován pro většinu správců databází s verzí nižší než 9.4 (která umožňuje použití pglogical)

Mezi nevýhody použití této metody patří…

• Vyžaduje odstávku

Replikace založená na spouštění

Za předpokladu, že verze 10 je na portu 5433 a má připravenou stejnou tabulku:

db=# create server upgrade_to_10 foreign data wrapper postgres_fdw options (port '5433', dbname 'dbl0');
CREATE SERVER
Time: 9.135 ms
db=# create user mapping for vao SERVER upgrade_to_10 options (user 'vao');
CREATE USER MAPPING
Time: 8.741 ms
db=# create foreign table rl0 (pk int, t text) server upgrade_to_10 options (table_name 'r');
CREATE FOREIGN TABLE
Time: 9.358 ms

Toto je extrémně zjednodušující fn() a spouštěč pro velmi základní logickou replikaci. Takový přístup je tak primitivní, že nebude fungovat s cizími klíči, ale kód je krátký:

db=# create or replace function tf() returns trigger as $$
begin
 if TG_0P = 'INSERT' then
   insert into r10 select NEW.*;
 elseif TG_0P = 'UPDATE' then
   delete from rl0 where pk = NEW.pk;
   insert into rl0 select NEW.*;
 elseif TG_0P = 'DELETE' then
   delete from rl0 where pk = OLD.pk;
 end if;
return case when TG_0P in ('INSERT','UPDATE') then NEW else OLD end;
end;
SS language plpgsql;
CREATE FUNCTION
Time: 8.531 ms
db=# create trigger t before insert or update or delete on r for each row execute procedure tf(); CREATE TRIGGER
Time: 8.813 ms

Příklad:

db=# insert into r(t) select chr(g) from generate_series(70,75) g;
INSERT 0 6
Time: 12.621 ms
db=# update r set t = 'updated' where pk=2;
UPDATE 1
Time: 10.398 ms
db=# delete from r where pk=1;
DELETE 1
Time: 9.634 ms
db=# select * from r;
 pk |    t
----+---------
  3 | H
  4 | I
  5 | J
  6 | K
  2 | updated
(5 rows)

Time: 9.026 ms
db=# select * from rl0;
 pk |    t
----+---------
  3 | H
  4 | I
  5 | J
  6 | K
  2 | updated
(5 rows)

Time: 1.201 ms

Nakonec zkontrolujeme, zda se replikujeme do jiné databáze:

db=# select *,current_setting('port') from dblink('upgrade.to.lO','select setting from pg_settings where name=$$port$$') as t(setting_10 text);
 setting_10 | currerrt.setting
------------+------------------
 5433       | 5432
(l row)

Time: 23.633 ms

Tuto metodu bych označil za nejexotičtější. Jak kvůli skutečnosti, že se streamingovou replikací a později s pglogic se použití replikace založené na spouštěči stává méně populární. Má vyšší zátěž na master, zvýšenou složitost během nastavování a nedostatek dobře strukturované dokumentace. Zde není žádná příprava (jako taková), protože chcete Slony pouze nastavit na různé hlavní verze.

Mezi výhody použití této metody patří…

• Není třeba provádět žádné zálohy a nejsou vyžadovány žádné prostoje (zejména když stojíte za nějakým pgbouncerem nebo haproxy).

Mezi nevýhody použití této metody patří…

• Vysoká složitost nastavení
• Nedostatek strukturované dokumentace
• Nepříliš populární – méně uživatelských případů ke studiu (a sdílení)

Ve stejném duchu je dalším možným způsobem upgradu samostatně psaná replikace spouštěče. Zatímco myšlenka je stejná (vytočíte novou databázi vyšší verze a nastavíte spouštěče na nižší verzi, abyste do ní posílali upravená data), samočinné nastavení vám bude jasné. Nebudete potřebovat žádnou podporu, a proto potenciálně spotřebováváte méně prostředků při jeho spuštění. Samozřejmě ze stejného důvodu pravděpodobně skončíte s tím, že některé funkce budou chybět nebo nebudou fungovat podle očekávání. Máte-li několik tabulek k přechodu na nové verze, taková možnost vám pravděpodobně zabere méně času a pokud je provedena dobře, může být méně náročná na zdroje. Jako bonus můžete s upgradem zkombinovat některé ETL transformace a přejít na novou verzi bez prostojů.

Logická replikace s pglogic

Jedná se o velmi slibný nový způsob upgradu Postgresu. Cílem je nastavit logickou replikaci mezi různými hlavními verzemi a doslova mít paralelní databázi vyšší (nebo nižší) verze se stejnými daty. Až budete připraveni, stačí přepnout připojení k vaší aplikaci ze starého na nové.

Mezi výhody použití této metody patří…

• V podstatě žádné prostoje
• Mimořádně slibná funkce, mnohem menší úsilí než replikace založená na spouštěči

Mezi nevýhody použití této metody patří…

• Nastavení je stále velmi složité (zejména u starších verzí)
• Nedostatek strukturované dokumentace
• Nepříliš populární – méně uživatelských případů ke studiu (a sdílení)

Migrace hlavní verze založené na spouštěči i na pglogické replikaci lze použít k downgradu verze (samozřejmě až na nějakou rozumnou hodnotu, např. pglogic je k dispozici pouze od verze 9.4 a replikace spouštěče je stále těžší a těžší nastavit jako verzi, kterou chcete přejít na starší verzi).

Opatření, která je třeba provést před upgradem

• Udělejte si zálohu
• Ujistěte se, že je na disku dostatek místa
• Zkontrolujte svá rozšíření (důležité je, že všechny externí moduly jsou také binárně kompatibilní, ačkoli to nelze zkontrolovat pomocí pg_upgrade)
• Ujistěte se, že v nové databázi používáte stejný datcollate a datctype atd. (zkontrolujte pg_database)
• Zkontrolujte (DDL + Drop) zobrazení, funkce, rozšíření, typy, které by mohly upgrade přerušit
• Před skutečným pg_upgrade použijte --check

Akce, které je třeba provést po upgradu

• Konzultujte stránku pg_upgrade_server.log (pokud jste použili pg_upgrade)
• Spustit analýzu na upgradovaných databázích (volitelné, protože by to bylo provedeno pomocí automatického vakua, ale můžete si vybrat, které vztahy se mají analyzovat jako první, pokud to uděláte sami)
• Předehřát oblíbené stránky (volitelné, ale na začátku by mohlo zvýšit výkon)

Závěr

Zde je několik obecných poznámek, které je dobré vědět, než se rozhodnete přejít na PostgreSQL verze 10…

• Byly představeny pg_sequences, které mění chování dříve oblíbeného SELECT * FROM název_sekvence – nyní pouze poslední_hodnota | log_cnt | is_cal jsou vráceny a skryjí před vámi „počáteční vlastnosti“ (upravte jakýkoli kód, který závisí na změněném chování)
• pg_basebackup ve výchozím nastavení streamuje WAL. Po upgradu možná budete muset upravit své skripty (volba -x odstraněna)
• Všechny akce pg_ctl čekají na dokončení. Dříve jste museli přidat -w, abyste se vyhnuli pokusu o připojení k databázi ihned po spuštění pg_ctl. Pokud tedy stále chcete používat "asynchronní" start nebo stop, musíte to výslovně označit pomocí -W. Možná budete muset upravit své skripty, aby se chovaly tak, jak bylo zamýšleno.
• Všechny skripty pro archivaci WAL nebo monitorování/řízení replikace streamování nebo PITR je třeba zkontrolovat a upravit je na změněná jména xlog. Např. select * from pg_is_xlog_replay_paused() vám již nebude ukazovat stav přehrávání slave WAL – musíte místo toho použít select * z pg_is_wal_replay_paused(). Také cp /blah/pg_xlog/* je třeba změnit na /bla/pg_wal/* a tak dále v podstatě pro všechny výskyty pg_xlog. Důvodem takové masivní změny, která není zpětně kompatibilní, je řešení případu, kdy nováček odstraní protokoly s předběžným zápisem, aby „vyčistil místo“ odstraněním protokolů, a ztratí databázi.
• Upravte skripty pomocí pg_stat_replication pro nová jména (umístění změněno na lsn)
• V případě potřeby upravte dotazy pomocí sady vracení funkcí
• Pokud jste používali pglogical jako rozšíření před verzí 10, možná budete muset upravit pg_hba.conf změnu hodnoty mezi "sloupci"
• Upravte skripty pro nový název pg_log, což je log, takže něco jako find /pg_data/pg_log/postgresql-*  -mmin +$((60*48)) -type f -exec bash /blah/moveto.s3 .sh {} \; by fungovalo. Samozřejmě můžete místo toho vytvořit symbolický odkaz, ale k nalezení protokolů ve výchozím umístění bude třeba podniknout akci. Další malou změnou výchozích hodnot je log_line_prefix – pokud váš regulární výraz závisel na určitém formátu, musíte jej upravit.
• Pokud jste ve svých databázích Postgres stále používali nezašifrovaná hesla, toto vydání dokončeno je odstraní. Je tedy čas vyřešit věci pro ty, kteří spoléhali na --unencrypted...
• Zbývající nekompatibilní změny s předchozími verzemi jsou buď příliš čerstvé, než aby na ně bylo odkazováno ve velkém množství kódu (min_parallel_relation_size), nebo příliš staré (externí tsearch2) nebo jsou příliš exotické (odstranění podpory časových razítek s pohyblivou řádovou čárkou v sestavení), takže přeskočíme je. Samozřejmě jsou uvedeny na stránce vydání.
• Jako tomu bylo u 9.5 až 9.6, možná budete muset upravit své skripty pro dotazování pg_stat_activity (jeden nový sloupec a nové možné hodnoty)
• Pokud jste ukládali/analyzovali vakuový podrobný výstup, možná budete muset upravit svůj kód
• Mohli byste se také podívat na novou implementaci rozdělení – možná budete chtít předělat svou stávající „sadu“ tak, aby vyhovovala novým „standardům“
• zkontrolujte časovou osu (bude resetována pro novou databázi, pokud provedete pg_upgrade)

Kromě těchto kroků, které musíte znát, abyste upgradovali na 10, existuje spousta věcí, které činí toto vydání velmi očekávaným. Přečtěte si prosím část o změnách v poznámkách k vydání nebo blogu depesz.