K8s, PostgreSQL a replikace na tři nody

[snuff1987]

Caute, zacinam trochu s kubernetes a riesim prave replikaciu postgresql na 3 nodoch. Predstavoval by som si to tak,ze na kazdom z 3 nodov mi bezi postgre pod a ma namountovany persistent volume. Nad postgre je stateless aplikacia ktora s nim komunikuje.

No a potrebujem samozrejme zabezpecit aby vsetko ostalo funkcne aj ked vypadne 1 node.

Moznosti mam si nasledovne.
1. 3krat postgre statefulset s persistent volume, nad tym headless service a replikaciu riesit na urovni postgresql konfigurakmi atd.
2. postgresql s vytvorenym "datovym" kontajnerom ktory bude nadefinovany ako stateful set a nejakym sposobom replikovany na vsetky 3 nody. Ak node vypadne a postgre prestane readovat, k8s ho jednoducho pusti na inom node s uz replikovanym datovym kontanerom
3. network storage ako ceph alebo glusterfs ktory bude sluzit ako volume a bude udrziavat synchronizovane data na vsetkych nodoch, nad tym sa jednoducho pusti postgre s aktualnymi datami.

Neviem ci som sa dobre vyjadril, snad je jasne aspon trochu co myslim.
Najradsej by som sa vyhol konfiguracii replikacie v bode 1 a spravil to bud ako moznost c.2 alebo c.3.

Riesili ste to uz niekto? diky

[Reklama]

[⚫⚫⚫]

Nemam konkretni reseni, ale nejdrive bych se podivat na existujici PostgreSQL operatory a zkusil vyuzit je.

[bobprasak]

Nebude imho fungovat ani jedno z navrhovanych reseni. Chcete multimaster, ale ten v ramci rdbms neni jednoduche udelat. I Oracle RAC funguje nad jednemi daty, pokud chcete mit data jeste v replice musite mit dataguard. Zkratka navystacite si paralelnim fs, pokud zvolite active-pasive reseni neni to zase vhodne pro masazeni do k8s. Jedine reseni ktere
me napada je mit 2 instance jako statefulset, kterym bude predrazena nejaka haproxy, na kterou pujdou prichozi db konexe a bude ta v pripade  failovery/switchoveru prehodi provoz na druhy node. Nicmene i tak nevim jak byste resil treba switchover (otoceni replikace).

IMHO tohle presne ten pripad na co se k8s pouzivat nema , ale treba kolegove prijdou s nejakym reseni co neznam.

[by_cx]

Používám tohle:

https://artifacthub.io/packages/helm/bitnami/postgresql-ha

Vytvoří to X instancí, kde jedna je master. Pokud vypadne node s master instancí, tak se automaticky povýší jiná a mezitím naběhne nová instance na jiném nodu. Je to docela jednoduché nasadit.

[Jan Forman]

Citusdata umí celkem dost, ale asi to není pro každého (počet nodů, správa, mírně odlišné chování)
https://www.citusdata.com

[Reklama]

[_Tomáš_]

k8s na relační databáze bývá jedna z nejhorší kombinací, bohužel často vídaných, dokonce i zmíněný Oracle RAC vidím v tom běžet.

Jednoduché řešení je, nedělej to.

postgresql-ha od bitnami je pěkné řešení (technicky, jako další image od nich), ale pozor na to, že to celé visí na pg proxy, která si udržuje spojení na více pg serverů, hlídá si který je dostupný a pak případě udělá failover. Tady pozor, nemůžeš (=neměl bys) mít více pg proxy, takže ideální nasazení je mít pg proxy jako sidecar k aplikaci a pro každou aplikací vlastní sadu pg.

Citusdata je na tohle takový drobný overkill, to bych nedoporučoval tomu, kdo se na to musí ptát.

Pokud s tím aplikace umí, tak daleko lépe pro takovéhle malé hraní mi ze zkušenosti vychází použít mariadb s galerou v master-master variantě, já vím, nemá global locking, má omezenou velikost na update statement, má vyšší latence, ale zase s sqlproxy si rozumí, funguje to transparentně a když aplikace nemá problémy s nevýhodami, tak i v k8s se nad tím dá stavět, se spoustou hvězdiček.

[snuff1987]

Dakujem za rady od kazdeho, pomohla kazda. Zatial sa pozriem na to bitnami riesenie.

Dalsia vec co som nasiel je
https://github.com/sorintlab/stolon

Uvidim, nieco vymyslim

[Ivan Brezina]

Podivej se ja Crunchydata to umi vsechno co pozadujes.

[_Tomáš_]

Podivej se ja Crunchydata to umi vsechno co pozadujes.

a není už lepší použít https://www.percona.com/software/postgresql-distribution? Crunchydata mi připadají dost uzavřené, řada věcí se tam řeší enteprise cestou (= složitě se spoustou kroků), ale vídám to jen málo. Máš s tím více zkušeností? Dokážeš to popsat a porovnat?

