PostgreSQL: změna dat při logické replikaci

[matrus]

Zdravim, je moznost pri logickej replikacii (PostgreSQL) zmena na replikovanych datach? Napr. ked zdrrojovy stlpec je varchar a potrebujem ho pocas replikacie pretypovat na jsonb? Target stlpec je totizto ineho formatu.

[Reklama]

[modnar]

Normalne neni, protoze logicka replikace replikuje pouze data, ne schema:

https://www.postgresql.org/docs/current/logical-replication-restrictions.html

[Pavel Stěhule]

Zdravim, je moznost pri logickej replikacii (PostgreSQL) zmena na replikovanych datach? Napr. ked zdrrojovy stlpec je varchar a potrebujem ho pocas replikacie pretypovat na jsonb? Target stlpec je totizto ineho formatu.

ano - je to možné, teď jsem to zkoušel. varchar na producentu a json na konzumentu funguje. Neznám replikační protokol, takže vám neřeknu proč - pravděpodobně protože se data předávají jako text. Fungovat by to mělo, je to napsané tak, aby to dokázalo propojit systémy, které data v binárním formátu ukládají jinak.

[modnar]

Zdravim, je moznost pri logickej replikacii (PostgreSQL) zmena na replikovanych datach? Napr. ked zdrrojovy stlpec je varchar a potrebujem ho pocas replikacie pretypovat na jsonb? Target stlpec je totizto ineho formatu.

ano - je to možné, teď jsem to zkoušel. varchar na producentu a json na konzumentu funguje. Neznám replikační protokol, takže vám neřeknu proč - pravděpodobně protože se data předávají jako text. Fungovat by to mělo, je to napsané tak, aby to dokázalo propojit systémy, které data v binárním formátu ukládají jinak.

Jak jsi to pretypoval behem logicke replikace?

[Pavel Stěhule]

Zdravim, je moznost pri logickej replikacii (PostgreSQL) zmena na replikovanych datach? Napr. ked zdrrojovy stlpec je varchar a potrebujem ho pocas replikacie pretypovat na jsonb? Target stlpec je totizto ineho formatu.

ano - je to možné, teď jsem to zkoušel. varchar na producentu a json na konzumentu funguje. Neznám replikační protokol, takže vám neřeknu proč - pravděpodobně protože se data předávají jako text. Fungovat by to mělo, je to napsané tak, aby to dokázalo propojit systémy, které data v binárním formátu ukládají jinak.

Jak jsi to pretypoval behem logicke replikace?

nijak - nikde se nekontroluje jestli jsou stejné datové typy poskytovatele a odběratele. Jen musí sedět názvy sloupců a nesmí havarovat vkládání. Co se dívám, v rychlosti do zdrojáků, tak na straně poskytovatele při insertu se vygeneruje specifická zpráva obsahující textová pole, a zapíše se do transakčního logu. Na straně konzumenta se ta zpráva přečte a jejím základě se zavolá obslužná rutina pro insert. Nevšiml jsem si nějakých konverzí (inicializační copy) může být něco jiného. Ještě jinak - je to jakoby se na straně poskytovatele vygeneroval insert, a ten se poslal ke konzumentu a vykonal. Akorát je to o něco chytřejší - negeneruje to a INSERT ve formátu SQL insertu, ale insert v strukturovaném formátu, takže se nemusí volat SQL parser. Nicméně to co je zatím je zpracování INSERTu. Na jedné straně získáš text, který nemá typ. Na druhé straně vložíš text. A bude to fungovat, pokud ta druhá strana ten text dokáže zpracovat bez chyby.

[Reklama]

[Pavel Stěhule]

Akorát je to o něco chytřejší - negeneruje to a INSERT ve formátu SQL insertu, ale insert v strukturovaném formátu, takže se nemusí volat SQL parser. Nicméně to co je zatím je zpracování INSERTu. Na jedné straně získáš text, který nemá typ. Na druhé straně vložíš text. A bude to fungovat, pokud ta druhá strana ten text dokáže zpracovat bez chyby.

Logická replikace je relativně křehká versus robustní fyzická replikace. Z mnoha různých důvodů tam může dojít ke kolizi (chybě), která replikaci zastaví. Tou kolizí může být i například to, že konzument nedokáže zpracovat přijatá data - třeba vzhledem k jinému typu formátu. U logické replikace je jediná garance, že informace se přenese na konzumenta, ale už tam není garance, že se úspěšně aplikuje. Tuplem, když tam nesedí 1:1 typy. Nicméně, to bych řekl, že je asi záměr. Dá se to použít pro "téměř" bezvýpadkové migrace z dementně navržených db, kde třeba všechny sloupce jsou varchar, do dobře navržených db, kde se používají typy. Cena za tu gumovost je křehkost - přijdou mi tam špatná data, a replikace se mi zastaví.

[matrus]

A je mozne spustit trigger na strane konzumenta pri replikacii dat, kde by sa tieto data upravili BEFORE INSERT?

