Systemd miért

Linux-haladó

Sziasztok,

 

Először a körítés, miért az a kérdés, ami, hátha erre is van valakinek ötlete: SLES-15-ön adott az a feladat, hogy két PostgreSQL-t kell replikálni, aktív-inaktív módon, plusz egy VIP (virtual IP). Fontos, hogy failover esetén nem állhat át kézzel a VIP a secondary node-ra, kézzel át lehet tenni, ennyi idő van.

Ha WAL replikációt használunk, akkor az nem jó, mert a slave node failover esetén readonly állapotban van, és ha vissza kell állni, akkor az nyűg.

A WAL logical replikációnak elég sok korlátja van, ezért azt ki sem próbáltuk.

Mivel ez nem volt jó megoldás, én végül azt javasoltam, hogy legyen DRBD, és egy script, ami megcsinálja az egyes lépéseket (így jutottunk el ide):

  • felhúzza a VIP-et
  • átrakja a DRBD kötetet primary-ra
  • felcsatolja a kötetet
  • elindítja a PG-t

Leállításnál visszafelé ua. Erre kész a két script, működik is, eddig minden ok.

(Ennek a felállásnak az egyik peremfeltétele, hogy a PostgreSQL service le legyen tiltva, hiszen nem indulhat el csak úgy - de semmi gond, letiltottam a PG-t.)

Az a kérés született, hogy induláskor a dedikált primary node-on mindez induljon el - mármint a shell scriptet hívja meg. Összeraktam egy systemd service fájlt, de valami nem ok vele - itt a journalctl kimenete:

aug 09 17:16:21 sles15-1 systemd[1]: Starting PostgreSQL database server...
aug 09 17:16:21 sles15-1 systemd[1]: Started PostgreSQL database server.
aug 09 17:16:21 sles15-1 systemd[1]: Stopping PostgreSQL database server...
aug 09 17:16:21 sles15-1 systemd[1]: Stopped PostgreSQL database server.
aug 09 17:16:21 sles15-1 kernel: XFS (drbd0): Unmounting Filesystem
aug 09 17:16:22 sles15-1 kernel: drbd r0: role( Primary -> Secondary )

Tehát elindul a PG, majd megáll a PG. De nem csak a PG áll meg, hanem lecsatolja a DRBD-t, és átrakja secondary állapotba.

Ha kézzel indítom a systemd service-t, akkor is ue az eredmény.

Ha shell scripttel indítom el a szolgáltatási láncot, akkor minden ok.

Ha systemd-n keresztül indítom, akkor a PG ezt logolja:

2021-08-09 17:16:21.365 CEST   [1829]LOG:  database system was shut down at 2021-08-09 17:15:47 CEST
2021-08-09 17:16:21.384 CEST   [1827]LOG:  database system is ready to accept connections
2021-08-09 17:16:21.499 CEST   [1827]LOG:  received fast shutdown request
2021-08-09 17:16:21.523 CEST   [1827]LOG:  aborting any active transactions
2021-08-09 17:16:21.525 CEST   [1827]LOG:  worker process: logical replication launcher (PID 1835) exited with exit code 1
2021-08-09 17:16:21.525 CEST   [1830]LOG:  shutting down
2021-08-09 17:16:21.737 CEST   [1827]LOG:  database system is shut down

ha a shell scripttel:

2021-08-09 17:22:52.432 CEST   [1977]LOG:  database system was shut down at 2021-08-09 17:22:13 CEST
2021-08-09 17:22:52.459 CEST   [1975]LOG:  database system is ready to accept connections

 

Mit nézek el?

  • 1080 megtekintés

( fsanyee | 2021. 08. 09., h – 17:35 )

Valószinület a service fileoddal van probléma.

Type= -ot nézd meg esetleg.

( Elbandi v | 2021. 08. 09., h – 18:17 )

corosync+pacemaker, csomo leiras van hogy kell vip+drbd+mount+service inditast csinalni

ne akarj olyan toollal megoldani valamit ami nem arra valo

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

corosync+pacemaker, csomo leiras van hogy kell vip+drbd+mount+service inditast csinalni

Köszi, nem kell leírás, eleget csináltam ilyet szerintem (bár nyilván mindig jó, ha van valami vezető). A megrendelő egyik kiemelt kérése volt:

Fontos, hogy failover esetén nem állhat át kézzel a VIP a secondary node-ra, ...