[tvojtatko]

Uplne vsetci na to idu zle.

Vymyslas ohybak na narovnavak.

Toto ti nebude fungovat spolahlivo a uz vobec to nebude skalovat. Co ked tych nodov budes potrebovat 25?

Chces master-less architekturu.

Odpoved je Apache Cassandra.

Su na to aj operatory.

[lazywriter]

Ještě existuje Patroni - https://github.com/zalando/patroni

[_Tomáš_]

Uplne vsetci na to idu zle.

Vymyslas ohybak na narovnavak.

Toto ti nebude fungovat spolahlivo a uz vobec to nebude skalovat. Co ked tych nodov budes potrebovat 25?

Chces master-less architekturu.

Odpoved je Apache Cassandra.

Su na to aj operatory.

snuff1987 tady chce sql databázi a ty mu doporučíš cassandru? Opravdu? Vždyť to je naprosto něco jiného a ještě poměrně složitého na provoz, nevím, proč v poslední době jí tolik lidí vytahuje z hrobu a snaží se na tom stavět projekty a pak si volají o pomoc, když jim to nejde. To je stejně slepá cesta jak mongo, hbase aj.

Nejspíš správné řešení je active-standby a asynchronní synchronizace na standby nody, to pg umí velice dobře. Failover není ve většině projektů tak častý, aby se to muselo řešit bez výpadkově a beztrátově. Odkázané řešení od bitnami, kde logiku failoveru řeší pg proxy není vůbec špatné (technicky, provozně) a pořád máš výhodnu plné sql databáze.

Master-master replikace je vyšší dívčí a v dynamickém prostředí (cloud, k8s, multisite) to nedělá dobroty. Stale stavy, konflikty, dead locky budou nastavát vždy a není snadné se s tím automaticky vypořádat, cena za nevýpadkový provoz jsou provozní výpadky, složitá logika v aplikaci, která vše maskuje a drahá údržba. Naproti tomu active-standby s pravidelnými snapshoty, notifikacemi na vysoký replication lag, udržováním spare instancí je snadné i pro průměrné vývojáře, dobře to funguje v prostředí cloudu a k8s jen s nevýhodou delších failover časů a možností ztráty dat při failoveru, jedná se ale o čerstvá data, která lze aplikačně ošetřit (wait for standby sync).

Samozřejmě, poku se snuff1987 to chce naučit, vyzkoušet si master-master je nejlepší cesta, uvidí co to obnáší a taková zkušenost je k nezaplacení. Pokud ale dělá komerční projekt, neměl by vymýšlet příliš komplexní řešení na hypotetické problémy, může se to vymstít.

[tvojtatko]

Vždyť to je naprosto něco jiného a ještě poměrně složitého na provoz, nevím, proč v poslední době jí tolik lidí vytahuje z hrobu a snaží se na tom stavět projekty a pak si volají o pomoc, když jim to nejde. To je stejně slepá cesta jak mongo, hbase aj.

absolutne netusis o com hovoris Cassandra je vsetko len nie mrtva.

Cassandra 5 bude mat ACID transakcie. Na indexy mas SAI (storage attached index).

Mongo je hracka projekt, to nikto nemoze na produkcii mysliet vazne.HBase ma iny usecase.

Mne pride uplne do popuku ze sa tu riesi replikovany postgres ked toto vyriesili ine DB s prstom v nose pred 10 rokmi.

[snuff1987]

Nakoniec som to vyriesil cez gluster replikovany volume na vsetky nody, cize moznost c.3.. Nad tym bezi 1 kontajner postgre, ktory sa v pripade vypadku nodu do 1minuty presunie na iny node. Testujem, zatial to funguje OK.

[_Tomáš_]

Nakoniec som to vyriesil cez gluster replikovany volume na vsetky nody, cize moznost c.3.. Nad tym bezi 1 kontajner postgre, ktory sa v pripade vypadku nodu do 1minuty presunie na iny node. Testujem, zatial to funguje OK.

mít jednu instanci pg je správné řešení, můžeš mít další nastartovanou jako readonly, ale nedoporučuji v téhle konfiguraci dělat master-master.

absolutne netusis o com hovoris Cassandra je vsetko len nie mrtva.
Cassandra 5 bude mat ACID transakcie. Na indexy mas SAI (storage attached index).

Ano, nestačí jim paxos, protože s ním latence brousí podlahu, tak zkouší raft, ten jim nesedí, je asi příliš málo závislý na čase, takže si přišli s accordem, který spoléhá jen a pouze na přesný čas, ale třeba nám v březnu řeknou víc, že?

Cassandra nepatří do rukou běžným lidem, to musíš očividně sám vědět, správný návrh schémat, způsob práce s daty se musí řešit na úplně začátku a jakákoliv změna v průběhu je složitá. Vektor použití je hodně jiný než obecná RDBMS a jen tak jí doporučit v diskuzi aniž bys tušil jak daná aplikace funguje je nezodpovědné.