[Pavel Stěhule]

A je mozne spustit trigger na strane konzumenta pri replikacii dat, kde by sa tieto data upravili BEFORE INSERT?

K tématu jsem našel vlákno

https://www.postgresql.org/message-id/8b6ecb08-136d-48b9-20b4-39d8d758ffac%40postgrespro.ru

případně

https://stackoverflow.com/questions/56671632/postgresql-10-logical-replication-trigger-function-not-executed

[matrus]

Ok, problem ze som sa k spusteniu triggeru nedostal bol ten, ze predtym mi replikacia padla na ERROR:  invalid input syntax for type json. Cize vyzera to tak, ze nie je mozne zmenit format (textovy) vstupu cez trigger, ktory by zmenil vstupne data pred insertom, ale prebieha kontrola este pred triggerom.
Zdrojovy text: Lorem Ipsum, cielovy text: {"en_US": "Lorem Ipsum"}.
Akonahle pretypujem cielovy stlpec na VARCHAR, sync zbehne aj s triggerom.

[Pavel Stěhule]

Ok, problem ze som sa k spusteniu triggeru nedostal bol ten, ze predtym mi replikacia padla na ERROR:  invalid input syntax for type json. Cize vyzera to tak, ze nie je mozne zmenit format (textovy) vstupu cez trigger, ktory by zmenil vstupne data pred insertom, ale prebieha kontrola este pred triggerom.
Zdrojovy text: Lorem Ipsum, cielovy text: {"en_US": "Lorem Ipsum"}.
Akonahle pretypujem cielovy stlpec na VARCHAR, sync zbehne aj s triggerom.

Tohle z triggeru obecně nejde. Trigger se startuje až poté, co jsou vstupní data konvertována do typu. Ve vašem příkladě, můžete kontrolovat obsah jsonu, ale vstup musí být vždy platný json. Buďto si musíte udělat pomocnou tabulku, kterou budete plnit z triggeru nebo by to možná šlo nastavit na úrovni filtru řádek logické replikace a nereplikovat data, která nejsou validním jsonem.

[matrus]

Ok, problem ze som sa k spusteniu triggeru nedostal bol ten, ze predtym mi replikacia padla na ERROR:  invalid input syntax for type json. Cize vyzera to tak, ze nie je mozne zmenit format (textovy) vstupu cez trigger, ktory by zmenil vstupne data pred insertom, ale prebieha kontrola este pred triggerom.
Zdrojovy text: Lorem Ipsum, cielovy text: {"en_US": "Lorem Ipsum"}.
Akonahle pretypujem cielovy stlpec na VARCHAR, sync zbehne aj s triggerom.

Tohle z triggeru obecně nejde. Trigger se startuje až poté, co jsou vstupní data konvertována do typu. Ve vašem příkladě, můžete kontrolovat obsah jsonu, ale vstup musí být vždy platný json. Buďto si musíte udělat pomocnou tabulku, kterou budete plnit z triggeru nebo by to možná šlo nastavit na úrovni filtru řádek logické replikace a nereplikovat data, která nejsou validním jsonem.

Skoda, bola by to super ficura 
Dakujem za pomoc.

[Pavel Stěhule]

Ok, problem ze som sa k spusteniu triggeru nedostal bol ten, ze predtym mi replikacia padla na ERROR:  invalid input syntax for type json. Cize vyzera to tak, ze nie je mozne zmenit format (textovy) vstupu cez trigger, ktory by zmenil vstupne data pred insertom, ale prebieha kontrola este pred triggerom.
Zdrojovy text: Lorem Ipsum, cielovy text: {"en_US": "Lorem Ipsum"}.
Akonahle pretypujem cielovy stlpec na VARCHAR, sync zbehne aj s triggerom.

Tohle z triggeru obecně nejde. Trigger se startuje až poté, co jsou vstupní data konvertována do typu. Ve vašem příkladě, můžete kontrolovat obsah jsonu, ale vstup musí být vždy platný json. Buďto si musíte udělat pomocnou tabulku, kterou budete plnit z triggeru nebo by to možná šlo nastavit na úrovni filtru řádek logické replikace a nereplikovat data, která nejsou validním jsonem.

Skoda, bola by to super ficura 
Dakujem za pomoc.

Nebyla by to super ficura V triggeru nemate opravovat data. Pak by apky byly totalne pojebane, kdyz vidim, co lidi dokazou.

[Death Walker]

Skoda, bola by to super ficura 

Nastastie v postgrese take uchylnosti netreba vymyslat. Mozete pouzit view a definovat mu rules pre non select operacie. Ja osobne to pouzivam skor v pripade ze treba dat do poriadku DB, ale aplikaciu ktora k nej pristupuje a treba ju este nejaky cas udrzat, je nerentabilne upravovat (blackbox alebo spatlanina). Imho, pre vas ucel to bude idealne. Viz https://www.postgresql.org/docs/current/rules.html