Ezzel nem tudok mit csinálni, ez van.

ne akarj olyan toollal megoldani valamit ami nem arra valo

A pacemaker-corosync arra való, hogy ha failover van, akkor ő kezeli azt, és átállítja. Itt meg pont az a lényeg, hogy ne álljon át, az operátor eldönti, hogy át kell-e állni, vagy sem.

 

(Vagy te arra gondolsz, hogy csináljam meg corosync-el, és tiltsam le az erőforrások automatikus átmozgatását? Itt van még más kitétel is, pl normál induláskor mindig az elsődlegesnek dedikált gépen kell elindulnia mindennek, és a hiba megszűnésekor nem állhat vissza semmi. De így meg semmi értelme a corosync/pacemaker párosnak. Szerintem.)

corosync megadsz egy default priorityt, hogy melyik az elsodleges node. amikor meg move-olod a vipet (o majd tudja hogy milyen sorrendben kell csinalni), akkor beallit egy magasabb priorityt a masik node-ra, igy ott fog elindulni aminek el kell.

bar eleve ezt a "failover esetén nem állhat át kézzel a VIP a secondary node" mondatot nem ertem... az milyen HA failover amihez user beavatkozas kell?

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

az milyen HA failover amihez user beavatkozas kell?

Pont ez a kihívás :).

Így döntöttek, ez van, le van írva a specbe, hogy nem lehet automatikus átállás. Így nem is kell HA failover-nek hívni :).

 

Ill még annyi korrekció, hogy

"failover esetén nem állhat át kézzel a VIP a secondary node"

nem csak a VIP nem állhat át, hanem a DB sem (és az aktív DRBD node sem).

Köszi, ez eddig a legjobb tipp :).

Sajnos a vas már rég adott, nem lesz más.

Mindegy, megoldottam tisztán systemd-n keresztül, még az IP címeket sem kell bevarrni, pár sorral kellett csak kiegészíteni a PG sysconfig fájlt (ez hosztonként lehet más), ez meg így jó lesz.

Leírod mi lett a megoldás? Szeretnék tanulni belőle és a systemd okoz sokaknak fejfájást. Köszönöm.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Hogy az általam először megírt (saját) systemd service-el mi volt a gond, arra nem jöttem rá.

A postgresql service fájlba néhány jól irányzott ExecStartPre, ExecStopPost és After beállítással simán azt kaptam, amit szerettem volna. Kb így néz ki a diff az eredeti Postgesql service-hez képest:

# diff postgresql.service.BAK /usr/lib/systemd/system/postgresql.service
5a6,7
> After=dev-drbd0.device
> After=drbd.service
13a16,21
> ExecStartPre=+/sbin/ip address add ${VIP} dev ${NETDEV}
> ExecStartPre=+/sbin/drbdadm primary ${RES}
> ExecStartPre=+/usr/bin/mount ${DRBDDEV} /var/lib/pgsql/data
> ExecStopPost=+/sbin/ip address delete ${VIP} dev ${NETDEV}
> ExecStopPost=+/usr/bin/umount /var/lib/pgsql/data
> ExecStopPost=+/sbin/drbdadm secondary ${RES}

ill. a /etc/sysconfig/postgresql-be felvettem a környezeti változókat (VIP, NETDEV, RES, DRBDDEV), így maga a service fájl ua lehet minden gépen (3 ilyen környezet van), a többi változtatható gépenként.

Ezt: https://www.freedesktop.org/software/systemd/man/systemd.unit.html érdemes elolvasni (nyugodtan haladj rá az examples részre, ott van értelmes magyarázat), mert általában jól ki lehet találni, hogy hogyan kell fileok elhelyezésével overrideolni anélkül, hogy barbár módon beleírnál az /usr/lib/systemd alatti részbe.

Tippre, ha jól látom neked igazából kell egy service specifikus conf.d ( /etc/systemd/system/postgresql.service.d/) ahova mehet egyrészt egy valami override.conf a fenti diffel, egy másikba, pl local.conf meg a konkrét host spec környezeti változók. (Szokás az /etc/sysconfig-ot nem kedvelni, ha systemdt használsz, de ez eléggé ízlés kérdése)

Uh, köszi, ez nagyon hasznos, megnézem, és még faragok rajta kicsit.

Szokás az /etc/sysconfig-ot nem kedvelni, ha systemdt használsz, de ez eléggé ízlés kérdése)

