🥇„Pro, ale ne cluster“ aneb jak jsme prováděli import substituce databáze

Všechny postavy jsou fiktivní, ochranné známky patří jejich majitelům, jakékoli shody jsou náhodné, a vůbec, to je mé 'subjektivní posouzení, prosím, nelomte dveře…'.

Máme značné zkušenosti s převodem informačních systémů logicky v DB z jednoho DBMS do druhého. V rámci usnesení vlády č. 1236 z 16. 11. 2016 se často jedná o převod z Oracle na Postgresql. Jak uspořádat proces co nejefektivněji a bezbolestně — můžeme popsat samostatně, dnes se zaměříme na zvláštnosti používání clustera a s jakými problémy se lze setkat při budování vysoce zatížených distribuovaných systémů se složitou logikou v procedurách a funkcích.

Spoiler — ano, káp, RAC a pg multimaster jsou velmi odlišná řešení.

Předpokládejme, že jste již převedli veškerou logiku z plsql na pgsql. A vaše regresní testy jsou zcela v pořádku, teď samozřejmě přemýšlíte o škálování, protože zátěžové testy vás moc netěší, zejména na tom hardwaru, který byl původně zakotven v projektu pro ten onen jiný DBMS. Předpokládejme, že jste našli řešení od domácího dodavatele 'Postgres Professional' s možností nazvanou 'multimaster', která je k dispozici pouze v 'maximální' verzi 'Postgres Pro Enterprise' a podle popisu — to velmi připomíná to, co potřebujete, a při prvním povrchním studiu vám přijde na mysl myšlenka: 'O! Místo RAC je to přesně to! A ještě s technickým podporou v domovině!'.

Ale nespěchejte se radovat, a dále popíšeme proč tyto nuance je třeba znát, protože je těžké je předvídat, i když si důkladně přečtete dokumentaci k produktu. Zvažte, zda budete ochotni často aktualizovat verze DBMS přímo na výrobní ploše, protože některé defekty nejsou kompatibilní s průmyslovým provozem a těžko se odhalují během testování.
Začněte pečlivým čtením sekce 'multimaster' — 'omezení' na webových stránkách výrobce.

První, s čím se můžete setkat, jsou zvláštnosti práce transakcí v takzvaném 'dvoufázovém' režimu, a někdy, kromě přepsání celé logiky vaší procedury, to nelze jinak opravit. Tady je jednoduchý příklad:

vytvořit tabulku test1 (id integer, id1 integer);
vložení do test1 hodnoty (1, 1),(1, 2);

ALTER TABLE test1 ADD CONSTRAINT test1_uk UNIQUE (id,id1) DEFERRABLE INITIALLY DEFERRED;

aktualizovat test1
           nastavte id1 =
               případ id1
                 když 1
                 pak 2
                 jinak id1 - sign(2 - 1)
               konec
         kde id1 mezi 1 a 2;

Dochází k chybě:

CHYBA:  [MTM] Transakce MTM-1-2435-10-605783555137701 (10654) byla zrušena na uzlu 3. Zkontrolujte její protokol pro další podrobnosti o chybě.

Můžete se dlouho potýkat s dead lockem ve verzích 10.5, 10.6 a jediné známé řešení, které zabíjí všechnu podstatu clusteru, je odstranit "problémové" tabulky z clusteru, tj. provést make_table_local, ale to alespoň umožní pracovat, a ne postavit "kolmo" vše kvůli vyčkávající stabilizaci transakcí. Anebo aktualizovat na verzi 11.2, která by měla pomoci, ale možná ne, nezapomeňte zkontrolovat.

V některých verzích můžete narazit na ještě záhadnější blokaci:

uživatelské jméno= mtm a backend_type = background worker

A v této situaci vám pomůže pouze aktualizace verze DBMS na 11.2 a vyšší, ale možná to také nepomůže.

Některé operace s indexy mohou vést k chybám, kde je zřetelně uvedeno, že problém je právě v Bi-Directional Replication, v protokolech MTM jasně uvidíte BDR. Opravdu 2ndQuadrant? Ne… my jsme přece koupili multimaster, to je jen náhoda, to je název technologie.

