{"id":30356,"date":"2019-10-31T21:35:06","date_gmt":"2019-10-31T18:35:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql\/"},"modified":"2019-10-31T21:35:06","modified_gmt":"2019-10-31T18:35:06","slug":"kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","title":{"rendered":"Kako smo koristili odlo\u017eenu replicaciju za oporavak od katastrofe s PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kako
\nReplikacija nije backup. Ili mo\u017eda jeste? Evo kako smo koristili odlo\u017eenu replikaciju za oporavak nakon \u0161to smo slu\u010dajno obrisali pre\u010dace.<\/p>\n

<\/p>\n

Stru\u010dnjaci za infrastrukturu<\/a><\/noindex> na GitLabu odgovaraju za rad GitLab.com<\/a><\/noindex> \u2013 najve\u0107eg GitLab instance ikada. Ovdje se nalazi 3 miliona korisnika i gotovo 7 miliona projekata, i to je jedan od najve\u0107ih open-source SaaS sa specijaliziranom arhitekturom. Bez sustava baza podataka PostgreSQL, infrastruktura GitLab.com ne bi daleko dogurala, a sve \u0161to radimo za otpornost na kvarove kada mo\u017eemo izgubiti podatke. Vjerojatno se takva katastrofa ne\u0107e dogoditi, ali smo se dobro pripremili i opskrbili raznim mehanizmima backup-a i replikacije.<\/p>\n

<\/p>\n

Replikacija nije na\u010din za backup baza podataka (vidi dolje<\/a><\/noindex>). No, sada \u0107emo vidjeti kako brzo obnoviti slu\u010dajno obrisane podatke pomo\u0107u odlo\u017eene replikacije: na GitLab.com<\/a><\/noindex> korisnik izbrisao pre\u010dac<\/a><\/noindex> za projekt gitlab-ce<\/code><\/a><\/noindex> i izgubio vezu s merge requestovima i zadacima.<\/p>\n

<\/p>\n

Sa odlo\u017eenom replikom obnovili smo podatke u svega 1,5 sata. Pogledajte kako je to bilo.<\/p>\n

<\/a><\/noindex><\/p>\n

Obnova na odre\u0111eno vrijeme s PostgreSQL<\/h3>\n

<\/p>\n

PostgreSQL ima ugra\u0111enu funkciju koja obnavlja stanje baze podataka na odre\u0111eni trenutak. Zove se Point-in-Time Recovery<\/a><\/noindex> (PITR) i koristi iste mehanizme koji podr\u017eavaju a\u017eurnost replike: zapo\u010dinjemo s pouzdanim snimkom cijelog klastera baza podataka (osnovni backup), a zatim primjenjujemo niz promjena stanja do odre\u0111enog trenutka.<\/p>\n

<\/p>\n

Kako bismo koristili ovu funkciju za hladni backup, redovito radimo osnovni backup baze podataka i pohranjujemo ga u arhivu (arhive GitLab-a \u017eive u Google Cloud Storage<\/a><\/noindex>). Osim toga, pratimo promjene stanja baze podataka, arhiviraju\u0107i zapisni dnevnik (write-ahead log<\/a><\/noindex>, WAL). I sa svime ovim mo\u017eemo izvesti PITR za hitnu obnovu: po\u010dinjemo od snimka napravljenog prije gre\u0161ke i primjenjujemo promjene iz WAL arhive do kvara.<\/p>\n

<\/p>\n

\u0160to je odlo\u017eena replikacija?<\/h3>\n

<\/p>\n

Odlo\u017eena replikacija je primjena promjena iz WAL-a s odgodom. Drugim rije\u010dima, transakcija se dogodila u satu X<\/code>, ali u replici \u0107e se pojaviti s odgodom d<\/code> za sat X + d<\/code>.<\/p>\n

<\/p>\n

U PostgreSQL-u postoje 2 na\u010dina za postavljanje fizi\u010dke replike baze podataka: obnova iz arhive i streaming replikacija. Obnova iz arhive<\/a><\/noindex>, u biti, radi kao PITR, ali neprekidno: stalno izvla\u010dimo promjene iz WAL arhive i primjenjujemo ih na repliku. A streaming replikacija<\/a><\/noindex> direktno izvla\u010di WAL tok s vi\u0161eg hosta baze podataka. Preferiramo obnavljanje iz arhive - njima je lak\u0161e upravljati i imaju normalne performanse, koje ne zaostaju za radnim klastra.<\/p>\n

<\/p>\n

Kako postaviti odgo\u0111eno obnavljanje iz arhive<\/h3>\n

<\/p>\n

Opcije obnove<\/a><\/noindex> opisane su u datoteci recovery.conf<\/code>. Primjer:<\/p>\n

<\/p>\n

standby_mode = 'on'\nrestore_command = ' \/usr\/bin\/envdir \/etc\/wal-e.d\/env \/opt\/wal-e\/bin\/wal-e wal-fetch -p 4 \"%f\" \"%p\"'\nrecovery_min_apply_delay = '8h'\nrecovery_target_timeline = 'latest'<\/code><\/pre>\n
<\/p>\n
S ovim parametrima postavili smo odgo\u0111enu repliku s obnavljanjem iz arhive. Ovdje se koristi wal-e<\/a><\/noindex> za va\u0111enje WAL segmenata (restore_command<\/code>) iz arhive, a promjene \u0107e se primjenjivati nakon osam sati (recovery_min_apply_delay<\/code>). Replika \u0107e pratiti promjene vremenskog okvira u arhivi, na primjer, zbog obrade otkaza u klasteru (recovery_target_timeline<\/code>).<\/p>\n
<\/p>\n
S recovery_min_apply_delay<\/code> mo\u017ee se postaviti streaming replikacija sa zaka\u0161njenjem, ali ovdje postoje neki trikovi koji se odnose na replika\u017ene slotove, povratne informacije s vru\u0107ih rezervi itd. WAL arhiva omogu\u0107uje izbjegavanje tih problema.<\/p>\n
<\/p>\n
Parametar recovery_min_apply_delay<\/code> pojavio se samo u PostgreSQL 9.3. U prethodnim verzijama za odgo\u0111enu replikaciju trebate postaviti kombinaciju funkcija upravljanja oporavkom<\/a><\/noindex> (pg_xlog_replay_pause(), pg_xlog_replay_resume()<\/code>) ili zadr\u017eati WAL segmente u arhivi tijekom zadr\u0161ke.<\/p>\n
<\/p>\n
Kako to PostgreSQL radi?<\/h3>\n
<\/p>\n
Zanimljivo je vidjeti kako PostgreSQL implementira odgo\u0111eno obnavljanje. Pogledajmo na recoveryApplyDelay(XlogReaderState)<\/code><\/a><\/noindex>. Poziva se iz glavnog kruga ponavljanja<\/a><\/noindex> za svaki zapis iz WAL.<\/p>\n
<\/p>\n
static bool\nrecoveryApplyDelay(XLogReaderState *record)\n{\n    uint8       xact_info;\n    TimestampTz xtime;\n    long        secs;\n    int         microsecs;\n\n    \/* nothing to do if no delay configured *\/\n    if (recovery_min_apply_delay <= 0)\n        return false;\n\n    \/* no delay is applied on a database not yet consistent *\/\n    if (!reachedConsistency)\n        return false;\n\n    \/*\n     * Is it a COMMIT record?\n     *\n     * We deliberately choose not to delay aborts since they have no effect on\n     * MVCC. We already allow replay of records that don't have a timestamp,\n     * so there is already opportunity for issues caused by early conflicts on\n     * standbys.\n     *\/\n    if (XLogRecGetRmid(record) != RM_XACT_ID)\n        return false;\n\n    xact_info = XLogRecGetInfo(record) & XLOG_XACT_OPMASK;\n\n    if (xact_info != XLOG_XACT_COMMIT &&\n        xact_info != XLOG_XACT_COMMIT_PREPARED)\n        return false;\n\n    if (!getRecordTimestamp(record, &xtime))\n        return false;\n\n    recoveryDelayUntilTime =\n        TimestampTzPlusMilliseconds(xtime, recovery_min_apply_delay);\n\n    \/*\n     * Exit without arming the latch if it's already past time to apply this\n     * record\n     *\/\n    TimestampDifference(GetCurrentTimestamp(), recoveryDelayUntilTime,\n                        &secs, &microsecs);\n    if (secs <= 0 && microsecs <= 0)\n        return false;\n\n    while (true)\n    {\n        \/\/ Shortened:\n        \/\/ Use WaitLatch until we reached recoveryDelayUntilTime\n        \/\/ and then\n        break;\n    }\n    return true;\n}<\/code><\/pre>\n
<\/p>\n
Bitno je da je odgoda temeljena na fizi\u010dkom vremenu zabilje\u017eenom u vremenskoj oznaci komita transakcije (xtime<\/code>). Kao \u0161to je vidljivo, odgoda se primjenjuje samo na komite i ne doti\u010de druge zapise \u2014 sve promjene se primjenjuju izravno, a komit se odga\u0111a, tako da \u0107emo vidjeti promjene tek nakon postavljene odgode.<\/p>\n
<\/p>\n
Kako koristiti odgo\u0111enu replicu za oporavak podataka<\/h3>\n
<\/p>\n
Pretpostavimo da imamo klaster baze podataka u produkciji i replicu s osmosatnom odgodom. Pogledajmo kako oporaviti podatke na primjeru nasumi\u010dnog brisanja oznaka<\/a><\/noindex>.<\/p>\n
<\/p>\n
Kada smo saznali za problem, zaustavili smo obnovu iz arhiva<\/a><\/noindex> za odgo\u0111enu replicu:<\/p>\n
<\/p>\n
SELECT pg_xlog_replay_pause();<\/code><\/pre>\n
<\/p>\n
S pauzom nismo imali rizika da \u0107e replika ponoviti zahtjev DELETE<\/code>. Korisna stvar, ako treba vremena da se sve razjasni.<\/p>\n
<\/p>\n
Bitno je da odgo\u0111ena replika do\u0111e do trenutka prije zahtjeva. DELETE<\/code>Otprilike smo znali fizi\u010dko vrijeme brisanja. Izbrisali smo recovery_min_apply_delay<\/code> i dodali recovery_target_time<\/code> u recovery.conf<\/code>. Tako replika dolazi do potrebnog trenutka bez odgoda:<\/p>\n
<\/p>\n
recovery_target_time = '2018-10-12 09:25:00+00'<\/code><\/pre>\n
<\/p>\n
S vremenskim oznakama bolje je smanjiti suvi\u0161no kako bismo izbjegli proma\u0161aj. Istina, \u0161to vi\u0161e smanjujemo, to vi\u0161e podataka gubimo. Opet, ako prokockamo zahtjev, DELETE<\/code>sve \u0107e ponovno biti obrisano i morat \u0107emo po\u010deti iznova (ili uop\u0107e uzeti hladnu sigurnosnu kopiju za PITR).<\/p>\n
<\/p>\n
Ponovo smo pokrenuli odlo\u017eeni Postgres instancu, a WAL segmenti su se ponavljali do navedenog vremena. Napredak u ovoj fazi mo\u017ee se pratiti upitom:<\/p>\n
<\/p>\n
SELECT\n  -- trenutna lokacija u WAL\n  pg_last_xlog_replay_location(),\n  -- trenutni vremenski pe\u010dat transakcije (stanje replike)\n  pg_last_xact_replay_timestamp(),\n  -- trenutno fizi\u010dko vrijeme\n  now(),\n  -- koli\u010dina vremena koja jo\u0161 treba biti primenjena do postizanja recovery_target_time\n  '2018-10-12 09:25:00+00'::timestamptz - pg_last_xact_replay_timestamp() as delay;<\/code><\/pre>\n
<\/p>\n
Ako se vremenska oznaka vi\u0161e ne menja, obnova je zavr\u0161ena. Mo\u017eete postaviti akciju recovery_target_action<\/code><\/a><\/noindex>, da se zatvori, unapredi ili pauzira instanca nakon ponavljanja (po defaultu se pauzira).<\/p>\n
<\/p>\n
Baza podataka se vratila u stanje pre tog nesretnog upita. Sada je mogu\u0107e, na primer, izvesti podatke. Izvezli smo uklonjene podatke o oznakama i sve veze s zadacima i merge zahtevima i preneli ih u radnu bazu podataka. Ako su gubici veliki, mo\u017eemo jednostavno unaprediti replikaciju i koristiti je kao glavnu. Ali tada \u0107e svi podaci nakon trenutka do kojeg smo se vratili biti izgubljeni.<\/p>\n
<\/p>\n
Umesto vremenskih oznaka, bolje je koristiti ID transakcija. Korisno je zabele\u017eiti ove ID, na primer, za DDL operatore (tipa DROP TABLE<\/code>), pomo\u0107u log_statements = 'ddl'<\/code>. Da smo imali ID transakcije, uzeli bismo recovery_target_xid<\/code> i izvr\u0161ili sve do transakcije pre upita DELETE<\/code>.<\/p>\n
<\/p>\n
Povratak na rad je vrlo jednostavan: uklonite sve promene iz recovery.conf<\/code> i ponovo pokrenite Postgres. Ubrzo \u0107e se na replici ponovo pojaviti osmo\u010dasovno ka\u0161njenje, i spremni smo za budu\u0107e nevolje.<\/p>\n
<\/p>\n
Prednosti za oporavak<\/h3>\n
<\/p>\n
Sa odlo\u017eenom replikom umesto hladnog backupa ne treba nam sate za obnavljanje celog snimka iz arhive. Na primer, treba nam pet sati da izvu\u010demo celi osnovni backup od 2 TB. A zatim \u0107emo jo\u0161 morati primeniti celu dnevnu WAL, da bismo se oporavili do potrebnog stanja (u najgorem slu\u010daju).<\/p>\n
<\/p>\n
Odlo\u017eena replika je bolja od hladnog backupa iz dva razloga:<\/p>\n
<\/p>\n
    \n
  1. Nije potrebno izvla\u010diti ceo osnovni backup iz arhive.<\/li>\n
  2. Postoji fiksno osmo\u010dasovno okno WAL segmenata koje treba ponoviti.<\/li>\n<\/ol>\n
    <\/p>\n
    Osim toga, stalno proveravamo mo\u017ee li se PITR obaviti iz WAL, i brzo bismo primetili o\u0161te\u0107enja ili druge probleme s arhivom WAL, prate\u0107i ka\u0161njenje odlo\u017eene replike.<\/p>\n
    <\/p>\n
    U ovom primeru je trebalo 50 minuta za oporavak, \u0161to zna\u010di da je brzina bila 110 GB podataka WAL po satu (arhiv je tada i dalje bio na AWS S3<\/a><\/noindex>). Sveukupno smo rije\u0161ili problem i povratili podatke u 1,5 sati.<\/p>\n
    <\/p>\n
    Zaklju\u010dci: gdje \u0107e se koristiti odgo\u0111ena replikacija (a gdje ne)<\/h3>\n
    <\/p>\n
    Koristite odgo\u0111enu replikaciju kao sredstvo prve pomo\u0107i ako slu\u010dajno izgubite podatke i primijetite ovu nesre\u0107u unutar postavljene ka\u0161njenja.<\/p>\n
    <\/p>\n
    Ali imajte na umu: replikacija nije backup.<\/p><\/blockquote>\n
    Backup i replikacija imaju razli\u010dite ciljeve. Hladni backup \u0107e biti koristan ako ste slu\u010dajno napravili DELETE<\/code> ili DROP TABLE<\/code>. Radimo backup iz hladnog skladi\u0161ta i obnavljamo prethodno stanje tablice ili cijele baze podataka. Me\u0111utim, upit DROP TABLE<\/code> se gotovo trenutno reproducira na svim replikama u radnom klasteru, tako da \u0107e uobi\u010dajena replikacija ovdje pomo\u0107i. Sama po sebi replikacija odr\u017eava bazu podataka dostupnom kada pojedini serveri otkazuju i raspore\u0111uje optere\u0107enje.<\/p>\n
    <\/p>\n
    \u010cak i s odgo\u0111enom replikom, ponekad jako trebamo hladni backup na sigurnom mjestu ako se dogodi kvar datacentra, skriveno o\u0161te\u0107enje ili drugi doga\u0111aji koje odmah ne primijetite. Ovdje od same replikacije nema koristi.<\/p>\n
    <\/p>\n
    Napomena<\/strong>. Na GitLab.com<\/a><\/noindex> sada \u0161titimo od gubitka podataka samo na razini sustava i ne obnavljamo podatke na razini korisnika.<\/p>\n
    Izvor: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
    \u0420\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044f \u2014 \u043d\u0435 \u0431\u044d\u043a\u0430\u043f. \u0418\u043b\u0438 \u043d\u0435\u0442? \u0412\u043e\u0442 \u043a\u0430\u043a \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043b\u0438 \u043e\u0442\u043b\u043e\u0436\u0435\u043d\u043d\u0443\u044e \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044e \u0434\u043b\u044f \u0432\u043e\u0441\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u044f, \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u043e \u0443\u0434\u0430\u043b\u0438\u0432 \u044f\u0440\u043b\u044b\u043a\u0438. \u0421\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u044b \u043f\u043e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0435 \u043d\u0430 GitLab \u043e\u0442\u0432\u0435\u0447\u0430\u044e\u0442 \u0437\u0430 \u0440\u0430\u0431\u043e\u0442\u0443 GitLab.com \u2014 \u0441\u0430\u043c\u043e\u0433\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u044d\u043a\u0437\u0435\u043c\u043f\u043b\u044f\u0440\u0430 GitLab \u0432 \u043f\u0440\u0438\u0440\u043e\u0434\u0435. \u0417\u0434\u0435\u0441\u044c 3 \u043c\u0438\u043b\u043b\u0438\u043e\u043d\u0430 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0438 \u043f\u043e\u0447\u0442\u0438 7 \u043c\u0438\u043b\u043b\u0438\u043e\u043d\u043e\u0432 \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0438 \u044d\u0442\u043e \u043e\u0434\u0438\u043d \u0438\u0437 \u0441\u0430\u043c\u044b\u0445 \u043a\u0440\u0443\u043f\u043d\u044b\u0445 \u043e\u043f\u0435\u043d\u0441\u043e\u0440\u0441-\u0441\u0430\u0439\u0442\u043e\u0432 SaaS \u0441 \u0432\u044b\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u043e\u0439. \u0411\u0435\u0437 \u0441\u0438\u0441\u0442\u0435\u043c\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":22360,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-30356","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Kako smo koristili odgo\u0111enu replikaciju za hitno obnavljanje s PostgreSQL | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\u041a\u0430\u043a \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043b\u0438 \u043e\u0442\u043b\u043e\u0436\u0435\u043d\u043d\u0443\u044e \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044e \u0434\u043b\u044f \u0430\u0432\u0430\u0440\u0438\u0439\u043d\u043e\u0433\u043e \u0432\u043e\u0441\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u044f \u0441 PostgreSQL | ProHoster","og:description":".","og:url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","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-31T18:35:06+00:00","article:modified_time":"2019-10-31T18:35:06+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"30356","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-21 00:50:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:48:29","updated":"2026-01-21 00:50:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/30356","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=30356"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/30356\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/22360"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=30356"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=30356"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=30356"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}