Nekem mindegy, ki milyen néven használja :), a SuSE speciel így - mármint a "gyári" service fájlban is így van:

[Service]
Type=forking
User=postgres
EnvironmentFile=-/etc/sysconfig/postgresql

De köszi még egyszer!

( kroozo v | 2021. 08. 10., k – 13:56 )

Mit nézek el?

Hát, a konkrét script és a konkrét unit file lehet, hogy segítene :) 

( zeller | 2021. 08. 10., k – 22:33 )

"Ha WAL replikációt használunk, akkor az nem jó, mert a slave node failover esetén readonly állapotban van, és ha vissza kell állni, akkor az nyűg." - Pedig jó az... Átbillenés esetén ahova billensz, ott át kell lökni masterbe, ahonnan billensz, oda -amikor életet leheltél a gépbe- tolsz egy basebackup-ot, és beállítod, hogy a másik gépről húzza a wal-okat, és ő lesz readonly. Az EFM pont ezt csinálja :-P

Átbillenés esetén ahova billensz, ott át kell lökni masterbe, ahonnan billensz, oda -amikor életet leheltél a gépbe- tolsz egy basebackup-ot, és beállítod, hogy a másik gépről húzza a wal-okat, és ő lesz readonly.

Ez az, ami végül nem volt jó a megrendelőnek. A mostani megoldás viszont teljesen jó.

Az EFM pont ezt csinálja :-P

Nem tudom, mi az az EFM :)

Az Enterprise Failover Mnager az pont ezt csinálja: Ha a master node rotty, akkor a(z elsődleges) slave-re automatikusan átbillen, HA-címmel, tok-vonó, illetve fencing-gel az eredeti master-t ki is gyilkolja (Illendően ILO vagy más management interfészen keresztül elvéve tőle a tápot). Eztán ha az eredeti master-t vissza akarkuk tenni mondjuk slave-ként (első körben azt lehet), akkor egy teljes DB-másolás kell (mondjuk basebackup), majd slave-ként elindítani, felszedi a wal-okat, és amikor szinkronban vannak, akkor lehet visszabillenteni, ha szükséges (és lehet a 2. node-ot visszaépíteni...)

Hogy lehet-e teljes visszamásolás nélkül visszaléptetni node-ot a fürtbe slave ként, az jó kérdés - elvileg (ha jól gondolom) amennyiben a masteren még ott van a visszaléptetni kívánt node által még fel nem dolgozott valamennyi wal fájl, akkor lehet, de amennyi ideig a nagyobbacska szerverek bootolnak, hát... Fene tudja, na.

Kluka kolléga is említette, hogy ezt nyugodtan megcsinálhatja a service layer is, akár tranzakcióban.

De akkor hadd kérdezzek vissza?

  • Mit könnyebb debuggolni, skálázni, trace-elni, a tárolt eljárást vagy a service kódját?
  • Metrikák, log üzenetek, tracing információk hogy jönnek ki tárolt elrájásból?
  • Hogyan teszteled a tárolt eljárást? Gondolom, nem unit tesztekkel :-) Mit, hogyan mockolsz?

Ezek nem megoldhatatlan dolgok, de én személy szerint szívesebben implementálom mindezt C#-ban, mint T-SQL-ben vagy akármi más ilyesmi nyelvben.

SQL prompt? Az a user interface? :-D

A service layer az egy identitással megy be a DB-be, aminek mondjuk a táblák x hammazára van írási joga, de a logtáblára direktben nincs, mert azt maximum olvasnia kell tudni. Hogy oldod meg mégis azt, hogy naplózzon?

Egy tárolteljárás tud logolni táblába, tud kivételt dobni, tud egy rakat olyan dolgot, amit lehet használni a működésének a követésére. Egy tárolt eljárást ugyanúgy lehet tesztelni, mint minden más kódot: valid és nem valid bemenetre hogyan viselkedik. Nem űrtechnológia...