[MTM] bdr nepodporuje revizi indexů
[MTM] 12124: REMOTE začátek zrušení transakce 4083
[MTM] 12124: odeslat ABORT oznámení pro transakci (5467) místní xid=4083 koordinátorovi 3
[MTM] Zpráva o zrušení ABORT_PREPARED pro transakci MTM-3-25030-83-605694076627780 ze uzlu 3
[MTM] Zrušení připravené transakce MTM-3-25030-83-605694076627780 status InProgress z uzlu 3 originId=3
[MTM] MtmLogAbortLogicalMessage uzel=3 transakce=MTM-3-25030-83-605694076627780 lsn=9fff448

Pokud používáte dočasné tabulky, navzdory ujištěním: „Rozšíření multimaster provádí replikaci dat zcela automaticky. Můžete současně provádět zápisové transakce a pracovat s dočasnými tabulkami na jakémkoli uzlu clusteru.“

Pak ve skutečnosti zjistíte, že replikace nefunguje pro všechny tabulky používané v proceduře, pokud je v kódu přítomno vytvoření dočasné tabulky, a dokonce ani použití multimaster.remote_functions nepomůže, budete muset aktualizovat nebo přepsat svou logiku v proceduře. Pokud potřebujete používat současně dvě rozšíření multimaster a pg_pathman v rámci „Postgres Pro Enterprise“ v 10.5, zkontrolujte, že při takovém jednoduchém příkladu:

Vytvořte tabulku measurement (
    city_id         int not null,
    logdate         date not null,
    peaktemp        int,
    unitsales       int
) PARTITION BY RANGE (logdate);

Vytvořte tabulku measurement_y2019m06 jako particiaci tabulky measurement pro hodnoty od ('2019-06-01') do ('2019-07-01');
vložte do measurement hodnoty (1, to_date('27.06.2019', 'dd.mm.yyyy'), 1, 1);
vložte do measurement hodnoty (2, to_date('28.06.2019', 'dd.mm.yyyy'), 1, 1);
vložte do measurement hodnoty (3, to_date('29.06.2019', 'dd.mm.yyyy'), 1, 1);
vložte do measurement hodnoty (4, to_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);

V logách na uzlech databázového systému začínají vycházet takové chyby:

…
 PATHMAN_CONFIG neobsahuje relaci 23245
> find_in_dynamic_libpath: pokus "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: pokus "\/opt\/…\/ent-10\/lib\/pg_pathman.so"
> ODDĚLENÍ:  find_in_dynamic_libpath: pokus "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: pokus "\/opt\/…\/ent-10\/lib\/pg_pathman.so"
> PrepareTransaction(1) název: unnamed; blockState: PREPARE; stav: INPROGR, xid\/subid\/cid: 6919\/1\/40
> StartTransaction(1) název: unnamed; blockState: DEFAULT; stav: INPROGR, xid\/subid\/cid: 0\/1\/0
> přepnuto na časovou osu 1 platnou do 0\/0
…
Transakce MTM-1-13604-7-612438856339841 (6919) je zrušena na uzlu 2. Zkontrolujte jeho log pro detaily chyby.
...
[MTM] 28295: REMOTE begin abort transaction 7017
…
[MTM] 28295: poslat oznámení ABORT pro transakci  (6919) místní xid=7017 koordinátorovi 1

Co tyto chyby znamenají, se můžete dozvědět na technické podpoře, neplatilo by se za ni zbytečně.

Co dělat? Správně! Aktualizujte na „Postgres Pro Enterprise“ na verzi 11.2

Je také důležité vědět, že sekvence, jakožto objekt replikované databáze, nemá celosvětovou hodnotu v celém clusteru, každá sekvence je lokální pro každý uzel a pokud máte pole s unikátními omezeními a používáte sekvenci, můžete pouze udělat inkrement odpovídající číslu uzlu v clusteru, neboť čím více uzlů v clusteru, tím rychleji se vám bude sekvence zvyšovat a int skončí rychleji, než jste očekávali. Pro zjednodušení práce se sekvencí v produktu najdete dokonce funkci alter_sequences, která udělá potřebné inkrementy pro každou sekvenci na všech uzlech, ale buďte připraveni, že funkce nemusí fungovat ve všech verzích. Samozřejmě si ji můžete napsat sami, vycházející z kódu na GitHubu nebo si ji upravit přímo v databázi. Přičemž pole s typem serialbigserial budou fungovat lépe, ale pro jejich použití pravděpodobně budete muset přepisovat kód vašich procedur a funkcí. Možná někomu pomůže funkce monotonic_sequences.

