{"id":73446,"date":"2020-03-09T20:41:59","date_gmt":"2020-03-09T17:41:59","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/pochemu-mozhet-ponadobitsya-polusinhronnaya-replikacziya"},"modified":"2020-03-09T20:41:59","modified_gmt":"2020-03-09T17:41:59","slug":"pochemu-mozhet-ponadobitsya-polusinhronnaya-replikacziya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/pochemu-mozhet-ponadobitsya-polusinhronnaya-replikacziya","title":{"rendered":"Waarom kan het nodig zijn om semi-synchrone replicatie te hebben?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i>Hallo iedereen. Dit is Vladislav Rodin. Momenteel geef ik cursussen op het OTUS-platform over software-architectuur en software-architectuur die onder hoge belasting staat. <b>In de aanloop naar de start van de nieuwe ronde van de cursus <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/jvDY\/\">\u00abArchitect van hoge belasting\u00bb<\/a><\/noindex> heb ik besloten om een klein origineel stuk te schrijven dat ik graag met jullie wil delen.<\/b><\/i><\/p>\n<p><img decoding=\"async\" alt=\"Waarom kan het nodig zijn om semi-synchrone replicatie te hebben?\" src=\"\/wp-content\/uploads\/2020\/03\/c2a1ea514249f8fca1ab9f668a899981.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Inleiding<\/h2>\n<p>\nOmdat op HDD's slechts ongeveer 400-700 bewerkingen per seconde kunnen worden uitgevoerd (wat niet te vergelijken is met de typische rps die worden gegenereerd door een zwaarbelaste systeem), is een klassieke schijfdatabase een knelpunt in de architectuur. Daarom is het belangrijk om speciale aandacht te besteden aan de schaling van deze opslag.<\/p>\n<p>Momenteel zijn er 2 schalingpatronen voor databases: replicatie en sharding. Sharding maakt het mogelijk om de schrijfbewerking te schalen en, als gevolg daarvan, de rps op schrijven die op \u00e9\u00e9n server van uw cluster komt te verminderen. Replicatie maakt hetzelfde mogelijk, maar dan voor leesbewerkingen. Dit patroon is waar dit artikel aan gewijd is.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Replicatie<\/h2>\n<p>\nAls we naar replicatie kijken vanuit een heel hoog niveau, is het een simpel concept: je had \u00e9\u00e9n server waarop de gegevens waren opgeslagen, en toen kon die server de leeslast van deze gegevens niet meer aan. Je voegt nog een paar servers toe, synchroniseert de gegevens op alle servers, en de gebruiker kan van elke server van uw cluster lezen. <\/p>\n<p>Ondanks de schijnbare eenvoud zijn er verschillende manieren om de verschillende implementaties van dit schema te classificeren:<\/p>\n<ul>\n<li>Op rollen in de cluster (master-master of master-slave)<\/li>\n<li>Op verzonden objecten (row-based, statement-based of mixed)<\/li>\n<li>Volgens het synchronisatiemechanisme van de nodes<\/li>\n<\/ul>\n<p>\nVandaag zullen we ons richten op punt 3. <\/p>\n<h2>Hoe de transactie wordt gecommiteerd<\/h2>\n<p>\nDit onderwerp is niet direct gerelateerd aan replicatie, hier kan een apart artikel over worden geschreven, maar aangezien het begrijpen van het mechanisme van de transactietoewijzing verder lezen nutteloos maakt, laat ik mezelf de belangrijkste zaken herinneren. De commit van een transactie gebeurt in 3 stappen:<\/p>\n<ol>\n<li>Het schrijven van de transactie naar het databasejournal.<\/li>\n<li>Het toepassen van de transactie in de database-engine.<\/li>\n<li>Het terugsturen van de bevestiging aan de cli\u00ebnt dat de transactie succesvol is toegepast.<\/li>\n<\/ol>\n<p>\nIn verschillende databases kunnen er nuances optreden in dit algoritme: bijvoorbeeld, in de InnoDB-engine van MySQL zijn er 2 logs: \u00e9\u00e9n voor replicatie (binary log) en de andere voor het behouden van ACID (undo\/redolog), terwijl PostgreSQL \u00e9\u00e9n log heeft die beide functies vervult (write ahead log = WAL). Maar hierboven is de algemene conceptie gepresenteerd die dergelijke nuances niet in overweging neemt.<\/p>\n<h2>Synchronisatie (sync) replicatie<\/h2>\n<p>\nLaten we de logica voor het repliceren van de ontvangen wijzigingen toevoegen aan het commit-algoritme van de transactie:<\/p>\n<ol>\n<li>Het schrijven van de transactie naar het databasejournal.<\/li>\n<li>Het toepassen van de transactie in de database-engine.<\/li>\n<li><b>Gegevens verzenden naar alle replicas.<\/b><\/li>\n<li><b>Bevestiging ontvangen van alle replicas over de uitvoering van de transactie.<\/b><\/li>\n<li>Het terugsturen van de bevestiging aan de cli\u00ebnt dat de transactie succesvol is toegepast.<\/li>\n<\/ol>\n<p>\nBij deze aanpak ondervinden we een aantal nadelen: <\/p>\n<ul>\n<li>de client wacht op de toepassing van wijzigingen op alle replicas.<\/li>\n<li>met de toename van het aantal knooppunten in het cluster verminderen we de kans dat de schrijfoperatie succesvol is.<\/li>\n<\/ul>\n<p>\nAls het eerste punt meer of minder duidelijk is, dan is het de moeite waard om de redenen voor het tweede punt toe te lichten. Als we bij synchronisatie replicatie geen antwoord van ten minste \u00e9\u00e9n knooppunt ontvangen, annulleren we de transactie. Hierdoor vergroot u, door het aantal knooppunten in het cluster te verhogen, de kans dat de schrijfoperatie mislukt. <\/p>\n<p>Kunnen we bevestiging verwachten van slechts een deel van de knooppunten, bijvoorbeeld van 51% (quorum)? Ja, dat kan, maar in de klassieke variant is bevestiging van alle knooppunten nodig, want zo kunnen we volledige consistentie van de gegevens in het cluster waarborgen, wat een onmiskenbaar voordeel van dit soort replicatie is.<\/p>\n<h2>Asynchrone (async) replicatie<\/h2>\n<p>\nLaten we het vorige algoritme aanpassen. We zullen de gegevens naar de replicas verzenden 'op een later moment', en 'op een later moment' zullen de wijzigingen op de replicas worden toegepast:<\/p>\n<ol>\n<li>Het schrijven van de transactie naar het databasejournal.<\/li>\n<li>Het toepassen van de transactie in de database-engine.<\/li>\n<li>Het terugsturen van de bevestiging aan de cli\u00ebnt dat de transactie succesvol is toegepast.<\/li>\n<li><b>Gegevens verzenden naar de replicas en het toepassen van wijzigingen door hen.<\/b><\/li>\n<\/ol>\n<p>\nDeze aanpak zorgt ervoor dat het cluster snel werkt, omdat we de client niet laten wachten totdat de gegevens naar de replicas zijn verzonden en bovendien zijn gecommit.<\/p>\n<p>Maar de voorwaarde om de gegevens naar de replicas 'op een later moment' te verzenden kan leiden tot verlies van transactie, en dit betreft het verlies van een bevestigde transactie aan de gebruiker, want als de gegevens niet tijdig zijn gerepliceerd, wordt de client bevestiging gestuurd over het succesvol uitvoeren van de operatie, terwijl de knoop waar de wijzigingen zijn aangekomen, een HDD-fout heeft, verliezen we de transactie, wat zeer onaangename gevolgen kan hebben.<\/p>\n<h2>Halve synchronisatie (semisync) replicatie<\/h2>\n<p>\nEindelijk zijn we aangekomen bij half-synchrone replicatie. Dit type replicatie is niet erg bekend en niet veelvoorkomend, maar het is heel interessant omdat het de voordelen van zowel synchrone als asynchrone replicatie kan combineren.<\/p>\n<p>Laten we proberen de twee eerdere benaderingen te combineren. We zullen de cli\u00ebnt niet lang vasthouden, maar we eisen dat de gegevens gerepliceerd worden:<\/p>\n<ol>\n<li>Het schrijven van de transactie naar het databasejournal.<\/li>\n<li>Het toepassen van de transactie in de database-engine.<\/li>\n<li><b>Verzending van gegevens naar de replica's.<\/b><\/li>\n<li><b>Ontvangstbevestiging van de replica over het ontvangen van wijzigingen (of ze zullen 'een keer later' toegepast worden).<\/b><\/li>\n<li>Het terugsturen van de bevestiging aan de cli\u00ebnt dat de transactie succesvol is toegepast.<\/li>\n<\/ol>\n<p>\nLet op dat bij dit algoritme het verlies van een transactie slechts optreedt in het geval van een storing van zowel de node die de wijzigingen aanneemt als de replica-node. De kans op zo'n storing wordt als klein beschouwd en deze risico's worden aanvaard. <\/p>\n<p>Bij deze benadering bestaat het risico van phantom reads. Stel je het volgende scenario voor: in stap 4 hebben we van geen enkele replica een bevestiging ontvangen. We moeten deze transactie terugdraaien en de cli\u00ebnt geen bevestiging geven. Aangezien de gegevens in stap 2 zijn toegepast, ontstaat er een tijdsperiode tussen het einde van stap 2 en het terugdraaien van de transactie, waarin parallelle transacties die wijzigingen kunnen zien die niet in de database zouden moeten zijn. <\/p>\n<h2>Lose-less semisync replicatie<\/h2>\n<p>\nAls we even nadenken, kunnen we simpelweg de stappen van het algoritme omwisselen om het probleem van phantom reads in dit scenario op te lossen:<\/p>\n<ol>\n<li>Het schrijven van de transactie naar het databasejournal.<\/li>\n<li><b>Verzending van gegevens naar de replica.<\/b><\/li>\n<li><b>Ontvangstbevestiging van de replica over het ontvangen van wijzigingen (of ze zullen 'een keer later' toegepast worden).<\/b><\/li>\n<li>Het toepassen van de transactie in de database-engine.<\/li>\n<li>Het terugsturen van de bevestiging aan de cli\u00ebnt dat de transactie succesvol is toegepast.<\/li>\n<\/ol>\n<p>\nNu committeren we de wijzigingen alleen als ze gerepliceerd zijn. <\/p>\n<h2>Uitslag<\/h2>\n<p>\nZoals altijd zijn er geen ideale oplossingen, maar een verzameling oplossingen, elk met zijn eigen voor- en nadelen en geschikt voor verschillende klassen van problemen. Dit is ook zeker waar voor het kiezen van een mechanisme voor gegevenssynchronisatie in een gerepliceerde database. De voordelen van half-synchrone replicatie zijn vrij aanzienlijk en interessant genoeg om het aandacht waard te maken, ondanks de geringe verspreiding.<\/p>\n<p><b>Dit is het. Tot ziens bij <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/jvDY\/\">de cursus<\/a><\/noindex>!<\/b><br \/>\n<br \/>Bron: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/491106\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u0412\u043b\u0430\u0434\u0438\u0441\u043b\u0430\u0432 \u0420\u043e\u0434\u0438\u043d. \u0412 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u044f \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u044e \u043d\u0430 \u043f\u043e\u0440\u0442\u0430\u043b\u0435 OTUS \u043a\u0443\u0440\u0441\u044b, \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u043d\u044b\u0435 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e \u0438 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e, \u043f\u043e\u0434\u0432\u0435\u0440\u0436\u0435\u043d\u043d\u043e\u0433\u043e \u0432\u044b\u0441\u043e\u043a\u043e\u0439 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0435. \u0412 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u043e\u0433\u043e \u043f\u043e\u0442\u043e\u043a\u0430 \u043a\u0443\u0440\u0441\u0430 \u00ab\u0410\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0432\u044b\u0441\u043e\u043a\u0438\u0445 \u043d\u0430\u0433\u0440\u0443\u0437\u043e\u043a\u00bb \u044f \u0440\u0435\u0448\u0438\u043b \u043d\u0430\u043f\u0438\u0441\u0430\u0442\u044c \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u0430\u0432\u0442\u043e\u0440\u0441\u043a\u0438\u0439 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b, \u043a\u043e\u0442\u043e\u0440\u044b\u043c \u0445\u043e\u0447\u0443 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0441 \u0432\u0430\u043c\u0438. \u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0418\u0437-\u0437\u0430 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e \u043d\u0430 HDD \u043c\u043e\u0436\u0435\u0442 \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0442\u044c\u0441\u044f \u043b\u0438\u0448\u044c \u043f\u043e\u0440\u044f\u0434\u043a\u0430 400-700 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":73447,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-73446","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\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u0412\u043b\u0430\u0434\u0438\u0441\u043b\u0430\u0432 \u0420\u043e\u0434\u0438\u043d. \u0412 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u044f \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u044e \u043d\u0430 \u043f\u043e\u0440\u0442\u0430\u043b\u0435 OTUS \u043a\u0443\u0440\u0441\u044b, \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u043d\u044b\u0435 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e \u0438 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e, \u043f\u043e\u0434\u0432\u0435\u0440\u0436\u0435\u043d\u043d\u043e\u0433\u043e \u0432\u044b\u0441\u043e\u043a\u043e\u0439 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0435.\" \/>\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\/nl\/blog\/administrirovanie\/pochemu-mozhet-ponadobitsya-polusinhronnaya-replikacziya\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\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\u041f\u043e\u0447\u0435\u043c\u0443 \u043c\u043e\u0436\u0435\u0442 \u043f\u043e\u043d\u0430\u0434\u043e\u0431\u0438\u0442\u044c\u0441\u044f \u043f\u043e\u043b\u0443\u0441\u0438\u043d\u0445\u0440\u043e\u043d\u043d\u0430\u044f \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044f? | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u0412\u043b\u0430\u0434\u0438\u0441\u043b\u0430\u0432 \u0420\u043e\u0434\u0438\u043d. \u0412 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u044f \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u044e \u043d\u0430 \u043f\u043e\u0440\u0442\u0430\u043b\u0435 OTUS \u043a\u0443\u0440\u0441\u044b, \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u043d\u044b\u0435 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e \u0438 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e, \u043f\u043e\u0434\u0432\u0435\u0440\u0436\u0435\u043d\u043d\u043e\u0433\u043e \u0432\u044b\u0441\u043e\u043a\u043e\u0439 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0435.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/pochemu-mozhet-ponadobitsya-polusinhronnaya-replikacziya\" \/>\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=\"2020-03-09T17:41:59+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-03-09T17:41:59+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\udd47Waarom kan half-synchrone replicatie nodig zijn? | ProHoster","description":"Hallo iedereen. Dit is Vladislav Rodin. Momenteel geef ik cursussen op het OTUS-platform over software-architectuur en software-architectuur die onder hoge belasting staat.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/pochemu-mozhet-ponadobitsya-polusinhronnaya-replikacziya","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\u041f\u043e\u0447\u0435\u043c\u0443 \u043c\u043e\u0436\u0435\u0442 \u043f\u043e\u043d\u0430\u0434\u043e\u0431\u0438\u0442\u044c\u0441\u044f \u043f\u043e\u043b\u0443\u0441\u0438\u043d\u0445\u0440\u043e\u043d\u043d\u0430\u044f \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044f? | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u0412\u043b\u0430\u0434\u0438\u0441\u043b\u0430\u0432 \u0420\u043e\u0434\u0438\u043d. \u0412 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u044f \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u044e \u043d\u0430 \u043f\u043e\u0440\u0442\u0430\u043b\u0435 OTUS \u043a\u0443\u0440\u0441\u044b, \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u043d\u044b\u0435 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e \u0438 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e, \u043f\u043e\u0434\u0432\u0435\u0440\u0436\u0435\u043d\u043d\u043e\u0433\u043e \u0432\u044b\u0441\u043e\u043a\u043e\u0439 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0435.","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/pochemu-mozhet-ponadobitsya-polusinhronnaya-replikacziya","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":"2020-03-09T17:41:59+00:00","article:modified_time":"2020-03-09T17:41:59+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"73446","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:50:08","updated":"2022-09-28 11:57:57","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\/73446","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=73446"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/73446\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/73447"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=73446"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=73446"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=73446"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}