{"id":35706,"date":"2019-10-31T22:05:50","date_gmt":"2019-10-31T19:05:50","guid":{"rendered":"https:\/\/prohoster.info\/blog\/otkazoustojchivyj-klaster-postgresql-patroni-opyt-vnedreniya\/"},"modified":"2026-05-18T20:58:46","modified_gmt":"2026-05-18T18:58:46","slug":"otkazoustojchivyj-klaster-postgresql-patroni-opyt-vnedreniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/otkazoustojchivyj-klaster-postgresql-patroni-opyt-vnedreniya","title":{"rendered":"Hib\u00e1tlan PostgreSQL klaszter + Patroni. Bevezet\u00e9si tapasztalatok.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>A cikkben bemutatom, hogyan k\u00f6zel\u00edtett\u00fck meg a PostgreSQL redundanci\u00e1j\u00e1nak k\u00e9rd\u00e9s\u00e9t, mi\u00e9rt v\u00e1lt ez sz\u00e1munkra fontoss\u00e1, \u00e9s mi lett az eredm\u00e9nye.<\/p>\n<p>Magas terhel\u00e9s\u0171 szolg\u00e1ltat\u00e1sunk van: 2,5 milli\u00f3 felhaszn\u00e1l\u00f3 vil\u00e1gszerte, napi 50K+ akt\u00edv felhaszn\u00e1l\u00f3. A szerverek az Amazone-n\u00e1l egy \u00edr r\u00e9gi\u00f3ban tal\u00e1lhat\u00f3k: folyamatosan 100+ k\u00fcl\u00f6nb\u00f6z\u0151 szerver m\u0171k\u00f6dik, ebb\u0151l k\u00f6zel 50 adatb\u00e1zisokkal.<\/p>\n<p>Az eg\u00e9sz backend egy nagy monolitikus, \u00e1llapotmeg\u0151rz\u0151 alkalmaz\u00e1s Java-ban, amely folyamatos websocket kapcsolatot tart fenn az \u00fcgyf\u00e9llel. Amikor t\u00f6bb felhaszn\u00e1l\u00f3 dolgozik egyszerre egy t\u00e1bl\u00e1n, mindannyian val\u00f3s id\u0151ben l\u00e1tj\u00e1k a v\u00e1ltoz\u00e1sokat, mert minden v\u00e1ltoz\u00e1st r\u00f6gz\u00edt\u00fcnk az adatb\u00e1zisban. K\u00f6r\u00fclbel\u00fcl 10K lek\u00e9rdez\u00e9s\u00fcnk van m\u00e1sodpercenk\u00e9nt az adatb\u00e1zisainkra. Cs\u00facsid\u0151szakban a Redis-ben 80-100K lek\u00e9rdez\u00e9st \u00edrunk m\u00e1sodpercenk\u00e9nt.<br \/>\n<img decoding=\"async\" style=\"display: block; margin: 0 auto;\" src=\"\/wp-content\/uploads\/2019\/06\/443f85815b0560fade7db5b639942935.png\" alt=\"Hib\u00e1tlan PostgreSQL klaszter + Patroni. Bevezet\u00e9si tapasztalatok.\" \/><br \/>\n<a rel=\"nofollow\" name=\"habracut\"><\/a><\/p>\n<h2>Mi\u00e9rt v\u00e1ltottunk a Redis-r\u00f3l PostgreSQL-ra<\/h2>\n<p>Kezdetben szolg\u00e1ltat\u00e1sunk Redis-szal m\u0171k\u00f6d\u00f6tt, egy key-value t\u00e1rol\u00f3val, amely minden adatot a RAM-ban t\u00e1rol. <a href=\"https:\/\/prohoster.info\/hu\/server\/\">a szerver<\/a>.<\/p>\n<p>A Redis el\u0151nyei:<\/p>\n<ol>\n<li>Magas v\u00e1laszsebess\u00e9g, mivel minden az mem\u00f3ri\u00e1ban t\u00e1rol\u00f3dik;<\/li>\n<li>K\u00f6nny\u0171 ment\u00e9s \u00e9s replik\u00e1ci\u00f3.<\/li>\n<\/ol>\n<p>A Redis h\u00e1tr\u00e1nyai sz\u00e1munkra:<\/p>\n<ol>\n<li>Nincsenek val\u00f3di tranzakci\u00f3k. Pr\u00f3b\u00e1ltuk ezeket az alkalmaz\u00e1sunk szintj\u00e9n imit\u00e1lni. Sajnos ez nem mindig m\u0171k\u00f6d\u00f6tt j\u00f3l, \u00e9s rendk\u00edv\u00fcl bonyolult k\u00f3d \u00edr\u00e1s\u00e1t ig\u00e9nyelte.<\/li>\n<li>Az adatok mennyis\u00e9g\u00e9t a mem\u00f3ria mennyis\u00e9ge korl\u00e1tozza. Az adatok n\u00f6veked\u00e9s\u00e9vel a mem\u00f3ria is n\u00f6vekedni fog, \u00e9s v\u00e9g\u00fcl bele\u00fctk\u00f6z\u00fcnk a v\u00e1lasztott p\u00e9ld\u00e1ny jellemz\u0151ibe, ami az AWS-n\u00e9l megk\u00f6veteli a szolg\u00e1ltat\u00e1sunk le\u00e1ll\u00edt\u00e1s\u00e1t az p\u00e9ld\u00e1ny t\u00edpusa v\u00e1ltoztat\u00e1sa \u00e9rdek\u00e9ben.<\/li>\n<li>Folyamatosan fenntartani kell az alacsony k\u00e9sleltet\u00e9st, mert nagyon sok lek\u00e9rdez\u00e9s\u00fcnk van. Az optim\u00e1lis k\u00e9sleltet\u00e9si szint\u00fcnk 17-20 ms. 30-40 ms k\u00e9sleltet\u00e9si szinten hossz\u00fa v\u00e1laszokat kapunk az alkalmaz\u00e1sunk lek\u00e9rdez\u00e9seire, \u00e9s a szolg\u00e1ltat\u00e1s degrad\u00e1ci\u00f3j\u00e1t tapasztaljuk. Sajnos ez 2018 szeptember\u00e9ben t\u00f6rt\u00e9nt, amikor az egyik Redis p\u00e9ld\u00e1ny valami\u00e9rt k\u00e9tszer olyan k\u00e9sleltet\u00e9st kapott, mint \u00e1ltal\u00e1ban. A probl\u00e9ma megold\u00e1s\u00e1hoz le\u00e1ll\u00edtottuk a szolg\u00e1ltat\u00e1st a munkanap k\u00f6zep\u00e9n nem tervezett karbantart\u00e1s c\u00e9lj\u00e1b\u00f3l \u00e9s kicser\u00e9lt\u00fck a hib\u00e1s Redis p\u00e9ld\u00e1nyt.<\/li>\n<li>K\u00f6nnyen el\u0151fordulhat az adatok konzisztenci\u00e1j\u00e1nak elveszt\u00e9se m\u00e9g kisebb k\u00f3dhiba eset\u00e9n is, \u00e9s sok id\u0151t lehet elt\u00f6lteni az adatok jav\u00edt\u00e1s\u00e1ra k\u00e9sz\u00fclt k\u00f3d \u00edr\u00e1s\u00e1val.<\/li>\n<\/ol>\n<p>Figyelembe vett\u00fck a h\u00e1tr\u00e1nyokat, \u00e9s meg\u00e9rtett\u00fck, hogy valami k\u00e9nyelmesebbre van sz\u00fcks\u00e9g\u00fcnk, norm\u00e1lis tranzakci\u00f3kkal \u00e9s kisebb k\u00e9sleltet\u00e9ssel. Kutat\u00e1st v\u00e9gezt\u00fcnk, elemezt\u00fcnk sz\u00e1mos lehet\u0151s\u00e9get, \u00e9s a PostgreSQL-t v\u00e1lasztottuk.<\/p>\n<p>Az \u00faj adatb\u00e1zisra m\u00e1r m\u00e1sf\u00e9l \u00e9ve k\u00f6lt\u00f6z\u00fcnk, \u00e9s csak egy kis mennyis\u00e9g\u0171 adatot vitt\u00fcnk \u00e1t, ez\u00e9rt most p\u00e1rhuzamosan dolgozunk a Redis-szal \u00e9s a PostgreSQL-vel. A k\u00f6lt\u00f6z\u00e9s f\u00e1zisair\u00f3l \u00e9s az adatok k\u00f6z\u00f6tti v\u00e1lt\u00e1sr\u00f3l az al\u00e1bbi cikkben olvashat. <a href=\"https:\/\/habr.com\/ru\/company\/miro\/blog\/437826\/\" rel=\"nofollow\">a koll\u00e9g\u00e1m cikk\u00e9ben<\/a>.<\/p>\n<p>Amikor elkezdt\u00fck a k\u00f6lt\u00f6z\u00e9st, az alkalmaz\u00e1sunk k\u00f6zvetlen\u00fcl az adatb\u00e1zissal dolgozott, a Redis \u00e9s a PostgreSQL mester\u00e9hez fordulva. A PostgreSQL klaszter egy mesterb\u0151l \u00e9s egy aszinkron replik\u00e1b\u00f3l \u00e1llt. \u00cdgy n\u00e9zett ki a munkafolyamat a b\u00e1zisokkal:<br \/>\n<img decoding=\"async\" style=\"display: block; margin: 0 auto;\" src=\"\/wp-content\/uploads\/2019\/06\/674dd77de4c8b48a946c9f64c0b2fdd1.png\" alt=\"Hib\u00e1tlan PostgreSQL klaszter + Patroni. Bevezet\u00e9si tapasztalatok.\" \/><\/p>\n<h2>PgBouncer bevezet\u00e9se<\/h2>\n<p>Mik\u00f6zben k\u00f6lt\u00f6zt\u00fcnk, a term\u00e9k is fejl\u0151d\u00f6tt: n\u0151tt a felhaszn\u00e1l\u00f3k sz\u00e1ma \u00e9s a PostgreSQL-t haszn\u00e1l\u00f3 szerverek sz\u00e1ma, ez\u00e9rt elfogytak a kapcsolatok. A PostgreSQL minden egyes kapcsolat eset\u00e9n k\u00fcl\u00f6n folyamatot hoz l\u00e9tre, \u00e9s fogyasztja az er\u0151forr\u00e1sokat. A kapcsolatok sz\u00e1m\u00e1t egy bizonyos pontig lehet n\u00f6velni, k\u00fcl\u00f6nben el\u0151fordulhat, hogy a BDB nem optim\u00e1lis m\u00f3don m\u0171k\u00f6dik. Ilyen helyzetben ide\u00e1lis lenne egy kapcsolattart\u00f3 menedzsert v\u00e1lasztani, amely a b\u00e1zis el\u0151tt \u00e1ll.<\/p>\n<p>K\u00e9t lehet\u0151s\u00e9g\u00fcnk volt a kapcsolatkezel\u0151 sz\u00e1m\u00e1ra: Pgpool \u00e9s PgBouncer. Az els\u0151 viszont nem t\u00e1mogatja az adatb\u00e1zissal val\u00f3 tranzakci\u00f3s m\u00f3dban val\u00f3 m\u0171k\u00f6d\u00e9st, ez\u00e9rt a PgBouncer-t v\u00e1lasztottuk.<\/p>\n<p>A k\u00f6vetkez\u0151 munkas\u00e9m\u00e1t \u00e1ll\u00edtottuk be: az alkalmaz\u00e1sunk egy PgBouncerhez fordul, amely m\u00f6g\u00f6tt a PostgreSQL mesterei \u00e1llnak, \u00e9s minden mester m\u00f6g\u00f6tt egy aszinkron replik\u00e1val rendelkez\u0151 replik\u00e1t tal\u00e1lunk.<br \/>\n<img decoding=\"async\" style=\"display: block; margin: 0 auto;\" src=\"\/wp-content\/uploads\/2019\/06\/dabcb7f6006520c4fec85fb925e8975e.png\" alt=\"Hib\u00e1tlan PostgreSQL klaszter + Patroni. Bevezet\u00e9si tapasztalatok.\" \/><\/p>\n<p>Ezen k\u00edv\u00fcl nem tudtuk az \u00f6sszes adat mennyis\u00e9g\u00e9t a PostgreSQL-ben t\u00e1rolni, \u00e9s fontos volt sz\u00e1munkra az adatb\u00e1zis sebess\u00e9ge, ez\u00e9rt elkezdt\u00fck a PostgreSQL sharding-el\u00e9s\u00e9t az alkalmaz\u00e1si szinten. A fent le\u00edrt s\u00e9ma viszonylag k\u00e9nyelmes ehhez: \u00faj shard hozz\u00e1ad\u00e1sakor elegend\u0151 a PgBouncer konfigur\u00e1ci\u00f3j\u00e1nak friss\u00edt\u00e9se, \u00e9s az alkalmaz\u00e1s azonnal k\u00e9pes lesz dolgozni az \u00faj sharddal.<\/p>\n<h3>PgBouncer hibat\u0171r\u00e9s<\/h3>\n<p>Ez a rendszer addig m\u0171k\u00f6d\u00f6tt, am\u00edg az egyetlen PgBouncer p\u00e9ld\u00e1ny le nem \u00e1llt. Az AWS-en vagyunk, ahol minden p\u00e9ld\u00e1ny olyan hardveren fut, ami id\u0151nk\u00e9nt le\u00e1ll. Ilyen esetekben a p\u00e9ld\u00e1ny egyszer\u0171en \u00e1tk\u00f6lt\u00f6zik egy \u00faj hardverre, \u00e9s ism\u00e9t m\u0171k\u00f6dik. \u00cdgy t\u00f6rt\u00e9nt a PgBouncer-rel is, azonban az el\u00e9rhetetlenn\u00e9 v\u00e1lt. Ennek a le\u00e1ll\u00e1snak az eredm\u00e9nyek\u00e9nt szolg\u00e1ltat\u00e1sunk 25 percig nem volt el\u00e9rhet\u0151. Az AWS ilyen helyzetekre azt javasolja, hogy haszn\u00e1ljunk redundanci\u00e1t a felhaszn\u00e1l\u00f3i oldalon, ami akkoriban n\u00e1lunk nem volt megval\u00f3s\u00edtva.<\/p>\n<p>Ezt k\u00f6vet\u0151en komolyan elgondolkodtunk a PgBouncer \u00e9s a PostgreSQL klaszterek hibakezel\u00e9si lehet\u0151s\u00e9gein, mert hasonl\u00f3 szitu\u00e1ci\u00f3 b\u00e1rmelyik p\u00e9ld\u00e1nnyal megism\u00e9tl\u0151dhetett volna az AWS fi\u00f3kunkban.<\/p>\n<p>A PgBouncer hibakezel\u00e9si strukt\u00far\u00e1j\u00e1t a k\u00f6vetkez\u0151k\u00e9ppen \u00e9p\u00edtett\u00fck fel: minden alkalmaz\u00e1sszerver a Network Load Balancer-hez fordul, amely m\u00f6g\u00f6tt k\u00e9t PgBouncer \u00e1ll. Mindk\u00e9t PgBouncer ugyanazokat a master PostgreSQL adatb\u00e1zisokat figyeli, minden shard eset\u00e9n. Ha megism\u00e9tl\u0151dik az AWS p\u00e9ld\u00e1ny le\u00e1ll\u00e1s\u00e1nak helyzete, az \u00f6sszes forgalom \u00e1tir\u00e1ny\u00edt\u00e1sra ker\u00fcl a m\u00e1sik PgBouncer-hez. A Network Load Balancer hibakezel\u00e9s\u00e9t az AWS biztos\u00edtja.<\/p>\n<p>Ez a rendszer lehet\u0151v\u00e9 teszi \u00faj PgBouncer szerverek probl\u00e9mamentes hozz\u00e1ad\u00e1s\u00e1t.<br \/>\n<img decoding=\"async\" style=\"display: block; margin: 0 auto;\" src=\"\/wp-content\/uploads\/2019\/06\/2c1f1e7d9f7be4fdeb43858520d55e36.png\" alt=\"Hib\u00e1tlan PostgreSQL klaszter + Patroni. Bevezet\u00e9si tapasztalatok.\" \/><\/p>\n<h2>Hibakezel\u0151 klaszter l\u00e9trehoz\u00e1sa PostgreSQL alatt<\/h2>\n<p>Ennek a probl\u00e9m\u00e1nak a megold\u00e1sakor k\u00fcl\u00f6nb\u00f6z\u0151 lehet\u0151s\u00e9geket vizsg\u00e1ltunk: h\u00e1zilag \u00edrt failover, repmgr, AWS RDS, Patroni.<\/p>\n<h3>Saj\u00e1t \u00edr\u00e1s\u00fa szkriptek<\/h3>\n<p>Ezek k\u00e9pesek figyelni a master m\u0171k\u00f6d\u00e9s\u00e9t, \u00e9s ha az le\u00e1ll, a replik\u00e1t masterr\u00e9 l\u00e9ptetik el\u0151 \u00e9s friss\u00edtik a PgBouncer konfigur\u00e1ci\u00f3t.<\/p>\n<p>Ennek a megk\u00f6zel\u00edt\u00e9snek az el\u0151nye a maxim\u00e1lis egyszer\u0171s\u00e9g, mert saj\u00e1t magunk \u00edrunk scriptet, \u00e9s pontosan \u00e9rtj\u00fck, hogyan m\u0171k\u00f6dnek.<\/p>\n<p>H\u00e1tr\u00e1nyok:<\/p>\n<ul>\n<li>Lehets\u00e9ges, hogy a master nem is \u00e1llt le, hanem h\u00e1l\u00f3zati hiba t\u00f6rt\u00e9nt. A failover, nem tudva err\u0151l, el\u0151l\u00e9pteti a replik\u00e1t masterr\u00e9, m\u00edg a r\u00e9gi master tov\u00e1bb m\u0171k\u00f6dik. Ennek k\u00f6vetkezt\u00e9ben k\u00e9t master szerver\u00fcnk lesz, \u00e9s nem tudjuk, melyiken vannak a legfrissebb adatok. Ezt a helyzetet split-brain helyzetnek h\u00edvj\u00e1k.<\/li>\n<li>Replika n\u00e9lk\u00fcl maradtunk. A mi konfigur\u00e1ci\u00f3nkban van egy master \u00e9s egy replika; a v\u00e1lt\u00e1s ut\u00e1n a replika el\u0151l\u00e9p a masterr\u00e9, \u00e9s t\u00f6bb\u00e9 nincs replik\u00e1nk, ez\u00e9rt manu\u00e1lisan kell \u00faj replik\u00e1t hozz\u00e1adnunk.<\/li>\n<li>Tov\u00e1bbi monitoring sz\u00fcks\u00e9ges a failover m\u0171k\u00f6d\u00e9s\u00e9hez, mik\u00f6zben 12 PostgreSQL shardunk van, ami azt jelenti, hogy 12 klasztert kell figyeln\u00fcnk. A shardok sz\u00e1m\u00e1nak n\u00f6vel\u00e9s\u00e9n\u00e9l ne felejts\u00fck el friss\u00edteni a failover-t.<\/li>\n<\/ul>\n<p>A saj\u00e1t fejleszt\u00e9s\u0171 failover nagyon bonyolultnak t\u0171nik, \u00e9s nem trivialis t\u00e1mogat\u00e1st ig\u00e9nyel. Egy PostgreSQL klaszter eset\u00e9n ez a legegyszer\u0171bb megold\u00e1s, de nem sk\u00e1l\u00e1zhat\u00f3, \u00edgy nem alkalmas sz\u00e1munkra.<\/p>\n<h3>Repmgr<\/h3>\n<p>Replication Manager PostgreSQL klaszterekhez, amely k\u00e9pes kezelni a PostgreSQL klaszter m\u0171k\u00f6d\u00e9s\u00e9t. Viszont nincs automatikus failover \u201edobozb\u00f3l\u201d, ez\u00e9rt sz\u00fcks\u00e9g van egy saj\u00e1t \u201ewrapper\u201d \u00edr\u00e1s\u00e1ra a k\u00e9sz megold\u00e1s f\u00f6l\u00e9. \u00cdgy lehet, hogy m\u00e9g bonyolultabb\u00e1 v\u00e1lik, mint a saj\u00e1t szkriptek eset\u00e9ben, ez\u00e9rt a Repmgrt nem is pr\u00f3b\u00e1ltuk ki.<\/p>\n<h3>AWS RDS<\/h3>\n<p>T\u00e1mogat mindent, amire sz\u00fcks\u00e9g\u00fcnk van, k\u00e9pes biztons\u00e1gi ment\u00e9seket k\u00e9sz\u00edteni, \u00e9s kezeli a kapcsolati medenc\u00e9t. Van automatikus \u00e1tv\u00e1lt\u00e1s: ha a mester le\u00e1ll, a replik\u00e1ci\u00f3 \u00faj mesterk\u00e9nt l\u00e9p fel, \u00e9s az AWS friss\u00edti a DNS bejegyz\u00e9st az \u00faj mesterre, mik\u00f6zben a replik\u00e1k k\u00fcl\u00f6nb\u00f6z\u0151 AZ-okban lehetnek.<\/p>\n<p>A h\u00e1tr\u00e1nyok k\u00f6z\u00e9 tartozik a finom be\u00e1ll\u00edt\u00e1sok hi\u00e1nya. P\u00e9ld\u00e1ul a finom be\u00e1ll\u00edt\u00e1sok k\u00f6z\u00e9 tartozik: a mi p\u00e9ld\u00e1nyainkon korl\u00e1toz\u00e1sok vannak a tcp kapcsolatokra, amit sajnos nem lehet megtenni az RDS-ben:<\/p>\n<pre><code class=\"python\">net.ipv4.tcp_keepalive_time=10\nnet.ipv4.tcp_keepalive_intvl=1\nnet.ipv4.tcp_keepalive_probes=5\nnet.ipv4.tcp_retries2=3\n<\/code><\/pre>\n<p>Ezenk\u00edv\u00fcl az AWS RDS \u00e1ra majdnem k\u00e9tszerese a szok\u00e1sos p\u00e9ld\u00e1ny\u00e1rnak, ami a f\u0151 oka a d\u00f6nt\u00e9s\u00fcnk elvet\u00e9s\u00e9nek.<\/p>\n<h3>Patroni<\/h3>\n<p>Ez egy python sablon a PostgreSQL kezel\u00e9s\u00e9re, j\u00f3 dokument\u00e1ci\u00f3val, automatikus failoverrel \u00e9s a GitHubon el\u00e9rhet\u0151 forr\u00e1sk\u00f3ddal.<\/p>\n<p>A Patroni el\u0151nyei:<\/p>\n<ul>\n<li>Minden konfigur\u00e1ci\u00f3s param\u00e9ter egy\u00e9rtelm\u0171en le van \u00edrva, vil\u00e1gos, hogyan m\u0171k\u00f6dik minden;<\/li>\n<li>Az automatikus failover dobozb\u00f3l m\u0171k\u00f6dik;<\/li>\n<li>Python nyelven \u00edr\u00f3dott, \u00e9s mivel mi is sokat \u00edrunk pythonban, nek\u00fcnk k\u00f6nnyebb lesz a probl\u00e9m\u00e1k megold\u00e1sa, \u00e9s lehet, hogy m\u00e9g a projekt fejleszt\u00e9s\u00e9ben is tudunk seg\u00edteni;<\/li>\n<li>Teljes m\u00e9rt\u00e9kben kezeli a PostgreSQL-t, lehet\u0151v\u00e9 t\u00e9ve a konfigur\u00e1ci\u00f3 azonnali megv\u00e1ltoztat\u00e1s\u00e1t a klaszter \u00f6sszes csom\u00f3pontj\u00e1n; ha pedig a \u00faj konfigur\u00e1ci\u00f3 alkalmaz\u00e1s\u00e1hoz a klaszter \u00fajraind\u00edt\u00e1sa sz\u00fcks\u00e9ges, ezt ism\u00e9t a Patronival lehet megtenni.<\/li>\n<\/ul>\n<p>H\u00e1tr\u00e1nyok:<\/p>\n<ul>\n<li>A dokument\u00e1ci\u00f3b\u00f3l nem vil\u00e1gos, hogyan kell helyesen dolgozni a PgBouncer-rel. B\u00e1r ezt neh\u00e9z h\u00e1tr\u00e1nyk\u00e9nt eml\u00edteni, mert a Patroni feladata a PostgreSQL kezel\u00e9se, hogy a csatlakoz\u00e1sok hogyan mennek be a Patroniba, az m\u00e1r a mi probl\u00e9m\u00e1nk;<\/li>\n<li>Kev\u00e9s p\u00e9lda van a Patroni nagy terhel\u00e9s\u0171 bevezet\u00e9s\u00e9re, ugyanakkor sz\u00e1mos p\u00e9lda tal\u00e1lhat\u00f3 a null\u00e1r\u00f3l val\u00f3 bevezet\u00e9sre.<\/li>\n<\/ul>\n<p>V\u00e9g\u00fcl a hibamentes klaszter l\u00e9trehoz\u00e1s\u00e1hoz a Patroni mellett d\u00f6nt\u00f6tt\u00fcnk.<\/p>\n<h2>A Patroni bevezet\u00e9si folyamata<\/h2>\n<p>A Patroni el\u0151tt 12 PostgreSQL shardunk volt egy mester \u00e9s egy replik\u00e1val, aszinkron replik\u00e1ci\u00f3val. Az alkalmaz\u00e1s szerverek a Network Load Balancer-en kereszt\u00fcl \u00e9rtek el az adatb\u00e1zisokat, amely m\u00f6g\u00f6tt k\u00e9t PgBouncer p\u00e9ld\u00e1ny \u00e1llt, \u00e9s m\u00f6g\u00f6tt\u00fck voltak az \u00f6sszes PostgreSQL szerver.<br \/>\n<img decoding=\"async\" style=\"display: block; margin: 0 auto;\" src=\"\/wp-content\/uploads\/2019\/06\/8e5350d2466311593e11add30d5b1bdc.png\" alt=\"Hib\u00e1tlan PostgreSQL klaszter + Patroni. Bevezet\u00e9si tapasztalatok.\" \/><\/p>\n<p>A Patroni bevezet\u00e9s\u00e9hez el kellett v\u00e1lasztanunk egy elosztott konfigur\u00e1ci\u00f3s t\u00e1rol\u00f3t a klaszter sz\u00e1m\u00e1ra. A Patroni elosztott konfigur\u00e1ci\u00f3s t\u00e1rol\u00f3rendszerekkel m\u0171k\u00f6dik, mint az etcd, Zookeeper, Consul. A termel\u00e9si k\u00f6rnyezet\u00fcnkben van egy teljes Consul klaszter\u00fcnk, amely egy\u00fctt m\u0171k\u00f6dik a Vault-tal, \u00e9s egy\u00e9bk\u00e9nt nem haszn\u00e1ljuk. Kiv\u00e1l\u00f3 lehet\u0151s\u00e9g a Consul c\u00e9lzott haszn\u00e1lat\u00e1ra.<\/p>\n<h3>Hogyan m\u0171k\u00f6dik a Patroni a Consul-lal<\/h3>\n<p>Van egy h\u00e1rom node-b\u00f3l \u00e1ll\u00f3 Consul klaszter\u00fcnk \u00e9s egy Patroni klaszter\u00fcnk, amely egy vezet\u0151b\u0151l \u00e9s egy replik\u00e1b\u00f3l \u00e1ll (a Patroni-ban a mester a klaszter vezet\u0151je, a replik\u00e1k pedig replik\u00e1k). Minden Patroni klaszter p\u00e9ld\u00e1ny folyamatosan k\u00fcld inform\u00e1ci\u00f3t a klaszter \u00e1llapot\u00e1r\u00f3l a Consul-nak. Ez\u00e9rt a Consul-b\u00f3l mindig meg lehet tudni a Patroni klaszter aktu\u00e1lis konfigur\u00e1ci\u00f3j\u00e1t \u00e9s azt, ki a vezet\u0151 az adott pillanatban.<\/p>\n<p><img decoding=\"async\" style=\"display: block; margin: 0 auto;\" src=\"\/wp-content\/uploads\/2019\/06\/3234594b363904424fdce64c9d77fca5.png\" alt=\"Hib\u00e1tlan PostgreSQL klaszter + Patroni. Bevezet\u00e9si tapasztalatok.\" \/><\/p>\n<p>A Patroni Consul-hoz val\u00f3 csatlakoz\u00e1s\u00e1hoz elegend\u0151 tanulm\u00e1nyozni a hivatalos dokument\u00e1ci\u00f3t, amelyben le van \u00edrva, hogy meg kell adni a hostot http vagy https form\u00e1tumban, att\u00f3l f\u00fcgg\u0151en, hogyan dolgozunk a Consul-lal, \u00e9s az opcion\u00e1lis csatlakoz\u00e1si s\u00e9m\u00e1t:<\/p>\n<pre><code class=\"plaintext\">host: a Consul v\u00e9gpont host:port c\u00edme, form\u00e1tumban: http(s):\/\/host:port\nscheme: (opcion\u00e1lis) http vagy https, alap\u00e9rtelmez\u00e9s szerint http<\/code><\/pre>\n<p>Egyszer\u0171nek t\u0171nik, de itt kezd\u0151dnek a buktat\u00f3k. A Consul-lal v\u00e9dett kapcsolatot haszn\u00e1lunk https-en kereszt\u00fcl, \u00e9s a csatlakoz\u00e1si konfigur\u00e1ci\u00f3nk a k\u00f6vetkez\u0151k\u00e9ppen n\u00e9z ki:<\/p>\n<pre><code class=\"python\">consul:\n  host: https:\/\/server.production.consul:8080 \n  verify: true\n  cacert: {{ consul_cacert }}\n  cert: {{ consul_cert }}\n  key: {{ consul_key }}<\/code><\/pre>\n<p>De \u00edgy nem m\u0171k\u00f6dik. A Patroni ind\u00edt\u00e1sakor nem tud csatlakozni a Consul-hoz, mert tov\u00e1bbra is http-n pr\u00f3b\u00e1lkozik.<\/p>\n<p>A probl\u00e9ma meg\u00e9rt\u00e9s\u00e9ben seg\u00edtett a Patroni forr\u00e1sk\u00f3dja. J\u00f3, hogy Python nyelven \u00edrt\u00e1k. Kider\u00fclt, hogy a host param\u00e9tert nem elemzik, \u00e9s a protokollt a scheme-ben kell megadni. \u00cdgy n\u00e9z ki a m\u0171k\u00f6d\u0151 konfigur\u00e1ci\u00f3s blokk a Consul-lal val\u00f3 kapcsolatunkhoz:<\/p>\n<pre><code class=\"python\">consul:\n  host: server.production.consul:8080\n  scheme: https\n  verify: true\n  cacert: {{ consul_cacert }}\n  cert: {{ consul_cert }}\n  key: {{ consul_key }}<\/code><\/pre>\n<h3>Consul-template<\/h3>\n<p>Teh\u00e1t, kiv\u00e1lasztottuk a t\u00e1rol\u00f3t a konfigur\u00e1ci\u00f3hoz. Most meg kell \u00e9rteni, hogy a PgBouncer hogyan fogja v\u00e1ltani a konfigur\u00e1ci\u00f3j\u00e1t, amikor a Patroni klaszterben vezet\u0151t v\u00e1lt. E k\u00e9rd\u00e9sre a dokument\u00e1ci\u00f3ban nincs v\u00e1lasz, mivel a PgBouncer m\u0171k\u00f6d\u00e9se nincs le\u00edrva.<\/p>\n<p>Megold\u00e1s keres\u00e9se k\u00f6zben tal\u00e1ltunk egy cikket (a c\u00edm\u00e9t sajnos nem tudom), amelyben azt \u00edrt\u00e1k, hogy a Consul-template nagyon seg\u00edtett a PgBouncer \u00e9s a Patroni \u00f6sszekapcsol\u00e1s\u00e1ban. Ez arra \u00f6szt\u00f6nz\u00f6tt minket, hogy kutassuk a Consul-template m\u0171k\u00f6d\u00e9s\u00e9t.<\/p>\n<p>Kider\u00fclt, hogy a Consul-template folyamatosan figyelemmel k\u00eds\u00e9ri a PostgreSQL klaszter konfigur\u00e1ci\u00f3j\u00e1t a Consul-ban. Amikor a vezet\u0151 v\u00e1lt, friss\u00edti a PgBouncer konfigur\u00e1ci\u00f3j\u00e1t \u00e9s parancsot k\u00fcld az \u00fajraind\u00edt\u00e1s\u00e1ra.<\/p>\n<p><img decoding=\"async\" style=\"display: block; margin: 0 auto;\" src=\"\/wp-content\/uploads\/2019\/06\/6cf92996a127bb6637ab81dc45fdd60a.png\" alt=\"Hib\u00e1tlan PostgreSQL klaszter + Patroni. Bevezet\u00e9si tapasztalatok.\" \/><\/p>\n<p>A template nagy el\u0151nye, hogy k\u00f3dk\u00e9nt van t\u00e1rolva, teh\u00e1t \u00faj shard hozz\u00e1ad\u00e1sakor elegend\u0151 egy \u00faj commitot v\u00e9grehajtani \u00e9s automatikusan friss\u00edteni a template-t, ezzel fenntartva az Infrastructure as Code elvet.<\/p>\n<h3>\u00daj architekt\u00fara Patroni-val<\/h3>\n<p>Ennek eredm\u00e9nyek\u00e9nt a k\u00f6vetkez\u0151 m\u0171k\u00f6d\u00e9si s\u00e9m\u00e1t kaptuk:<br \/>\n<img decoding=\"async\" style=\"display: block; margin: 0 auto;\" src=\"\/wp-content\/uploads\/2019\/06\/bf9a9eff675a26039e3f76b16c6cd713.png\" alt=\"Hib\u00e1tlan PostgreSQL klaszter + Patroni. Bevezet\u00e9si tapasztalatok.\" \/><\/p>\n<p>Minden alkalmaz\u00e1sszerver a terhel\u00e9seloszt\u00f3hoz fordul \u2192 m\u00f6g\u00f6tte k\u00e9t PgBouncer instance \u00e1ll \u2192 mindk\u00e9t instance-on a Consul-template fut, amely figyeli a Patroni klaszterek \u00e1llapot\u00e1t \u00e9s nyomon k\u00f6veti a PgBouncer konfigur\u00e1ci\u00f3 aktu\u00e1lis \u00e1llapot\u00e1t, amely a klaszterek aktu\u00e1lis vezet\u0151j\u00e9re ir\u00e1ny\u00edtja a k\u00e9r\u00e9seket.<\/p>\n<h3>K\u00e9zi tesztel\u00e9s<\/h3>\n<p>Ezt a s\u00e9m\u00e1t \u00e9les k\u00f6rnyezetbe val\u00f3 kihelyez\u00e9s el\u0151tt egy kis tesztk\u00f6rnyezetben futtattuk, \u00e9s ellen\u0151rizt\u00fck az automatikus v\u00e1lt\u00e1s m\u0171k\u00f6d\u00e9s\u00e9t. Megnyitottuk a t\u00e1bl\u00e1t, \u00e1thelyezt\u00fck a matric\u00e1t, \u00e9s ebben a pillanatban \u201emeg\u00f6lt\u00fck\u201d a klaszter vezet\u0151j\u00e9t. Az AWS-ben ehhez elegend\u0151 az instance le\u00e1ll\u00edt\u00e1sa a konzolon kereszt\u00fcl.<\/p>\n<p><img decoding=\"async\" style=\"display: block; margin: 0 auto;\" src=\"\/wp-content\/uploads\/2019\/06\/d670fe373b774f1b52bfd8a8c3b53a21.png\" alt=\"Hib\u00e1tlan PostgreSQL klaszter + Patroni. Bevezet\u00e9si tapasztalatok.\" \/><\/p>\n<p>A matrica 10-20 m\u00e1sodperc m\u00falva visszat\u00e9rt, majd \u00fajra elkezdte a norm\u00e1lis mozg\u00e1s\u00e1t. Ez azt jelenti, hogy a Patroni klaszter megfelel\u0151en m\u0171k\u00f6d\u00f6tt: v\u00e1ltotta a vezet\u0151t, elk\u00fcldte az inform\u00e1ci\u00f3t a Consulnak, \u00e9s a Consul-template azonnal \u00e1tvette ezt az inform\u00e1ci\u00f3t, friss\u00edtette a PgBouncer konfigur\u00e1ci\u00f3j\u00e1t \u00e9s parancsot k\u00fcld\u00f6tt a reload-ra.<\/p>\n<h2>Hogyan lehet t\u00fal\u00e9lni a nagy terhel\u00e9st \u00e9s meg\u0151rizni a minim\u00e1lis le\u00e1ll\u00e1st?<\/h2>\n<p>Minden nagyszer\u0171en m\u0171k\u00f6dik! De \u00faj k\u00e9rd\u00e9sek mer\u00fclnek fel: Hogyan m\u0171k\u00f6dik ez nagy terhel\u00e9s alatt? Hogyan lehet gyorsan \u00e9s biztons\u00e1gosan bevezetni mindent a produksi k\u00f6rnyezetbe?<\/p>\n<p>Az els\u0151 k\u00e9rd\u00e9sre a tesztk\u00f6rnyezet seg\u00edt v\u00e1laszolni, ahol terhel\u00e9ses tesztel\u00e9st v\u00e9gz\u00fcnk. Ez teljesen azonos a production k\u00f6rnyezettel architekt\u00far\u00e1j\u00e1ban, \u00e9s gener\u00e1lt tesztadatokkal rendelkezik, amelyek mennyis\u00e9g\u00fckben k\u00f6r\u00fclbel\u00fcl egyenl\u0151ek a productionnal. Egyszer\u0171en \u00fagy d\u00f6nt\u00fcnk, hogy 'meg\u00f6lj\u00fck' az egyik PostgreSQL mestert a teszt sor\u00e1n, \u00e9s megn\u00e9zz\u00fck, mi t\u00f6rt\u00e9nik. De ezt megel\u0151z\u0151en fontos ellen\u0151rizni az automatikus telep\u00edt\u00e9st, hiszen ezen a k\u00f6rnyezeten t\u00f6bb PostgreSQL shardunk van, \u00edgy nagyszer\u0171 tesztel\u00e9st kapunk a konfigur\u00e1ci\u00f3s szkriptek el\u0151tt a production k\u00f6rnyezethez.<\/p>\n<p>Mindk\u00e9t feladat ambici\u00f3zusan hangzik, de nek\u00fcnk PostgreSQL 9.6-unk van. Tal\u00e1n k\u00f6zvetlen\u00fcl az 11.2-re friss\u00edt\u00fcnk?<\/p>\n<p>\u00dagy d\u00f6nt\u00f6tt\u00fcnk, hogy ezt k\u00e9t l\u00e9p\u00e9sben v\u00e9gezz\u00fck: el\u0151sz\u00f6r friss\u00edtj\u00fck a verzi\u00f3t 11.2-re, majd elind\u00edtjuk a Patroni-t.<\/p>\n<h3>PostgreSQL friss\u00edt\u00e9se<\/h3>\n<p>A PostgreSQL verzi\u00f3 gyors friss\u00edt\u00e9s\u00e9hez a k\u00f6vetkez\u0151 opci\u00f3t kell haszn\u00e1lni: <b>-k<\/b>, amely lehet\u0151v\u00e9 teszi a hard linkek l\u00e9trehoz\u00e1s\u00e1t a lemezen, \u00edgy nincs sz\u00fcks\u00e9g az adataid m\u00e1sol\u00e1s\u00e1ra. A 300-400 GB-os adatb\u00e1zisok friss\u00edt\u00e9se 1 m\u00e1sodpercet vesz ig\u00e9nybe.<\/p>\n<p>Sok shardunk van, ez\u00e9rt a friss\u00edt\u00e9st automatikusan kell v\u00e9grehajtani. Ehhez \u00edrtunk egy Ansible playbookot, amely elv\u00e9gzi a teljes friss\u00edt\u00e9si folyamatot helyett\u00fcnk:<\/p>\n<pre><code class=\"plaintext\">\/usr\/lib\/postgresql\/11\/bin\/pg_upgrade \n&lt;b&gt;--link &lt;\/b&gt;\n--old-datadir=&#039;&#039; --new-datadir=&#039;&#039; \n --old-bindir=&#039;&#039;  --new-bindir=&#039;&#039; \n --old-options=&#039; -c config_file=&#039; \n --new-options=&#039; -c config_file=&#039;<\/code><\/pre>\n<p>Itt fontos megjegyezni, hogy a friss\u00edt\u00e9s megkezd\u00e9se el\u0151tt el kell v\u00e9gezni a friss\u00edt\u00e9st a k\u00f6vetkez\u0151 param\u00e9terrel: <b>\u2014check<\/b>, hogy biztosak legy\u00fcnk a friss\u00edt\u00e9s lehet\u0151s\u00e9g\u00e9ben. Emellett a szkriptek a friss\u00edt\u00e9s idej\u00e9re felcser\u00e9lik a konfigur\u00e1ci\u00f3s f\u00e1jlokat. A szkript\u00fcnk 30 m\u00e1sodperc alatt futott le, ami kiv\u00e1l\u00f3 eredm\u00e9ny.<\/p>\n<h3>Patroni ind\u00edt\u00e1sa<\/h3>\n<p>A m\u00e1sodik probl\u00e9ma megold\u00e1s\u00e1hoz elegend\u0151 r\u00e1tekinteni a Patroni konfigur\u00e1ci\u00f3j\u00e1ra. A hivatalos rep\u00f3ban van egy p\u00e9ldakonfigur\u00e1ci\u00f3 initdb-vel, amely a \u00faj adatb\u00e1zis inicializ\u00e1l\u00e1s\u00e1\u00e9rt felel\u0151s a Patroni els\u0151 ind\u00edt\u00e1sakor. De mivel m\u00e1r van egy k\u00e9sz adatb\u00e1zisunk, egyszer\u0171en elt\u00e1vol\u00edtottuk ezt a r\u00e9szt a konfigur\u00e1ci\u00f3b\u00f3l.<\/p>\n<p>Amikor elkezdt\u00fck a Patroni telep\u00edt\u00e9s\u00e9t egy megl\u00e9v\u0151 PostgreSQL klaszterre \u00e9s elind\u00edtottuk azt, \u00faj probl\u00e9m\u00e1val szembes\u00fclt\u00fcnk: mindk\u00e9t szerver vezet\u0151k\u00e9nt indult. A Patroni nem tud a klaszter kor\u00e1bbi \u00e1llapot\u00e1r\u00f3l, \u00e9s megpr\u00f3b\u00e1lja mindk\u00e9t szervert k\u00e9t k\u00fcl\u00f6n klaszterk\u00e9nt ind\u00edtani ugyanazzal a n\u00e9vvel. E probl\u00e9ma megold\u00e1s\u00e1hoz el kell t\u00e1vol\u00edtani az adatk\u00f6nyvt\u00e1rat a slave-en:<\/p>\n<pre><code class=\"plaintext\">rm -rf \/var\/lib\/postgresql\/<\/code><\/pre>\n<p><b>Ezt csak a slave-en sz\u00fcks\u00e9ges megtenni!<\/b><\/p>\n<p>A tiszta replik\u00e1hoz csatlakozva a Patroni a leader-b\u0151l egy basebackup-ot k\u00e9sz\u00edt, \u00e9s vissza\u00e1ll\u00edtja azt a replik\u00e1ra, majd a wal-napl\u00f3kon kereszt\u00fcl naprak\u00e9ssz\u00e9 teszi.<\/p>\n<p>Egy \u00fajabb neh\u00e9zs\u00e9g, amellyel szembes\u00fclt\u00fcnk, hogy az \u00f6sszes PostgreSQL klaszter alap\u00e9rtelmez\u00e9s szerint main n\u00e9ven ismert. Amikor minden klaszter nem tud a m\u00e1sikr\u00f3l, ez norm\u00e1lis. De amikor Patronit szeretn\u00e9l haszn\u00e1lni, akkor minden klaszternek egyedi n\u00e9vvel kell rendelkeznie. A megold\u00e1s az, hogy megv\u00e1ltoztatjuk a klaszter nev\u00e9t a PostgreSQL konfigur\u00e1ci\u00f3ban.<\/p>\n<h3>Terhel\u00e9si teszt<\/h3>\n<p>Futtattunk egy tesztet, amely szimul\u00e1lta a felhaszn\u00e1l\u00f3k munk\u00e1j\u00e1t a t\u00e1bl\u00e1kon. Amikor a terhel\u00e9s el\u00e9rte a napi \u00e1tlagunkat, pontosan ugyanazt a tesztet ism\u00e9telt\u00fck meg. Kih\u00faztunk egy p\u00e9ld\u00e1nyt a vezet\u0151 PostgreSQL-b\u0151l. Az automatikus failover \u00fagy m\u0171k\u00f6d\u00f6tt, ahogy azt v\u00e1rtuk: Patroni megv\u00e1ltoztatta a vezet\u0151t, a Consul-template friss\u00edtette a PgBouncer konfigur\u00e1ci\u00f3t \u00e9s kiadta a reload parancsot. Grafana grafikonjain l\u00e1that\u00f3 volt, hogy 20-30 m\u00e1sodperces k\u00e9s\u00e9sek \u00e9s egy kis mennyis\u00e9g\u0171 hiba l\u00e9pett fel a szerverekn\u00e9l, amelyek az adatb\u00e1zishoz val\u00f3 kapcsol\u00f3d\u00e1ssal voltak \u00f6sszef\u00fcgg\u00e9sben. Ez norm\u00e1lis helyzet, ilyen \u00e9rt\u00e9kek elfogadhat\u00f3k a failover\u00fcnkn\u00e9l, \u00e9s mindenk\u00e9ppen jobb, mint a szolg\u00e1ltat\u00e1s le\u00e1ll\u00e1sa.<\/p>\n<h2>Patroni bevezet\u00e9se a termel\u00e9sbe<\/h2>\n<p>\u00d6sszess\u00e9g\u00e9ben a k\u00f6vetkez\u0151 tervet dolgoztuk ki:<\/p>\n<ul>\n<li>A Consul-template telep\u00edt\u00e9se a PgBouncer szerverekre \u00e9s beind\u00edt\u00e1sa;<\/li>\n<li>A PostgreSQL friss\u00edt\u00e9se 11.2 verzi\u00f3ra;<\/li>\n<li>A klaszter nev\u00e9nek megv\u00e1ltoztat\u00e1sa;<\/li>\n<li>A Patroni klaszter ind\u00edt\u00e1sa.<\/li>\n<\/ul>\n<p>Ek\u00f6zben a s\u00e9m\u00e1nk lehet\u0151v\u00e9 teszi, hogy az els\u0151 pontot gyakorlatilag b\u00e1rmikor v\u00e9grehajtsuk, sorban elt\u00fcntethetj\u00fck minden PgBouncer-t, \u00e9s v\u00e9grehajthatjuk rajta a Consul-template telep\u00edt\u00e9st \u00e9s ind\u00edt\u00e1st. \u00cdgy is tett\u00fck.<\/p>\n<p>Gyors bevezet\u00e9shez Ansible-t haszn\u00e1ltunk, mivel az \u00f6sszes playbook-ot m\u00e1r tesztelt\u00fck a tesztk\u00f6rnyezetben, \u00e9s a teljes forgat\u00f3k\u00f6nyv v\u00e9grehajt\u00e1si ideje 1,5-2 perc volt minden shardra. Minden shard sz\u00e1m\u00e1ra egym\u00e1s ut\u00e1n ki tudtuk vezetni an\u00e9lk\u00fcl, hogy le kellett volna \u00e1ll\u00edtanunk a szolg\u00e1ltat\u00e1sunkat, de n\u00e9h\u00e1ny percre ki kellett volna kapcsolnunk minden PostgreSQL-t. Ebben az esetben azok a felhaszn\u00e1l\u00f3k, akiknek adatai ezen a shardon voltak, nem tudtak volna teljes m\u00e9rt\u00e9kben dolgozni ebben az id\u0151ben, ami sz\u00e1munkra elfogadhatatlan.<\/p>\n<p>A helyzet megold\u00e1sa a tervszer\u0171 karbantart\u00e1s lett, ami n\u00e1lunk h\u00e1romhavonta zajlik. Ez az id\u0151szak a tervezett munk\u00e1kra, amikor teljesen le\u00e1ll\u00edtjuk a szolg\u00e1ltat\u00e1sunkat \u00e9s friss\u00edtj\u00fck az adatb\u00e1zis p\u00e9ld\u00e1nyait. Egy h\u00e9t maradt a k\u00f6vetkez\u0151 karbantart\u00e1sig, \u00e9s \u00fagy d\u00f6nt\u00f6tt\u00fcnk, hogy egyszer\u0171en megv\u00e1rjuk \u00e9s tov\u00e1bbi el\u0151k\u00e9sz\u00fcleteket tesz\u00fcnk. A v\u00e1rakoz\u00e1s id\u0151szak\u00e1ban tov\u00e1bbi v\u00e9delmet \u00e9p\u00edtett\u00fcnk: minden PostgreSQL shard sz\u00e1m\u00e1ra egy kiv\u00e1lt\u00f3 m\u00e1solatot \u00e1ll\u00edtottunk be, hogy meg\u0151rizz\u00fck a legfrissebb adatokat, \u00e9s \u00faj p\u00e9ld\u00e1nyt adtunk hozz\u00e1 minden shardhoz, amely \u00faj replik\u00e1v\u00e1 v\u00e1lik a Patroni klaszterben, hogy ne kelljen az adatokat elt\u00e1vol\u00edt\u00f3 parancsot v\u00e9grehajtanunk. Mindez seg\u00edtett minim\u00e1lisra cs\u00f6kkenteni a hib\u00e1z\u00e1s kock\u00e1zat\u00e1t.<br \/>\n<img decoding=\"async\" style=\"display: block; margin: 0 auto;\" src=\"\/wp-content\/uploads\/2019\/06\/29e5c5f50dbfebfe5665fa0aeb009728.png\" alt=\"Hib\u00e1tlan PostgreSQL klaszter + Patroni. Bevezet\u00e9si tapasztalatok.\" \/><\/p>\n<p>\u00dajraind\u00edtottuk a szolg\u00e1ltat\u00e1sunkat, minden \u00fagy m\u0171k\u00f6d\u00f6tt, ahogy kellett, a felhaszn\u00e1l\u00f3k folytatt\u00e1k a munk\u00e1t, de a grafikonokon rendk\u00edv\u00fcl magas terhel\u00e9st \u00e9szlelt\u00fcnk a Consul szervereken.<br \/>\n<img decoding=\"async\" style=\"display: block; margin: 0 auto;\" src=\"\/wp-content\/uploads\/2019\/06\/af0eef9ac235706c0aac62d2e1ee179d.png\" alt=\"Hib\u00e1tlan PostgreSQL klaszter + Patroni. Bevezet\u00e9si tapasztalatok.\" \/><\/p>\n<p>Mi\u00e9rt nem \u00e9szlelt\u00fck ezt a tesztk\u00f6rnyezetben? Ez a probl\u00e9ma nagyon j\u00f3l szeml\u00e9lteti, hogy k\u00f6vetni kell az Infrastructure as code elvet, \u00e9s fejleszteni kell az eg\u00e9sz infrastrukt\u00far\u00e1t, kezdve a tesztk\u00f6rnyezetekt\u0151l eg\u00e9szen a production-ig. K\u00fcl\u00f6nben nagyon k\u00f6nnyen olyan probl\u00e9m\u00e1t kaphatunk, mint amit mi tapasztaltunk. Mi t\u00f6rt\u00e9nt? A Consul el\u0151sz\u00f6r a production-ben jelent meg, majd a tesztk\u00f6rnyezetekben, \u00edgy a tesztk\u00f6rnyezetekben a Consul verzi\u00f3ja magasabb volt, mint a production-ben. Egyik kiad\u00e1sban \u00e9ppen a consul-template haszn\u00e1lata k\u00f6zben fell\u00e9p\u0151 CPU sziv\u00e1rg\u00e1st jav\u00edtott\u00e1k ki. Ez\u00e9rt egyszer\u0171en friss\u00edtett\u00fck a Consult, \u00edgy megoldva a probl\u00e9m\u00e1t.<\/p>\n<h3>Patroni klaszter \u00fajraind\u00edt\u00e1sa<\/h3>\n<p>Azt\u00e1n \u00faj probl\u00e9m\u00e1val szembes\u00fclt\u00fcnk, amir\u0151l m\u00e9g csak nem is sejtett\u00fcnk. Amikor friss\u00edtj\u00fck a Consult, egyszer\u0171en elt\u00e1vol\u00edtjuk a Consul csom\u00f3pontot a klaszterb\u0151l a consul leave parancs v\u00e9grehajt\u00e1s\u00e1val \u2192 a Patroni csatlakozik egy m\u00e1sik Consul szerverhez \u2192 minden m\u0171k\u00f6dik. De amikor eljutottunk a Consul klaszter utols\u00f3 p\u00e9ld\u00e1ny\u00e1hoz \u00e9s elk\u00fcldt\u00fck neki a consul leave parancsot, az \u00f6sszes Patroni klaszter egyszer\u0171en \u00fajraindult, \u00e9s a napl\u00f3inkban a k\u00f6vetkez\u0151 hib\u00e1t l\u00e1ttuk:<\/p>\n<pre><code class=\"plaintext\">HIB&Aacute;ZAT: get_cluster\nNyomk&ouml;vet&eacute;s (a legutols&oacute; h&iacute;v&aacute;s legutols&oacute;):\n...\nRetryFailedError: &#039;T&uacute;ll&eacute;pte a pr&oacute;b&aacute;lkoz&aacute;s hat&aacute;ridej&eacute;t&#039;\nHIB&Aacute;ZAT: Hiba a DCS-sel val&oacute; kommunik&aacute;ci&oacute;ban\n&lt;b&gt;NAPL&Oacute;: az adatb&aacute;zis rendszer le&aacute;llt&lt;\/b&gt;<\/code><\/pre>\n<p>A Patroni klaszter nem tudta megszerezni a saj\u00e1t klaszter\u00e9r\u0151l az inform\u00e1ci\u00f3t, \u00e9s \u00fajraindult.<\/p>\n<p>A megold\u00e1s keres\u00e9se \u00e9rdek\u00e9ben felkerest\u00fck a Patroni szerz\u0151it egy issue-on a github-on. Javasolt\u00e1k a konfigur\u00e1ci\u00f3s f\u00e1jlaink jav\u00edt\u00e1s\u00e1t:<\/p>\n<pre><code class=\"python\">consul:\n consul.checks: []\nbootstrap:\n dcs:\n   retry_timeout: 8<\/code><\/pre>\n<p>Siker\u00fclt reproduk\u00e1lni a probl\u00e9m\u00e1t a tesztk\u00f6rnyezet\u00fcnkben, \u00e9s ott tesztelt\u00fck ezeket a param\u00e9tereket, de sajnos nem m\u0171k\u00f6dtek.<\/p>\n<p>A probl\u00e9ma tov\u00e1bbra is megoldatlan. Tervezett megold\u00e1si lehet\u0151s\u00e9geink a k\u00f6vetkez\u0151k:<\/p>\n<ul>\n<li>Haszn\u00e1ljunk Consul-\u00fcgyn\u00f6k\u00f6t a Patroni klaszter minden p\u00e9ld\u00e1ny\u00e1n;<\/li>\n<li>Jav\u00edtsuk ki a probl\u00e9m\u00e1t a k\u00f3dban.<\/li>\n<\/ul>\n<p>Meg\u00e9rtett\u00fck a hiba jelentkez\u00e9s\u00e9nek hely\u00e9t: val\u00f3sz\u00edn\u0171leg a probl\u00e9ma a default timeout haszn\u00e1lat\u00e1ban rejlik, amelyet nem lehet fel\u00fclb\u00edr\u00e1lni a konfigur\u00e1ci\u00f3s f\u00e1jlon kereszt\u00fcl. Amikor az utols\u00f3 Consul szerver elt\u00e1vol\u00edt\u00e1sra ker\u00fcl a klaszterb\u0151l, az eg\u00e9sz Consul-klaszter lefagy, ami t\u00f6bb mint egy m\u00e1sodpercig tart, emiatt a Patroni nem tudja lek\u00e9rdezni a klaszter \u00e1llapot\u00e1t, \u00e9s teljesen \u00fajraind\u00edtja az eg\u00e9sz klasztert.<\/p>\n<p>Szerencs\u00e9re tov\u00e1bbi hib\u00e1kat nem tapasztaltunk.<\/p>\n<h2>A Patroni haszn\u00e1lat\u00e1nak \u00f6sszegz\u00e9se<\/h2>\n<p>A Patroni sikeres ind\u00edt\u00e1sa ut\u00e1n egy extra replik\u00e1t adtunk hozz\u00e1 minden klaszterhez. Most minden klaszterben van egyfajta korm\u00e1nyz\u00e1s: egy vezet\u0151 \u00e9s k\u00e9t replik\u00e1t, hogy biztos\u00edtsuk a biztons\u00e1got split-brain eset\u00e9n a v\u00e1lt\u00e1s sor\u00e1n.<br \/>\n<img decoding=\"async\" style=\"display: block; margin: 0 auto;\" src=\"\/wp-content\/uploads\/2019\/06\/3bb4c0495fea274b04edd2e99b59eacb.png\" alt=\"Hib\u00e1tlan PostgreSQL klaszter + Patroni. Bevezet\u00e9si tapasztalatok.\" \/><\/p>\n<p>A produkci\u00f3s k\u00f6rnyezetben a Patroni m\u00e1r t\u00f6bb mint h\u00e1rom h\u00f3napja m\u0171k\u00f6dik. Ez id\u0151 alatt m\u00e1r t\u00f6bb alkalommal seg\u00edtett nek\u00fcnk. Nemr\u00e9g az AWS-en az egyik klaszter vezet\u0151je meghalt, az automatikus failover m\u0171k\u00f6d\u00e9sbe l\u00e9pett, \u00e9s a felhaszn\u00e1l\u00f3k folytathatt\u00e1k a munk\u00e1t. A Patroni bet\u00f6lt\u00f6tte a legfontosabb szerep\u00e9t.<\/p>\n<p><b>Kis \u00f6sszegz\u00e9s a Patroni haszn\u00e1lat\u00e1r\u00f3l:<\/b><\/p>\n<ul>\n<li>A konfigur\u00e1ci\u00f3 v\u00e1ltoztat\u00e1s\u00e1nak k\u00e9nyelme. Elegend\u0151 m\u00f3dos\u00edtani a konfigur\u00e1ci\u00f3t egy p\u00e9ld\u00e1nyon, \u00e9s az az eg\u00e9sz klaszterre \u00e9rv\u00e9nyes lesz. Ha az \u00faj konfigur\u00e1ci\u00f3 alkalmaz\u00e1s\u00e1hoz \u00fajraind\u00edt\u00e1s sz\u00fcks\u00e9ges, akkor a Patroni \u00e9rtes\u00edt r\u00f3la. A Patroni egyszeri parancs seg\u00edts\u00e9g\u00e9vel k\u00e9pes \u00fajraind\u00edtani az eg\u00e9sz klasztert, ami szint\u00e9n nagyon k\u00e9nyelmes.<\/li>\n<li>Az automatikus failover m\u0171k\u00f6dik, \u00e9s m\u00e1r seg\u00edtett nek\u00fcnk.<\/li>\n<li>A PostgreSQL friss\u00edt\u00e9se alkalmaz\u00e1s le\u00e1ll\u00e1sa n\u00e9lk\u00fcl. El\u0151sz\u00f6r a replik\u00e1kat kell friss\u00edteni az \u00faj verzi\u00f3ra, majd meg kell v\u00e1ltoztatni a vezet\u0151t a Patroni klaszterben, \u00e9s friss\u00edteni a r\u00e9gi vezet\u0151t. Ekkor elv\u00e9gezz\u00fck az automatikus failover tesztel\u00e9s\u00e9t is.<\/li>\n<\/ul>\n<p>Forr\u00e1s: <a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/miro\/blog\/457326\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0434\u043e\u0448\u043b\u0438 \u043a \u0432\u043e\u043f\u0440\u043e\u0441\u0443 \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 PostgreSQL, \u043f\u043e\u0447\u0435\u043c\u0443 \u044d\u0442\u043e \u0441\u0442\u0430\u043b\u043e \u0434\u043b\u044f \u043d\u0430\u0441 \u0432\u0430\u0436\u043d\u043e \u0438 \u0447\u0442\u043e \u0432 \u0438\u0442\u043e\u0433\u0435 \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c. \u0423 \u043d\u0430\u0441 \u0432\u044b\u0441\u043e\u043a\u043e\u043d\u0430\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u044b\u0439 \u0441\u0435\u0440\u0432\u0438\u0441: 2,5 \u043c\u043b\u043d \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443, 50\u041a+ \u0430\u043a\u0442\u0438\u0432\u043d\u044b\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u043a\u0430\u0436\u0434\u044b\u0439 \u0434\u0435\u043d\u044c. \u0421\u0435\u0440\u0432\u0435\u0440\u0430 \u043d\u0430\u0445\u043e\u0434\u044f\u0442\u0441\u044f \u0432 Amazone \u0432 \u043e\u0434\u043d\u043e\u043c \u0440\u0435\u0433\u0438\u043e\u043d\u0435 \u0418\u0440\u043b\u0430\u043d\u0434\u0438\u0438: \u0432 \u0440\u0430\u0431\u043e\u0442\u0435 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e 100+ \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432, \u0438\u0437 \u043d\u0438\u0445 \u043f\u043e\u0447\u0442\u0438 50 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26749,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35706","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0434\u043e\u0448\u043b\u0438 \u043a \u0432\u043e\u043f\u0440\u043e\u0441\u0443 \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 PostgreSQL, \u043f\u043e\u0447\u0435\u043c\u0443 \u044d\u0442\u043e \u0441\u0442\u0430\u043b\u043e \u0434\u043b\u044f \u043d\u0430\u0441 \u0432\u0430\u0436\u043d\u043e \u0438 \u0447\u0442\u043e \u0432 \u0438\u0442\u043e\u0433\u0435 \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/otkazoustojchivyj-klaster-postgresql-patroni-opyt-vnedreniya\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"hu_HU\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u044b\u0439 \u043a\u043b\u0430\u0441\u0442\u0435\u0440 PostgreSQL + Patroni. \u041e\u043f\u044b\u0442 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u044f | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0434\u043e\u0448\u043b\u0438 \u043a \u0432\u043e\u043f\u0440\u043e\u0441\u0443 \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 PostgreSQL, \u043f\u043e\u0447\u0435\u043c\u0443 \u044d\u0442\u043e \u0441\u0442\u0430\u043b\u043e \u0434\u043b\u044f \u043d\u0430\u0441 \u0432\u0430\u0436\u043d\u043e \u0438 \u0447\u0442\u043e \u0432 \u0438\u0442\u043e\u0433\u0435 \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/otkazoustojchivyj-klaster-postgresql-patroni-opyt-vnedreniya\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:05:50+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2026-05-18T18:58:46+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Hibat\u0171r\u0151 PostgreSQL klaszter + Patroni. Bevezet\u00e9si tapasztalat | ProHoster","description":"A cikkben bemutatom, hogyan k\u00f6zel\u00edtett\u00fck meg a PostgreSQL redundanci\u00e1j\u00e1nak k\u00e9rd\u00e9s\u00e9t, mi\u00e9rt v\u00e1lt ez sz\u00e1munkra fontoss\u00e1, \u00e9s mi lett az eredm\u00e9nye.","canonical_url":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/otkazoustojchivyj-klaster-postgresql-patroni-opyt-vnedreniya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hu_HU","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u044b\u0439 \u043a\u043b\u0430\u0441\u0442\u0435\u0440 PostgreSQL + Patroni. \u041e\u043f\u044b\u0442 \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u044f | ProHoster","og:description":"\u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0434\u043e\u0448\u043b\u0438 \u043a \u0432\u043e\u043f\u0440\u043e\u0441\u0443 \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 PostgreSQL, \u043f\u043e\u0447\u0435\u043c\u0443 \u044d\u0442\u043e \u0441\u0442\u0430\u043b\u043e \u0434\u043b\u044f \u043d\u0430\u0441 \u0432\u0430\u0436\u043d\u043e \u0438 \u0447\u0442\u043e \u0432 \u0438\u0442\u043e\u0433\u0435 \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c.","og:url":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/otkazoustojchivyj-klaster-postgresql-patroni-opyt-vnedreniya","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:05:50+00:00","article:modified_time":"2026-05-18T18:58:46+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35706","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 00:26:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 13:51:06","updated":"2026-01-22 00:26:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/35706","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/comments?post=35706"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/35706\/revisions"}],"predecessor-version":[{"id":172654,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/35706\/revisions\/172654"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media\/26749"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media?parent=35706"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/categories?post=35706"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/tags?post=35706"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}