postgres cluster primary-primary

Linux-haladó

nem vagyok egy nagy DB guru, a cel az lenne, hogy valami modon egy posgtres DB-be tobb node-on is tudjunk beleirni. (ne master-slave legyen, ahol csak a master irhato)

Azaz lenyegeben a primary-primary megoldas kellene.

van ilyen? Architekturalisan mi az ajanlott itt?

 

Olvasni mindenfelet, pl:

https://www.crunchydata.com/blog/a-guide-to-building-an-active-active-p…

 

de nekem egy jol mukodo, tesztelt cucc lenne jo...amit mar hasznaltok hosszu ideje...

  • 1560 megtekintés

Igen, bar a vendor adja nem mi magunk konfigoljuk. Cloud provider postgresql magoldasa. Eddig nem volt vele semmi baj. De hasznaljuk kubernetes alatt teszt rendszerben is mindenes backendkent.

De van ahol sima sync-et hasznalunk adatbazis szinten locigal replicarion-nel (publisher/subscriber). De ezt egy masik projekt masik teamje csinalja szoval reszleteket nem tudok, egyszer voltam egy troubleshoot call-ba behivva, es ultem mint a hulye :d

( osod88 v | 2023. 12. 15., p – 20:58 )

Subscribe. A kérdésre ugyan nem válasz meg nem értek hozzá különösebben, de érdekel mik az opciók Postgressel.

Galera clustereket használok MariaDB-vel, mind minimum 3 node. Mindegyik node írható, folytonos a replikáció köztük.

Az alkalmazás a háromból kettőhöz fér hozzá, ha az egyik nem válaszol, failoverel a másikra. Szerintem a két node az problémás lehet ha megáll köztük a szinkronizáció valamiért.

"Everything fails, all the time."

Így néz ki a konfiguráció. Ne vedd készpénznek mert nem vagyok DB guru, ha jól tudom a wsrep csinálja a táblák / sorok folytonos replikációját rsync-et használva.

A wsrep opciókról itt található leírás, az architektúráról pedig itt

Node 1: (10.0.23.4)

ubuntu@db01:~$ cat /etc/mysql/conf.d/galera.cnf
[mysqld]
sync_binlog = 0
binlog_format = ROW
default_storage_engine = InnoDB
transaction-isolation = READ-COMMITTED
innodb_autoinc_lock_mode = 2
innodb_doublewrite = 1
innodb_flush_log_at_trx_commit = 0
innodb_stats_on_metadata = 0
query_cache_limit = 8M
query_cache_size = 0
query_cache_type = 0
bind-address = 0.0.0.0

# galera settings
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = galera_cluster
wsrep_cluster_address = gcomm://10.0.23.4,10.0.23.36,10.0.23.68
wsrep_sst_method = rsync
wsrep_node_name = dbnode1
wsrep_sst_donor = dbnode3,

Node 2 (10.0.23.36)

ubuntu@db02:~$ cat /etc/mysql/conf.d/galera.cnf
[mysqld]
sync_binlog = 0
binlog_format = ROW
default_storage_engine = InnoDB
transaction-isolation = READ-COMMITTED
innodb_autoinc_lock_mode = 2
innodb_doublewrite = 1
innodb_flush_log_at_trx_commit = 0
innodb_stats_on_metadata = 0
query_cache_limit = 8M
query_cache_size = 0
query_cache_type = 0
bind-address = 0.0.0.0

# galera settings
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = galera_cluster
wsrep_cluster_address = gcomm://10.0.23.4,10.0.23.36,10.0.23.68
wsrep_sst_method = rsync
wsrep_node_name = dbnode2
wsrep_sst_donor = dbnode3,

Node 3: (10.0.23.68)

