Vlákno názorů k článku PostgreSQL 14: nové funkce, nástroje a interní optimalizace od lojdr - Pekny clanek. Diky za nej. ...a docela mi udělalo...

Pekny clanek. Diky za nej.

...a docela mi udělalo radost, že PostgreSQL byla úspěšně použitá na několika větších (kritičtějších) projektech v ČR, kde by se dříve uvažovalo pouze o Oracle nebo MS SQL.

Urcite by jich bylo mnohem vic, kdyby se vyresil naprikad problem s moznou ztratou dat pri synchronnich replikacich a vypadku komunikace mezi nody, ale jak jsem poznal, tak problem je, ze na to neexistuje konsenzus, jak to resit. Smutne je, ze ten konsenzus se nenasel ani za vic jak 10 let co ten problem neexistuje. Chapu, ze je to okrajova oblast a jeji vyreseni je celkem komplexnejsi ukol, ale Oracle v urcite konfiguraci dokaze zabezpecit RPO=0. To PostgreSQL zatim nedokaze. Bohuzel.
Snad se to tedy nekdy v budoucnu vyresi. Drzim PostgreSQL palce.

Mám pocit, že tohle téma se řešilo cca před měsícem v mailing listu.

Když něco takhle dlouho trvá, tak to znamená, že nikdo na to netlačí nebo že se neví, jak to správně udělat. Můžete mít např dvě validní řešení, které se navzájem vylučují, a pak z důvodu zachování zpětné kompatibility nebude možné ten návrh v budoucnu změnit. Tam asi vůbec nejde o technické řešení, ale o argumentaci pro/proti toho správného řešení. O to jak ten problém uchopit, aby bylo možné se správně rozhodnout.

V komunitním Postgresu fíčury nevznikají samy od sebe. Někdo musí udělat návrh, musí ho obhájit (a řeší se jenom věcná správnost a udržitelnost do budoucna), a musí to také naprogramovat. A musím říct jako autor desítek patchů do Postgresu, že obecně komunita (vývojáři) jsou lidé, kteří umí komunikovat, jsou velice chytří, ale mají dost nízkou (prakticky nulovou) toleranci ke kompromisům. Což na jednu stranu garantuje dlouhodobou kvalitu a udržitelnost vývoje, na druhou stranu, některé věci se nemusí pohnout 10 let (komunita vůbec neřeší byznys, řeší jen kvalitu). Takže některé věci musí uzrát, na něco potřebujete infrastrukturu, na něco lidi, kteří umí uchopit nějaký problém nějak, a mají dostatečnou motivaci).

U komerčních forků jako je EDB nebo PostgresPro, tak tam se byznys a byznysové fíčury samozřejmě řeší, a tam pak je větší šance, že si koupíte, co potřebujete, pokud potřebujete něco, co v komunitní verzi není.

Nejsem si úplně jistý o jakém problému s potenciální ztrátou dat při sync replikaci je řeč, ale je fakt že replikace / failover / HA nejsou úplně uživatelsky přívětivé, zejména ne bez nějakých dalších nástrojů které se postarají o management toho clusteru.

Ale nemyslím že by to bylo nějakou nechutí ke kompromisům v rámci komunity - spíš jde o to že filozofií PotgreSQL vždycky byla flexibilita, tj. snaha poskytnout infrastrukturu a "API" na kterých pak mohou vznikat řešení s různými vlastnostmi atd. Tj. místo toho aby se "zadrátovala" jedna varianta jak dělat HA, tak existují různá externí řešení (asi každá firma poskytující PostgreSQL služby má dnes vlastní tool). Což je na jednu stranu trochu "hloupé" pokud chcete prostě nějaký "default" HA cluster, ale součaně je prostě pravda že každé to řešní má trochu jiné silné/slabé stránky, a nic jako očividně "správné" řešení neexistuje. Např. mohou vznikat HA řešení "na míru" pro různá prostředí (např. různé cloudy, kubernetes, ...).

Je nicméně pravda že občas to může způsobovat "zaseknutí" vývoje protože bez ukázky řešení se těžko formuluje API. To je jeden z důvodů proč tak dlouho trvalo než se v PostgreSQL objevila pořádná nativní replikace, protože snaha byla udělat API, ale nikdo nevěděl jak přesně to API má vypadat protože neexistovalo žádné replikační řešení.

U toho co jsem uvadel, jde o situaci, kdy PostgreSQL vrati nasledujici varovani.

WARNING: canceling wait for synchronous replication due to user request
DETAIL: The transaction has already committed locally, but might not have
been replicated to the standby.

Tam pak v pripade vypadku site synchronniho nodu muze dojit k tomu, ze data jsou commitnuta a pristupna dalsim aplikacim na master nodu, ale nejsou zpropagovana na standby nodu (i v pripade synchronni replikace).
Kdyz se pak o mastera prijde, tak se prijde i o ta "nova" data.
Tady je to bych spise rekl na urovni PostgreSQL nez na to resit na urovni nejakeho HA frameworku.
Reseni jsem v mailing listu videl ruzna, ale zadne (pokud jsem neco neopomenul nebo nepreskocil) samo o sobe nedokazalo resit vsechny situace, ktere mohly nastat. Coz je mozna duvod, proc ten problem existuje dodnes.

Tak jistě, ale to určitě nejde brát jako ztrátu dat - pokud se rozhodnete nečekat na COMMIT, tak vám *žádná* DB nemůže za nic ručit. V principu je to úplně stejná situace jako když pošlete COMMIT a než vám přijde odpověď tak zavřete spojení. Pak taky nevíte v jakém stavu ta transakce je.

Problém je, že vy na standby nemáte věrohodnou informaci o tom, že na masteru ta data byla commitnutá. Je to 50 na 50. Kdyby to byla opačná situace, tak by se mohlo stát, že transakce se na masteru rollbacka a na odpojeném standby commitnula. Má to úplně tu samou pravděpodobnost. Aby to bylo úplně korektní, tak by se musel použít 2PC commit, a to by bylo zoufale pomalé. Uznávám, že jsou situace, kdy tenhle způsob měl smysl, ale bohužel, nikdo to nenaimplementoval.

U dvou serveru nikdy nebudes mit quorum. To je jako split brain a resi se obdobne jako u ostatnich distribuovanych systemu. Nahodis ty repliky dve a reknes, ze prvni ziva z nich je synchronni:

alter system set synchronous_standby_names = 'FIRST 1 ("db-2", "db-3")';
select pg_reload_conf();