Do verze 11.2 „Postgres Pro Enterprise“ bude replikace fungovat pouze při přítomnosti unikátních primárních klíčů, mějte to na paměti při vývoji.

Rádi bychom zmínili zvláštnosti fungování npgsql právě v klastrovém řešení, tyto problémy se nevyskytují na jednom uzlu, ale v multimasteru se bohužel objevují.
V některých verzích se můžete setkat s chybou:

Podrobnosti o výjimce: Npgsql.PostgresException: 25001: příkaz SET TRANSACTION ISOLATION LEVEL 
Popis: Došlo k neošetřené výjimce během provádění aktuální webové žádosti. Zkontrolujte prosím sledovací zásobník pro další informace o chybě a místě, kde vznikla v kódu.

Co můžete udělat? Je třeba prostě nepoužívat některé verze. Je dobré je znát, protože chyba se neobjevuje v jedné verzi, a dokonce i po jejím prvním opravě se s ní můžete setkat později. Je dobré být na to připraven a pro všechny identifikované chyby databázového systému, které výrobce opravuje, doporučujeme provést samostatné regresní testy. Tak říkajíc, důvěřuj, ale prověřuj.

Pokud aplikace používá npgsql a přepíná mezi uzly, myslí si, že jsou všechny stejné, může se objevit chyba:

VÝJIMKA: Npgsql.PostgresException (0x80004005): XX000: selhání vyhledávání v cache pro typ ...

Taková chyba nastane, protože se provádí mapping

(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");)

kompozitních typů při startu aplikace pro všechna připojení. V důsledku toho obdržíme identifikátor z jednoho uzlu, a při dotazu na jiném uzlu se neshoduje, čímž dojde k chybě, tedy není možné transparentně pracovat s kompozitními typy v klastru pro některé aplikace bez dodatečných úprav na straně aplikace (pokud se vám to podaří).

Jak všichni víme, celková hodnocení stavu klastru jsou velmi důležitá pro diagnostiku a okamžitá opatření při práci. V produktu najdete některé funkce, které by vám měly usnadnit život, ale někdy mohou vydávat zcela něco jiného, než byste čekali, i výrobce.

Například:

select mtm.collect_cluster_info();
na každém uzlu vrací stejný výsledek:
(1,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06")
(2,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06")
(3,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:09")

Ale proč je v poli LiveNodes všude číslo 2, i když podle popisu práce multimasteru by se mělo odpovídat číslu AllNodes=3? Odpověď: Je třeba aktualizovat verzi databáze.

A buďte připraveni shromažďovat logy ze všech uzlů, protože obvykle budete vidět "chyba je v logu jiného uzlu". Technická podpora přijme všechny vámi nalezené defekty a informuje o připravenosti další verze, kterou bude třeba někdy instalovat s přerušením služby, někdy i na delší dobu (závisí na objemu vaší databáze). Není dobré doufat, že problémy s provozem výrazně zatěžují dodavatele, a že aktualizace kvůli zjištěným defektům bude provedena za účasti zástupců dodavatele; spíše nedoporučuji zapojit zástupce dodavatele, protože nakonec můžete získat na produkčním prostředí rozebraný cluster bez zálohy.

V licenci k obchodnímu produktu výrobce upřímně varuje: "Tento software je poskytován na základě principu 'jak je' a společnost s ručením omezeným 'Postgres Professional' nenese žádnou odpovědnost za poskytování podpory, údržby, aktualizací, rozšíření nebo změn."

Pokud jste ještě nepřišli na to, o jaký produkt se jedná, toto vše bylo získáno na základě ročního provozu databáze Postgres Pro Enterprise. Můžete si udělat vlastní závěr, je to tak nezralé, že rostou houby.

Ale to by ještě nebylo tak zlé, kdyby byly problémy odstraňovány včas a operativně.

Ale to se právě neděje. Zřejmě výrobci chybí zdroje na to, aby operativně odstraňovali zjištěné chyby.

Pouze registrovaní uživatelé se mohou účastnit ankety. Přihlaste se, prosím.