ubuntu@db03:~$ cat /etc/mysql/conf.d/galera.cnf
[mysqld]
sync_binlog = 0
binlog_format = ROW
default_storage_engine = InnoDB
transaction-isolation = READ-COMMITTED
innodb_autoinc_lock_mode = 2
innodb_doublewrite = 1
innodb_flush_log_at_trx_commit = 0
innodb_stats_on_metadata = 0
query_cache_limit = 8M
query_cache_size = 0
query_cache_type = 0
bind-address = 0.0.0.0

# galera settings
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = galera_cluster
wsrep_cluster_address = gcomm://10.0.23.4,10.0.23.36,10.0.23.68
wsrep_sst_method = rsync
wsrep_node_name = dbnode3
wsrep_sst_donor = dbnode2,dbnode1,

"Everything fails, all the time."

https://galeracluster.com/products/

"

Galera Replication

  • Galera replication happens at transaction commit time, by broadcasting transaction write set to the cluster for applying

"

"However in practice synchronous database replication was traditionally implemented via the so-called “2-phase commit” or distributed locking which proved to be very slow. Low performance and complexity of implementation of synchronous replication led to a situation where asynchronous replication remains the dominant means for database performance scalability and availability. Widely adopted open-source databases such as MySQL or PostgreSQL offer only asynchronous replication solution."

neked aztan fura humorod van...

( dotnetlinux | 2023. 12. 15., p – 21:17 )

Szerkesztve: 2023. 12. 15., p – 21:17

Mennyire sajat host kell? Aws managed nem jatszik? 

( iwanabeguru | 2023. 12. 15., p – 21:23 )

Ez szerintem az elméletileg lehetetlen kategória. Egyszerűen nem tudod biztosítani az ACID működést ha 2 master node van.

Elosztott rendszerekben és elosztott adatbázisoknál fejlődött ki a CAP teória. Consistency, Availability, Performance. Tipikusan a 3ból kettőt választhatsz, de inkább egy százalékos elosztást képzelj el. Ilyen rendszerekben csak kompromisszumok vannak. El kell dönteni mi a fontosabb.

2 "master" node + load balancer + valamilyen szinkronizáló (akár valami batch job) = high performance, high availability, de vacak consistency

1 master node + n replica = szuper consistency, high availabilty, de kevesebb performance.

 

Néztem a linket amit belinkeltél és az is valami extra servicet húz a postgres nodeok fölé ami megoldja a szinkronizációt.

// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

> Ez szerintem az elméletileg lehetetlen kategória.

Mi a lehetetlen pontosan? Léteznek elosztott adatbázisok, amik tudnak ACID tranzakciókat.

> Elosztott rendszerekben és elosztott adatbázisoknál fejlődött ki a CAP teória. Consistency, Availability, Performance.

Nem ezt jelenti. Ezt javaslom olvasni: https://cloud.google.com/blog/products/databases/inside-cloud-spanner-a…

( bazso | 2023. 12. 16., szo – 07:39 )

Kíváncsi vagyok, van e már megoldás.

A fentebb említett CAP illetve sync/async korlátok és kompromisszumok miatt arra számítok, hogy általános esetekre maradt a régi nóta: míg az olvasást könnyű lineárisan skálázni, az írás nem lesz gyorsabb, mintha csak egyetlen node írna, sőt, azt is nehéz elérni, hogy ne legyen lassabb. 

Persze lehetnek speciális esetek, amikor előre tudod a tranzakciók felépítését, és akkor sharding alapon felosztják ki milyen adat master-e (egyik csak a páros, másik csak a páratlan számokat írhatja, utána replikálja az állapotot), így nem lépnek egymás lábára. De ha komplex (valós , általános) esetben le kell kommunikálni, ráadásul kivárni a lock-ot, az nem lesz gyors

( NevemTeve | 2023. 12. 16., szo – 07:40 )

Ha maga a termék gyártója ajánl ilyen kétlábas (avagy clusteres) működést, akkor a dolog lehetséges, de sok problémád lesz vele. Ha külső fél megoldását használnád, akkor csak a második rész biztos: sok problémád lesz vele.