"SQL prompt? Az a user interface? :-D" Ha a DB-hez közvetlenül, az alkalmazást megkerülve hozzá tudsz férni (mert az alkalmazásból kinyerhető az user/pw, vagy mert az AD-s usered az, ami azonosít a DB felé, akkor ki tudsz adni oylan sql utasítást, hogy update logolando_tabla set naplozando_mezo=123 where naplozando_mezo=234;
És ez nem fog megjelenni a naplóban megfelelő trigger nélkül. Miközben kötelező lenne naplóba írni minden változást...

De miért logolnál egy OLTP adatbázisba? 1980-at írunk?

Természetesen, tákolni mindig lehet.

Ha a DB-hez közvetlenül, az alkalmazást megkerülve hozzá tudsz férni

Atyaég, ez nálatok így működik? Mármint ezt komolyan így tervezte meg valaki?

Írd már meg, lécci, hol dolgozol, nehogy véletlenül oda interjúzzak.

Kicsit el kellene felejteni ezt a logot most (ezzel együtt leszállni arról a lóról), és megpróbálni megérteni a másikat.

Senki nem mondta, hogy mindent triggerrel kell megoldani, ez egy lehetőség.

Pl. én is használom rekordok archíválására, ahol fontos, hogy vissza lehessen követni, mi mikor változott.

Csak triggerek meg tárolt eljárások nincsenek benne - azaz mindent is az alkalmazásnak kell csinálnia, olyasmit is, amit értelmes ember a DB-ben (okos adatszerkezet - buta kód elv) csinál meg.

Megértem a kollégát, csak nem értek egyet. Szerintem egy értelmes ember az adatbzisban adatokat tárol, és nem üzleti logikát implementál benne.

amit értelmes ember a DB-ben

Mondanám, hogy értelmes ember az ilyeneken átlép, de elég paradox lenne... :)

adatbzisban adatokat tárol, és nem üzleti logikát implementál benne.

Nyilván, de azt, hogy mi az adat, eldöntheti mindenki maga, ugye? :)

És ha mégis van egy adatbázisod, amihez lehet alkalmazáson kívül is kapcsolódni (mondjuk valami tervezési hiba miatt, de lehet security incidens is), akkor nem baj, ha konzisztens marad a kitalált struktúra?

"amihez lehet alkalmazáson kívül is kapcsolódni" - mondj nekem olyan RDBMS-t, amihez nem lehet sql parancsok kiadására közvetlenül alkalmas eszközből kapcsolódni :-)

A konzisztencia a másik fontos tényező, amire -ahogy itt is látszik- az alkalmazásfejlesztő azt mondja, hogy "megoldom egy tranzakcióban aztán kész" - mert az alkalmazásától nem lát messzebbre.

A tranzakció az egyik konzisztens állapotból visz át egy másik konzisztens állapotba, nemde?

Mi olyat tud a tárolt eljárás, vagy egy trigger, amit én ne tudnék kezdeményezni az alkalmazásomból?

Tényleg érdekel. Lehet, hogy ma újat tanulok.

(Jó, OK, adhatok jogot a tákolt eljárás futtatására, miközben a táblák közvetlen írására nem. Ez eddig egy.)

A tranzakció az egyik konzisztens állapotból visz át egy másik konzisztens állapotba, nemde?

Mi olyat tud a tárolt eljárás, vagy egy trigger, amit én ne tudnék kezdeményezni az alkalmazásomból?

Garantálja, hogy az alkalmazásodon kívül is konzisztens állapotban marad a DB-d.

Keress rá a tranzakció izolációs szintekre. Ma már minden DB MVCC-t használ (nincs szoros összefüggésben az isolation levellel, inkább egy technikai megvalósítása), mármint az értelmesebbje.

https://docs.microsoft.com/en-us/sql/odbc/reference/develop-app/transac…

https://en.wikipedia.org/wiki/Isolation_(database_systems)

De én annak idején a Postgres manuáljából értettem meg. Kellett egy hét.

https://www.postgresql.org/docs/current/transaction-iso.html

Bocsánat a kérdésért, de mit értesz DB-n belüli izoláción? Nincs DB-n belüli és kívüli izoláció. A tranzakciók futnak izoláltan, a tranzakciókat pedig kliensek hozzák létre, akár kódból, akár tárolt eljárásból.

Igen, értem, mit akarnak megoldani. Olyan dolgot, amit máshogy, kényelmesebben, átláthatóbban, háttérben történő mágiák alkalmazása nélkül is meg lehet oldani pontosan ugyanolyan helyesen.

