{"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\/nl\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","title":{"rendered":"Hoe we uitgestelde replicatie hebben gebruikt voor noodherstel met PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hoe
\nReplicatie is geen backup. Of toch? Zo hebben we uitgestelde replicatie gebruikt voor herstel nadat we per ongeluk snelkoppelingen hebben verwijderd.<\/p>\n

<\/p>\n

Infrastructuurspecialisten<\/a><\/noindex> bij GitLab zijn verantwoordelijk voor de werking GitLab.com<\/a><\/noindex> van de grootste GitLab-instantie ter wereld. Hier zijn 3 miljoen gebruikers en bijna 7 miljoen projecten, en dit is een van de grootste open-source SaaS-websites met een gedediceerde architectuur. Zonder PostgreSQL-databasesysteem kan GitLab.com niet ver komen, en wat we ook doen voor fouttolerantie in geval van storingen waarbij gegevens verloren kunnen gaan. Het is onwaarschijnlijk dat zo'n ramp zich zal voordoen, maar we zijn goed voorbereid en hebben verschillende mechanismen voor backups en replicatie.<\/p>\n

<\/p>\n

Replicatie is geen middel voor databasbackup (zie hieronder<\/a><\/noindex>). Maar nu zullen we zien hoe we per ongeluk verwijderde gegevens snel kunnen herstellen met behulp van uitgestelde replicatie: op GitLab.com<\/a><\/noindex> gebruiker verwijderde ik een snelkoppeling<\/a><\/noindex> voor het project gitlab-ce<\/code><\/a><\/noindex> en verloor de aansluiting met merge-verzoeken en taken.<\/p>\n

<\/p>\n

Met de uitgestelde replica hebben we de gegevens in slechts 1,5 uur hersteld. Kijk hoe we dat deden.<\/p>\n

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

Herstel naar een specifiek tijdstip met PostgreSQL<\/h3>\n

<\/p>\n

PostgreSQL heeft een ingebouwde functie die de status van de database op een bepaald tijdstip herstelt. Deze wordt Point-in-Time Recovery<\/a><\/noindex> (PITR) genoemd en maakt gebruik van dezelfde mechanismen die de actualiteit van de replica ondersteunen: beginnend met een betrouwbare snapshot van de hele databasecluster (basisbackup), passen we een reeks statuswijzigingen toe tot een bepaald tijdstip.<\/p>\n

<\/p>\n

Om deze functie te gebruiken voor koude backups, maken we regelmatig een basisbackup van de database en slaan deze op in een archief (archieven van GitLab leven in de Google Cloud Storage<\/a><\/noindex>). We volgen ook de wijzigingen in de status van de database door het archiveren van de write-ahead log (write-ahead log<\/a><\/noindex>, WAL). Met dit alles kunnen we PITR uitvoeren voor noodherstel: we beginnen met een snapshot dat v\u00f3\u00f3r de fout is gemaakt en passen de wijzigingen uit het WAL-archief toe tot aan de storing.<\/p>\n

<\/p>\n

Wat is uitgestelde replicatie?<\/h3>\n

<\/p>\n

Uitgestelde replicatie is het toepassen van wijzigingen uit WAL met een vertraging. Dat wil zeggen, de transactie vond plaats om 1 uur, X<\/code>maar in de replica verschijnt deze met een vertraging We verwijderen de huidige partitie om een nieuwe aan te maken voor in totaal 50 GB.<\/code> van 1 uur X + d<\/code>.<\/p>\n

<\/p>\n

In PostgreSQL zijn er 2 manieren om een fysieke database-replica in te stellen: herstel vanuit archief en streamingreplicatie. Herstel uit archief<\/a><\/noindex>, in wezen, werkt als PITR, maar continu: we extraheren constant wijzigingen uit het WAL-archief en passen deze toe op de replica. A streamingreplicatie<\/a><\/noindex> haalt rechtstreeks de WAL-stroom van de bovenliggende databasehost. We geven de voorkeur aan herstel uit het archief \u2014 dit is eenvoudiger te beheren en heeft een normale prestatie die niet achterblijft bij het actieve cluster.<\/p>\n

<\/p>\n

Hoe uitgestelde herstel uit het archief in te stellen<\/h3>\n

<\/p>\n

Herstelopties<\/a><\/noindex> worden beschreven in het bestand recovery.conf<\/code>. Voorbeeld:<\/p>\n

<\/p>\n

standby_mode = 'on'\nrestore_command = '\u200d\/usr\/bin\/envdir \/etc\/wal-e.d\/env \/opt\/wal-e\/bin\/wal-e wal-fetch -p 4 \"%f\" \"%p\"'\nrecovery_min_apply_delay = '8u'\nrecovery_target_timeline = 'latest'<\/code><\/pre>\n
<\/p>\n
Met deze parameters hebben we een uitgestelde replica ingesteld met herstel uit het archief. Hier wordt wal-e<\/a><\/noindex> gebruikt om segmenten WAL te extraheren (restore_command<\/code>) uit het archief, en wijzigingen worden na acht uur toegepast (recovery_min_apply_delay<\/code>). De replica zal wijzigingen in de tijdlijn in het archief volgen, bijvoorbeeld door een failover in het cluster (recovery_target_timeline<\/code>).<\/p>\n
<\/p>\n
met recovery_min_apply_delay<\/code> kan streamingreplicatie met vertraging worden ingesteld, maar er zijn enkele valkuilen die verband houden met replicatiesloten, backpressure en dergelijke. Het WAL-archief stelt ons in staat om deze te vermijden.<\/p>\n
<\/p>\n
Parameter recovery_min_apply_delay<\/code> is alleen beschikbaar in PostgreSQL 9.3. In eerdere versies moest voor uitgestelde replicatie een combinatie worden ingesteld van herstelbeheerfuncties<\/a><\/noindex> (pg_xlog_replay_pause(), pg_xlog_replay_resume()<\/code>) of segments WAL in het archief houden tijdens de vertraging.<\/p>\n
<\/p>\n
Hoe doet PostgreSQL dit?<\/h3>\n
<\/p>\n
Het is interessant om te zien hoe PostgreSQL uitgesteld herstel implementeert. Laten we kijken naar recoveryApplyDelay(XlogReaderState)<\/code><\/a><\/noindex>. Dit wordt aangeroepen vanuit de hoofdherhalingslus<\/a><\/noindex> voor elke invoer uit 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    \/* niets te doen als er geen vertraging is geconfigureerd *\/\n    if (recovery_min_apply_delay <= 0)\n        return false;\n\n    \/* er wordt geen vertraging toegepast op een database die nog niet consistent is *\/\n    if (!reachedConsistency)\n        return false;\n\n    \/*\n     * Is dit een COMMIT-record?\n     *\n     * We kiezen er opzettelijk voor om abortussen niet te vertragen, omdat ze geen effect hebben op\n     * MVCC. We staan al replay toe van records zonder een timestamp,\n     * er is dus al kans op problemen door vroege conflicten op\n     * standby.<\/code><\/pre>\n
<\/p>\n
Het punt is dat de vertraging gebaseerd is op de fysieke tijd vastgelegd in de timestamp van de transactieverplichting (xtime<\/code>). Zoals te zien is, wordt de vertraging alleen toegepast op commits en raakt het andere records niet \u2014 alle wijzigingen worden direct toegepast, terwijl de commit wordt uitgesteld, dus we zien de wijzigingen pas na de ingestelde vertraging.<\/p>\n
<\/p>\n
Hoe een vertraagde replica te gebruiken voor gegevensherstel<\/h3>\n
<\/p>\n
Stel, we hebben een productie-databasecluster en een replica met een vertraging van acht uur. Laten we zien hoe we gegevens kunnen herstellen aan de hand van een willekeurige verwijdering van snelkoppelingen<\/a><\/noindex>.<\/p>\n
<\/p>\n
Toen we het probleem ontdekten, schortten we de herstelling uit het archief<\/a><\/noindex> voor de vertraging van de replica:<\/p>\n
<\/p>\n
SELECT pg_xlog_replay_pause();<\/code><\/pre>\n
<\/p>\n
Met de pauze hadden we geen risico dat de replica de aanvraag herhaalde HEAD<\/code>. Een nuttige functie als je tijd nodig hebt om alles te begrijpen.<\/p>\n
<\/p>\n
Het punt is dat de vertraagde replica moet komen tot het moment v\u00f3\u00f3r de aanvraag HEAD<\/code>. We wisten ongeveer de fysieke tijd van de verwijdering. We hebben verwijderd recovery_min_apply_delay<\/code> en toegevoegd recovery_target_time<\/code> in recovery.conf<\/code>. Zo bereikt de replica het juiste moment zonder vertraging:<\/p>\n
<\/p>\n
recovery_target_time = '2018-10-12 09:25:00+00'<\/code><\/pre>\n
<\/p>\n
Met timestamps is het beter om te veel af te trekken, zodat je niet mist. Hoe meer je af trekt, hoe meer gegevens je verliest. Nogmaals, als we de aanvraag overslaan HEAD<\/code>, verdwijnen alle gegevens opnieuw en moet je helemaal opnieuw beginnen (of een koude back-up nemen voor PITR).<\/p>\n
<\/p>\n
We hebben de uitgestelde instantie van Postgres opnieuw opgestart en de WAL-segmenten zijn herhaald tot het opgegeven tijdstip. De voortgang op dit punt kan worden gevolgd met de volgende query:<\/p>\n
<\/p>\n
SELECT\n  -- huidige locatie in WAL\n  pg_last_xlog_replay_location(),\n  -- huidige tijdstempel van de transactie (staat van de replica)\n  pg_last_xact_replay_timestamp(),\n  -- huidige fysieke tijd\n  now(),\n  -- de hoeveelheid tijd die nog moet worden toegepast totdat recovery_target_time is bereikt\n  '2018-10-12 09:25:00+00'::timestamptz - pg_last_xact_replay_timestamp() as delay;<\/code><\/pre>\n
<\/p>\n
Als de tijdstempel niet meer verandert, is het herstel voltooid. U kunt de actie instellen recovery_target_action<\/code><\/a><\/noindex>, om de instantie te sluiten, voort te zetten of te pauzeren na de herhaling (standaard wordt deze gepauzeerd).<\/p>\n
<\/p>\n
De database is terug in de staat v\u00f3\u00f3r die noodlottige query. Nu kunnen we bijvoorbeeld gegevens exporteren. We hebben de verwijderde gegevens over het label en alle koppelingen naar taken en merge-verzoeken ge\u00ebxporteerd en naar de werkdatabase verplaatst. Als er een groot verlies was, kunnen we eenvoudig de replica voortzetten en deze als hoofd gebruiken. Maar dan gaan alle wijzigingen verloren die gedaan zijn na het moment waarop we zijn hersteld.<\/p>\n
<\/p>\n
In plaats van tijdstempels is het beter om transactiekenmerken te gebruiken. Het is nuttig om deze ID's bij te houden, bijvoorbeeld voor DDL-operators (zoals DROP TABLE<\/code>), met behulp van log_statements = 'ddl'<\/code>. Als we de transactiekenmerken hadden, zouden we recovery_target_xid<\/code> nemen en alles doorlopen tot de transactie v\u00f3\u00f3r de aanvraag. HEAD<\/code>.<\/p>\n
<\/p>\n
Terug aan het werk is heel eenvoudig: verwijder alle wijzigingen uit recovery.conf<\/code> en start Postgres opnieuw. Binnenkort verschijnt er weer een vertraging van acht uur in de replica en zijn we klaar voor toekomstige problemen.<\/p>\n
<\/p>\n
Voordelen van herstel<\/h3>\n
<\/p>\n
Met een uitgestelde replica hoeft u niet urenlang de volledige snapshot uit het archief te herstellen. Het kost ons bijvoorbeeld vijf uur om de volledige basisback-up van 2 TB op te halen. En dan moeten we ook nog de volledige dagelijkse WAL toepassen om te herstellen tot de gewenste staat (in het slechtste geval).<\/p>\n
<\/p>\n
Een uitgestelde replica biedt voordelen ten opzichte van een koude back-up op twee punten:<\/p>\n
<\/p>\n
    \n
  1. U hoeft de volledige basisback-up niet uit het archief te halen.<\/li>\n
  2. Er is een vast acht-uurs venster van WAL-segmenten die herhaald moeten worden.<\/li>\n<\/ol>\n
    <\/p>\n
    Bovendien controleren we constant of PITR uit de WAL mogelijk is, en zouden we snel beschadigingen of andere problemen met het WAL-archief opmerken door de achterstand van de uitgestelde replica in de gaten te houden.<\/p>\n
    <\/p>\n
    In dit voorbeeld kostte het ons 50 minuten om te herstellen, wat betekent dat de snelheid 110 GB WAL-gegevens per uur was (het archief was toen nog steeds op AWS S3<\/a><\/noindex>). In totaal hebben we het probleem opgelost en de data binnen 1,5 uur hersteld.<\/p>\n
    <\/p>\n
    Conclusies: waar uitgestelde replicatie nuttig is (en waar niet)<\/h3>\n
    <\/p>\n
    Gebruik uitgestelde replicatie als eerste hulp als je per ongeluk gegevens hebt verloren en dit probleem binnen de ingestelde vertraging opmerkt.<\/p>\n
    <\/p>\n
    Maar houd er rekening mee: replicatie is geen backup.<\/p><\/blockquote>\n
    Backups en replicatie hebben verschillende doelen. Een koude backup is nuttig als je per ongeluk hebt gedaan HEAD<\/code> of DROP TABLE<\/code>. We maken een backup vanuit de koude opslag en herstellen de vorige staat van de tabel of de gehele database. Maar ondertussen wordt de aanvraag DROP TABLE<\/code> bijna onmiddellijk in alle replicas op het werkcluster gereproduceerd, dus gewone replicatie zal hier niet helpen. Replicatie zelf houdt de database toegankelijk wanneer afzonderlijke servers falen en verdeelt de belasting.<\/p>\n
    <\/p>\n
    Zelfs met een uitgestelde replicatie hebben we soms dringend een koude backup nodig op een veilige plek, voor het geval er een storing van het datacenter, verborgen schade of andere gebeurtenissen plaatsvinden die je niet onmiddellijk opmerkt. In dit geval heeft de replicatie alleen weinig nut.<\/p>\n
    <\/p>\n
    Opmerking<\/strong>. Op GitLab.com<\/a><\/noindex> beschermen we momenteel alleen tegen gegevensverlies op systeemniveau en herstellen we geen gegevens op gebruikersniveau.<\/p>\n
    Bron: 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\udd47 Hoe we uitgestelde replicatie hebben gebruikt voor noodherstel met PostgreSQL | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/30356","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=30356"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/30356\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/22360"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=30356"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=30356"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=30356"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}