Vlákno názorů k článku PostgreSQL 9.0: nový začátek od Radek Hladik - Za prvé, moc pěkný článek. Musím pochválit. Chtěl bych...
-
Radek Hladik (neregistrovaný)
Za prvé, moc pěkný článek. Musím pochválit.
Chtěl bych se zeptat, zda je někde nějak přehledně popsána ta replikace, především všechny ty možnosti?
Typicky mi jde o to, že mám server, který bych případně chtěl rozdělit na víc (z výkonových důvodů). Do teď byla možnost jen Slony, ale naprosto se mi příčí přístup přes triggery. Ale netušíl jsem, že existje nějaké API s hooky na replikaci, jak to funguje?
Bohužel se mi zdá, že ten nový přístup nelze použít na nic jiného, než hot standby. Nebo je nějak řešena konzistence jednotlivých serverů? Například když udělám INSERT na master serveru a pak SELECT na libovolném stroji, dostanu již pokaždé i ten nový záznam?
Teoreticky by stačilo nějak server běžící readonly přesvědčít, aby zápisy přeposlal na master server a pokračoval ve zpracování až ve chvíli, kdy záznamy bude mít u sebe. Například případ, kdy založím nový záznam v tabulce faktur a hned si ho načtu zpátky a použiju. -
Radek Hladik (neregistrovaný)
To je zajímavé, jen mám strach, aby to nebylo takové moc překombinované. Ikdyž tohle jeětě vypadá na únosnou mez :-)
Pochopil jsem to správně tak, že věechny ty DB stroje používají jeden sdílený adresář PG_DATA? Jestli ano, jak je pak zajištěno, že master postgres všechno víceméně okamžitě uloží na shared FS? To by se asi dalo vyřešit i tím hot standby, co umí 9.0, ale pořád mi tam chybí ta jistota, že např SELECT okamžitě po INSERTu vráti i nová data…
-
Data na disku konzistentní občas jsou – pokud přijde checkpoint což je v defaultu např. max 5 minut. Jinak jsou změny zachyceny pouze v cache (shared-buffers), a samozřejmě aby nedošlo ke ztrátě dat při výpadku, tak v transakčním logu. Rozdíl mezi uloženými daty a aktuálními daty je zachycen právě v transakčním logu. Nová instance db, i když pojede na daty jiné instance nebude sdílet shared-buffers. Když budete mít kliku, tak to fungovat může – ale nikdo a nic Vám to negarantuje.
-
Mě hlavně není jasné čeho tímhle setupem vlastně chcete dosáhnout …
I kdyby to nakrásně z nějakého záhadného důvodu fungovalo (přes Pavlovy argumenty proč to spolehlivě fungovat nebude), tak mi uniká smysl toho sdíleného disku. Replikace se v zásadě používá v případě že (a) potřebujete záložní systém a nebo (b) rozložit výkon na víc strojů:
(a) zálohování
V tomto případě většinou na slavech nepotřebujete provádět dotazy, stroj tam prostě jenom sedí a „čeká“ až produkce spadne a on se přepne do pozice mastera. Tudíž vás nějaké drobné zpoždění mezi zápisem na masteru a propagací na slave moc nevzrušuje (navíc s hot-standby to bude minimální).
Navíc ten sdílený disk představuje „single point of failure“ tj. například pokud selže hw nebo pokud master při odchodu nějak brutálně rozvrtá ten datový adresář (byť se mi nikdy nic takového nestalo), tak nemáte nic. A to je u zálohování trochu problém …
(b) rozložení výkonu
V případě databází je nejčastějším bottleneckem bezpochyby I/O (na HDD). Tím že používáte sdílený disk tak to zatížení I/O v podstatě nijak nerozkládáte protože všechno jde přes jeden diskový systém (řadič, fyzické disky, …). A navíc to jde ještě přes síť což přidává další latenci (jak moc záleží na síti, síťovkách, atd.).
Čili ani v jednom případě by použití sdíleného disku nebylo funkční řešení …
PS: Jako jo, mohli bysme se bavit o řešeních sdílených discích typu SAN apod. přes které by to teoreticky mohlo fungovat (ale ne pro PostgreSQL, viz. Pavlův příspěvek).
-
Ne zcela rozumím jak to SSD disky řeší …
Vycházím z toho že pokud mám I/O bottleneck na disku, nevyřeším ho tím že na stejném disku rozchodím další instanci databáze která tudíž bude užírat I/O z toho samého disku, čímž problém ještě zhorší. A to že se jedná o SSD na tomhle principu nic nemění, ne?
Navíc je otázka co je to za SSD disky (Flash vs. DRAM) a jaký typ zátěže to je (write vs. read). Např. flash SSD disky mají problémy při zápisu, kdy jsou dokonce pomalejší než tradiční disky – u DRAM SSD tohle samozřejmě neplatí.
Ale připouštím že SSD disky nijak detailně nesleduji a třeba se v poslední době udál nějaký zásadní koncepční zlom.
Nicméně SSD disky jsou obecně dražší a je otázka jestli to ve výsledku je rentabilní řešení. Navíc DB oblast je poměrně konzervativní.
-
Kdyz mate kvalitni storage s kterou jste se asi doposud jeste nesetkal kdyz porad trvdite ze je nejpomalejsi disk a udelate si z toho data sharing group na mainframech pripadne na POWER a nasadite shared disk db reseni – DB2 Purescale na POWER nebo Oracle RAC. nebo DB2 for z/OS tak jeden node v takovem clusteru dela cca 15–25k transakci/sekundu a ma to do 32 uzlu prakticky linearni skalovatelnost.
Pokud narikate nad pomalym diskem tak si kupte lepsi storage a vice RAM, pod 64GB na uzel nema cenu dneska jit.
-
1) Všimněte si prosím že můj příspěvek je formulován ve smyslu „Pokud máte problém s I/O na disku, další instance přistupující na stejný disk nepomůže.“
Nechápu vaši argumentaci ve smyslu „Ale s kvalitní storagí typu … to problém není!“Není, to máte samozřejmě pravdu, ale to také nebylo pointou mého příspěvku. Trochu mi to připomíná vtip končící „Ale vy zase bijete černochy!“
2) Pořád mi nějak uniká jakým zázračným způsobem se ty SSD disky vyhýbají uvedenému principu „když mám problém s I/O na disku, nemá cenu tam rozjíždět další instanci.“ Možná mají vyšší propustnost, nižší latenci atd. ale ten princip pro ně pořád platí …
3) Ano, máte pravdu že s uvedenými technologiemi (alespoň s výjimkou Oracle RAC) běžně do styku nepřijdu. Jste holt lepší. Nicméně tak nějak jsem – možná mylně – předpokládal že pisatel původního příspěvku se na takovém prostředí nepohybuje. A i kdyby pohyboval, formulace mého příspěvku s tím nijak v rozporu není (viz. první odstavec).
4) Tvrdím že disk je nejčastější příčinou výkonnostních problémů na DB. Netvrdím a nikdy jsem netvrdil že to tak je vždy, za každých okolností a na každém hw. Předpokládám ale že se shodneme že na standardním hw to tak je.
5) Bez ohledu na předchozí body je to v případě PostgreSQL bezpředmětná diskuse, protože PostgreSQL provoz více instancí nad sdíleným adresářem nepodporuje.
-
budem sice mozno trocha off topic, lebo ako sa chova postgres neviem, kazdopadne s cimsi podobnym som sa stretol u berkeley, ktora ma podobnu funkcionalitu implementovanu uz niekolko verzii.
berkeley nedisponuje frameworkom na preposielanie write requestov z replikanta (slave-a) na master-a a co sa tyka garancie toho, ze zaznam, ktory slave vracia, je vzdy aktualny, toto berkeley zarucit nedokaze a zrejme sa to ani neda. je vsak mozne zarucit, ze databaza je v bode citania v ramci transakcie plne konzistentna najvyssim levelom separacie transakcie tak, ze pripadne novo commitnute transakcne logy sa v kontexte v minulosti zacatej transakcie neprejavia.
nezabezpeci to sice, ze bude vzdy vidno najnovsie data, ale zabezpeci to, ze v pripade dlhotrvajucej transakcie na replikantovi, ktoremu je streamovane velke mnozstvo logov bude transakcia konzistentna k bodu jej vytvorenia a neobjavia sa v nej data, ktore boli commitnute logom, ktory dorazil po zacati transakcie. hovori sa tomu snapshoting, ale netusim, ci to postgres bude vediet.
samozrejme, cim vacsi pocet takto osetrenych transakcii a cim vacsie mnozstvo commitov, tym viac pamate si to vyzaduje.
-
Hot standby je popsáno v dokumentaci http://developer.postgresql.org/pgdocs/postgres/index.html . Popis možných hooks bohužel nikde není – není to nic, pro běžného uživatele – ohledně replikací by bylo možné se inspirovat v Slony2. Jinak – jak slony, tak hot standby implementují asynchronní master/slave replikaci. Vy asi hledáte synchronní master/master replikaci – tu například poskytuje projekt pg_cluster – což je speciálně upravená verze PostgreSQL.
-
Radek Hladik (neregistrovaný)
Ten popis hot standby jsem četl. Spíš jsem měl na mysli nějaký souhrn možností a jejich srovnání s nějakým výhledem do budoucna. Můj problém je podle mně docela běžný. Mám DB server, který už nestíhá, je možné pořídit více serverů, ale aplikaci není možné upravit tak, aby pracovala s více servery. A poměrně často se spoléhá na to, že pokud udělám insert/update/delete + commit, tak po commitu už tam ty data budou nebo nebudou (podle operace). Samozřejmě by se mi i líbilo, kdyby se to dostalo do stavu, kdy pád jednoho serveru pouze sníží výkon celého řešení.
Jako jediné použitelné řešení vypadá ten PgPool, který sice představuje SPOF (Single point of failure), ale to by se dalo vyřešit záložním serverem nebo nějakým záložním virtuálem.
ČLÁNKY DO MAILU