Messziről kell indulni, úgy látom... Egy adott folyamat során az A és B táblát kell együtt módosítani úgy, hogy az A táblába írt adat alapján kerüljön a B módosításra.
Te ezt alkalmazásban szépen megcsinálod begin transaction; insert ... A ; update B ; end transaction módon, ezzel az alkalmazásod felől rendben van a konzisztencia.
Én fogom magam, és becsattanok sql-ből, és azt mondom, hogy insert ... A; commit; És máris telibe van rosálva az üzleti logika szerinti konzisztencia - egyszerűen azért, mert az A táblán nincs ott az a trigger, ami a változása esetén a B-be betolja az update-et.

Amire a megoldás a tranzaction isolation level. A második "insert A"

  1. szépen vár, amíg az én tranzakcióm be nem fejeződik (pesszimista konkurenciakezelés),
  2. az én tranzakcióm pukkan el és rollback (optimista tranzakciókezelés).

Látod, én még választhatok is, hogy optimista (SNAPSHOT) vagy pesszimista (pl. SERIALIZABLE) tranzakciókezelést szeretnék. A triggereddel mindenképpen pesszimista lesz (innen már nem nehéz elképzelni egy dead-lockot sem). 

Szerintem nem erre gondol, megpróbálok gondolatolvasni. :)

Normál esetben (egyszerűsített példa lesz, a valóságban nem így csinálnám, bear with me) mondjuk egy tranzakció úgy néz ki, hogy a KÉSZLET táblán update-eled a terméket, a MEGRENDELÉSEK-en pedig beszúrsz egy sort, majd commit. Ez eddig fasza. Most jön zeller, aki szeretné kilopni a raktárból az új iPhone-t, ezért csökkenti a készletet eggyel. DB szempontból ez a tranzakció is teljesen valid.

Zeller főnöke viszont azt szeretné, hogy egy tranzakció ne csak a DBA szempontjából legyen értelmes, hanem üzletileg is, tehát ne lehessen lopni a raktárból. Így a KÉSZLET táblára mindenkitől elveszi a write jogot, és a MEGRENDELÉSEK tábla módosításakor egy trigger hozzáigazítja a készletet a valós termékmozgásokhoz.

De attól még valaki megfoghatja az iPhone-t, és elviheti. Szóval üzleti szempontból így sem véd a trigger, hónap végén ugyanúgy hiányozni fog egy termék.

Műszaki szempontból kellene pontosan egy service (amit lehet skálázni, ha kell), ami a rendelésekért felel, minden más service ezt a service-t használja (autentikáció után), ha rendelni akar vagy a készletet akarja lekérdezni. Nem kell ennek REST-nek lennie, van 100 más megoldás is, pl. gRPC.

A DB-hez alapvetőeb nem kell írási jog senkinek, max. annak a pár embernek, akik az adatok archiválásáért, managementjéért felelősek, és persze a service-nek.

De amúgy igen, ha valaki inkább keresgéli hajnal kettőkor a kitudja hány soros tárolt eljárásait, esetleg verziókezelőbe be sem checkolt triggereit, hát jó, nekem végülis mindegy.

Szóval üzleti szempontból így sem véd a trigger, hónap végén ugyanúgy hiányozni fog egy termék.

Viszont leltárnál kiderül, és le lehet tiltani. De ne az iPhone-on lovagoljunk, mondtam, hogy ez egy egyszerá példa lesz. :)

De amúgy igen, ha valaki inkább keresgéli hajnal kettőkor a kitudja hány soros tárolt eljárásait, esetleg verziókezelőbe be sem checkolt triggereit, hát jó, nekem végülis mindegy.

Jó, hát legalább megtanulja, hogy legközelebb csekkolja be ezeket is. :)

"esetleg verziókezelőbe be sem checkolt triggereit" - nomostan értelmes DB fejlesztő Flyway, Liquibase vagy hasonlók nélkül nem dolgozik - ugyanis a DB-be kerülő kód, a futtatandó DDL vagy épp DML kód normális helyen verziózva van, és a betöltésüket is nyomon követi a megfelelő eszköz. Szóval de, a trigger, tárolt eljárás, sémageneráló/módosító scriptek is verziózva vannak jobb helyen. Rosszabb helyen meg dBase-szinten használják a DB-t, aztán csodálkoznak, ha üzleti logika szerint inkonzisztens lesz itt-ott...

Ennyire szerintem nem fekete-fehér a dolog. :)