( profeta | 2023. 12. 16., szo – 19:59 )

Szerkesztve: 2023. 12. 16., szo – 20:00

Amit keresel azt úgy hívják hogy oracle rac. Az a gond a master-master működéssel, hogy eloszott cache és lock adatbázis kell hozzá, valamint megosztott tároló. Ami megoldásokat én láttam, azoknak közük nem volt az ACID tranzakciókezeléshez, még read committed szinten se. Az már nem adatbázis, hanem csak valami elosztott tároló. Gyönyörű kifejezést is alkottak rá, ez az eventually consistent. Kb. ugyanaz mint a szűzk@rva

( n.balazs v | 2023. 12. 16., szo – 21:21 )

Megkérdezem, hogy mi az a megoldandó probléma, amihez a megoldást a Postgresql multimaster megoldásától várod? Ha nem túl nagy titok.
Mert lehet, hogy megold 1 problémát, de behoz másik 10-t.

( profeta | 2023. 12. 17., v – 14:21 )

Egyébként postgresnél beállíthatod úgy a replikációt, hogy szinkron legyen, azaz addig nem igazolja vissza a commit-ot, amíg a replika is át nem vette. Így gyorsan és biztonsággal lehet mastert cserélni, és nyugodtan olvashatsz a replikából is, bár arra nem esküszöm meg, hogy mindig ugyanazt az eredmény kapod. Persze kicsit lassab lesz.

Ha írásra akarsz skálázódást, akkor oda inkább valami shared nothing architektúrájú nosql lesz a jó. A konzisztencia nem érdekes akkor, ha úgyis csak insert van, és nem számít, hogy olvasáskor nem látod rögtön az összes kiírt rekordot.

Van még egy mysql származék a TiDB, emlékeim szerint abban volt valami okosság, de nincs vele tapasztalatom.

( kisg v | 2023. 12. 18., h – 09:22 )

Ha Postgres wire kompatibilitás kell, akkor a Yugabytedb-t és a Cockroachdb-t is érdemes megnézni. Ettől függetlenül, ahogy már írták, az alkalmazást fel kell készíteni arra, hogy elosztott DB-n dolgozik.

Ahogy nézem, mindkét opciónak vannak korlátai a natív PG-hez képest, úgyhogy alaposan átgondolandó/tesztelendő egy ilyen elosztott DB-re történő átállás. (A CockroachDB esetében a triggerek hiánya nagyon sok esetben igencsak fájhat, és akár olyan is lehet, ahol ez kizáró ok(!) (pl. változások  kötelező, alkalmazástól, módosítás "forrásától" független naplózása...))

( gelei v | 2023. 12. 18., h – 12:28 )

Szerkesztve: 2023. 12. 18., h – 12:28

a cel az lenne, hogy valami modon egy posgtres DB-be tobb node-on is tudjunk beleirni

A cel biztosan nem ez, ez legfeljebb egy potencialis megoldasa egy feladatnak.

Szoval mi is a feladat pontosan? :)

( gabrielakos v | 2023. 12. 19., k – 08:17 )

"Architekturálisan mi ajánlott?"

A CAP theorem tanulmányozása először: https://en.wikipedia.org/wiki/CAP_theorem

Aztán a CAP vs ACID tanulmányozása, majd az "eventually consistent" fogalommal való megbarátkozás. És azzal, hogy az alkalmazás jelentős átalakítása nélkül a feladat elméletileg sem oldható meg helyesen.

Vaaagy az egésznek az elengedése és maradni a master-replica setupnál, már ha korrekt, kiszámíthatóan működő megoldást akarsz.

Job security szempontból persze jobb lehet egy időnként "megmagyarázhatatlan" dolgokat produkáló rendszerben hibákat kergetni vég nélkül, sárral betömködni a lyukakat, teóriákat és magyarázatokat gyártani mindenre. 

Cinikus? Az. Okkal? Bizony.

zászló, zászló, szív

Én kb. reggeltől estig elosztott adatbázisokkal dolgozok. Létezik olyan jó adatbázis motor, ahol minimális kompromisszummal és átalakítással lehet ilyet használni. (Még full konzisztens módban is, csak az kicsit lassabb.) Viszont azt lesújtónak tartom (a fenti kommentek alapján) hogy ettől a FOSS és dobozos termékek milyen messze állnak még.

Gyakorlatilag ezt: https://cloud.google.com/spanner . Most látom, hogy van PostgreSQL interfésze, szóval a kérdezőnek is jó lehet. ACID, alig van kompromisszum a CAP miatt, és tényleg veszettül skálázódik. Földrajzilag replikált, egy adott helyszínen pedig clusterként skálázódik automatikusan (pl. egy-egy szerver bizonyos táblák vagy sorok egy adott halmazáért felelős). Valahol hallottam, hogy a CockroachDB is hasonló elvek szerint épült fel.

Mivel mi viszonylag lassabb (100-1000ms) tranzakciókat futtatunk, ezért optimistic concurrency controlt építettünk köré, de pessimistic locking módot is tud. Mindkét esetben garantált, hogy ha írunk, akkor az abban a tranzakcióban olvasott adatok konzisztensek és más nem vágta felül. Okosan kell kezelni azt, hogy ha transaction conflict hibát kapunk, milyen szinten próbáljuk újra. Olvasás esetén lehet választani, hogy nagyon friss adat kell, ami lassabb, vagy kicsit régebbi is jó, ami gyorsabban elérhető (ez utóbbi az eventual consistency), illetve timestamp-ek kezelésével read-after-write consistency is elérhető. Külön öröm, hogy lehet adott időpontbeli állapotot olvasni, mert minden adat verziózott. Ezek egy része sok embernek szokatlan, de a valóságban mindig kiderül, hogy némi kompromisszum belefér a követelményekbe, cserébe még gyorsabb lesz. De mindez opcionális, lehet ilyen dolgok nélkül is buta adatbázisként használni, csak akkor kicsit lassabb és néha fog furcsa hibákat produkálni.

Sajnos a fejlesztők nagy részének, főleg a tranzakciókezelt adatbázisokon felnőtt többségnek a hozzászólásod vsz kínai, nem leszólva őket, mert amíg nincs konkrét probléma ami miatt ki kell jönni a komfortzónából, az ritka (rdbms jó nagy vason szinte mindent tud, a többi akkor jön amikor beüt az a szinte...). Egy ilyen típusú működéshez nagyon át kell állni fejben. Már az eventual consistency zárlatot okoz azzal, hogy nem lehetsz benne biztos, hogy az imént beírt adatot kapod e vissza vagy annak valamely múltbeli állapotát.

Már az eventual consistency zárlatot okoz azzal, hogy nem lehetsz benne biztos, hogy az imént beírt adatot kapod e vissza vagy annak valamely múltbeli állapotát.

Ez az eventual consistency sajnos user szinten is zárlatot okoz ( = szar a rendszer, most írtam be, hát hová tűnt?!?!?!?), ergó meglehetősen lehetetlen user interfésszel rendelkező szoftvert ilyen hátérre építeni. Batch jobokhoz megfelelő.

Bocs a flame-szagú megjegyzésért de ebből a kommentedből csak az derül ki hogy nem értetted (még) meg mit jelent az eventual consistency :)

-> a user már "látja" amit beírt, a "teljes rendszeren" nem ért végig (esetleg) az információ

Viccet félretéve valóban picit nehezebb jó UI-t írni ilyen rendszerekhez de nem lehetetlen.
Nagyban függ attól is hogy a "consistency" mennyi idő alatt teljesül és mit érzékel ebből a user.

zászló, zászló, szív