Szerintem bőven van olyan logika, aminek a DB-ben a helye - tipikusan ami a tárolt adatokhoz szorosan kapcsolódik, pl. access controlt valósít meg, vagy éppen performance oldalról nem érné meg áthúzni az app layerbe, onnan vissza, stb.

"De miért logolnál egy OLTP adatbázisba?" - mert mondjuk előírás a változások idősoros tárolása? Én jobban szeretem azt mondani a DB-nek, hogy rakja el ezt és ezt az adatot - aztán hogy abból még lesz 3 táblában 4 insert, kettőben meg öt update, az nem érdekel - amikor mindegyik kész, akkor visszajön a meghívott eljárás, hogy készen van. És ha 1234 kölönböző alkalamzás fogja azokat az adatokat bepakolni a DB-be, akkor az az 1234 különböző alkalmazás is ugyanazt a rakd_el_ezt_légyszives() eljárást fogja felparaméterezve meghívni, totál függetlenül attól, hogy milyen nyelven, ki fejleszti. Egységesen, és garantáltan ugyanúgy fog működni minden irányból, míg ha mindenki saját magának írná meg sql-ben (öt tábla, 4 insert meg öt update), akkor vagy egyformán működnének, vagy sem.

Nekem ez a "több[féle] alkalmazás is ugyanazt a DB-t használja" mindig azt jelenti, hogy valahol leakel az absztrakció, sérül a single responsibility principle. Mert amúgy pontosan ugyanezt egy tranzakcióban is meg lehet oldani a repository layerben úgy, hogy a biznisz domain még csak nem is kell, hogy ismerje az extra lépéseket.

Cserébe megmarad minden, amit a XXI. században elvárunk: könnyű debuggolhatóság, logok aggregálva, tracing, metrikák, skálázhatóság, rendes tesztelés (igen, rendszeresen futtatott automata tesztekkel, mockokkal).

Tippelek, hogy te még nem láttál nagyobb/komolyabb DB-t, illetve ilyenre épített alkalmazásokat... A többféle app használja ugyanazt a DB-t kérdésre mondjuk egy banki rendszert hozok példaként: használja a fióki frontend, mondjuk legacy vastagkliensből, használja a netbank/mobilbank Java-ból, használja az adattárház kiöntés egy harmadik alkalmazásból, jelentéskészítő cucc mondjuk .NET-es csodából, átutalási rendszerek megint csak valami másból (többen, többféle módon), kártyarendszer, monitoring... satöbbi.

"egy tranzakcióban is meg lehet oldani a repository layerben" - csak az a gond, hogy az üzleti logika szerinti konzisztenciát mindenütt meg kell valósítanod, valamennyi alkalmazásban, valamennyi, a DB-be írási joggal rendelkező irányból - ahelyett, hogy maga az adatszerkezet lenne olyan okos, hogy ezt megoldja - mondjuk triggerrel, mondjuk néhány jól irányzott tárolt eljárással...

Bár ne láttam volna. Az 5 év fintech nem múlt el nyomtalanul. Mondjuk tanulni abból is lehet, ha mást nem, az antipatterneket. De nem leszek igazságtalan, pontosan ugyanitt láttam meg a másik oldalt is.

"egy tranzakcióban is meg lehet oldani a repository layerben", igen, írni kell egy pár service-t, mint absztrakciós réteget, amit aztán lehet tutujgatni, és nem a DB-t kell bántani.

"nem a DB-t kell bántani" A "nem kell" és a "nem lehet" közötti árnyalatnyi különbség az ugye megvan...?  Az, hogy neked mágia meg fölöslegesnek tűnő dolog az, hogy a DB _önmaga_ képes (lehet) üzleti logika szerint konzisztens lenni, az egy dolog, de attól még kifejezetten hasznos és jól alkalmazható tudása a normális RDBMS-eknek. (Ilyen alapon egyébként a constraint-ek is fölöslegesek, nem? Alkalmazásból meg tudod nézni, hogy létezik e az adott érték a másik táblában, aztán jónapot...)

Valszeg én nem értek valamit, de egy triggert hogy kellene replikálni?

Pont az a lényege, hogy van egy DML (aminek az eredménye megjelenik a másik/többi node-on is), ami elindítja a trigger futását, ami további DML-eket futtat, melyeknek az eredményei szintén megjelenik a többi node-on. Nem a trigger futását kell replikálni, hanem a DML-eket...

Vagy ahogy írtam, nem értem a felvetést. :P