{"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\/it\/blog\/administrirovanie\/pochemu-mozhet-ponadobitsya-polusinhronnaya-replikacziya","title":{"rendered":"Perch\u00e9 potrebbe essere necessaria la replica parziale?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i>Ciao a tutti. Sono Vladislav Rodin. Attualmente insegno sul portale OTUS corsi dedicati all'architettura del software e all'architettura del software soggetta a carichi elevati. <b>In vista dell'inizio di un nuovo ciclo di corsi <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/jvDY\/\">\u00abArchitetto dei sistemi ad alta disponibilit\u00e0\u00bb<\/a><\/noindex> ho deciso di scrivere un breve materiale originale che desidero condividere con voi.<\/b><\/i><\/p>\n<p><img decoding=\"async\" alt=\"Perch\u00e9 potrebbe essere necessaria la replica parziale?\" src=\"\/wp-content\/uploads\/2020\/03\/c2a1ea514249f8fca1ab9f668a899981.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Introduzione<\/h2>\n<p>\nPoich\u00e9 un HDD pu\u00f2 eseguire solo circa 400-700 operazioni al secondo (cosa che non pu\u00f2 essere paragonata ai tipici rps che si riscontrano in un sistema ad alta intensit\u00e0 di carico), un classico database su disco rappresenta un collo di bottiglia nell'architettura. Pertanto, \u00e8 fondamentale prestare particolare attenzione ai modelli di scalabilit\u00e0 di questo tipo di archiviazione.<\/p>\n<p>Attualmente ci sono 2 pattern di scalabilit\u00e0 del database: replicazione e sharding. Lo sharding consente di scalare l'operazione di scrittura e, di conseguenza, ridurre gli rps di scrittura su un singolo server del proprio cluster. La replicazione consente la stessa cosa, ma con le operazioni di lettura. \u00c8 proprio a questo pattern che \u00e8 dedicato questo articolo.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Replica<\/h2>\n<p>\nSe si guarda alla replicazione da un punto di vista molto generico, \u00e8 una cosa semplice: avevi un server, su di esso c'erano i dati, e poi quel server ha smesso di gestire il carico di lettura di quei dati. Aggiungi un paio di server, sincronizzi i dati su tutti i server e l'utente pu\u00f2 leggere da qualsiasi server del tuo cluster. <\/p>\n<p>Nonostante la sua apparente semplicit\u00e0, ci sono diversi modi per classificare le varie implementazioni di questo schema:<\/p>\n<ul>\n<li>Per ruoli nel cluster (master-master o master-slave)<\/li>\n<li>Per oggetti inviati (row-based, statement-based o mixed)<\/li>\n<li>Per meccanismo di sincronizzazione dei nodi<\/li>\n<\/ul>\n<p>\nOggi ci concentreremo proprio sul terzo punto. <\/p>\n<h2>Come avviene il commit delle transazioni<\/h2>\n<p>\nQuesto argomento non \u00e8 direttamente correlato alla replicazione e potrebbe complessivamente richiedere un articolo separato, ma poich\u00e9 senza comprendere il meccanismo di commit delle transazioni la lettura successiva risulterebbe inutile, mi permetto di ricordare le cose pi\u00f9 fondamentali. Il commit delle transazioni avviene in 3 fasi:<\/p>\n<ol>\n<li>Registrazione della transazione nel registro del database.<\/li>\n<li>Applicazione della transazione nel motore del database.<\/li>\n<li>Restituzione della conferma al cliente sull'applicazione riuscita della transazione.<\/li>\n<\/ol>\n<p>\nNelle diverse basi in questo algoritmo possono sorgere delle sfumature: ad esempio, nel motore InnoDB del database MySQL ci sono 2 registri: uno per la replicazione (binary log) e l'altro per mantenere l'ACID (undo\/red log), mentre in PostgreSQL c'\u00e8 un solo registro che svolge entrambe le funzioni (write ahead log = WAL). Tuttavia, quanto sopra rappresenta propriamente il concetto generale, che consente di non considerare tali sfumature.<\/p>\n<h2>Replicazione sincrona (sync)<\/h2>\n<p>\nAggiungiamo all'algoritmo di commit della transazione la logica per replicare le modifiche ricevute:<\/p>\n<ol>\n<li>Registrazione della transazione nel registro del database.<\/li>\n<li>Applicazione della transazione nel motore del database.<\/li>\n<li><b>Invio dei dati a tutte le repliche.<\/b><\/li>\n<li><b>Ricezione della conferma da tutte le repliche riguardo l'esecuzione della transazione.<\/b><\/li>\n<li>Restituzione della conferma al cliente sull'applicazione riuscita della transazione.<\/li>\n<\/ol>\n<p>\nCon questo approccio otteniamo una serie di svantaggi: <\/p>\n<ul>\n<li>il cliente attende l'applicazione delle modifiche su tutte le repliche.<\/li>\n<li>con l'aumento del numero di nodi nel cluster diminuiamo la probabilit\u00e0 che l'operazione di scrittura vada a buon fine.<\/li>\n<\/ul>\n<p>\nSe per il primo punto \u00e8 tutto pi\u00f9 o meno chiaro, le ragioni del secondo punto meritano una spiegazione. Se nella replicazione sincrona non riceviamo risposta da almeno un nodo, annulliamo la transazione. Cos\u00ec, aumentando il numero di nodi nel cluster, aumentate la probabilit\u00e0 che l'operazione di scrittura fallisca. <\/p>\n<p>Possiamo attendere conferma da solo una certa percentuale di nodi, ad esempio, dal 51% (quorum)? S\u00ec, possiamo, tuttavia nella versione classica \u00e8 richiesta la conferma da tutti i nodi, poich\u00e9 \u00e8 cos\u00ec che possiamo garantire la piena consistenza dei dati nel cluster, che \u00e8 un indubbio vantaggio di questo tipo di replicazione.<\/p>\n<h2>Replicazione asincrona (async)<\/h2>\n<p>\nModifichiamo l'algoritmo precedente. I dati alle repliche verranno inviati \"prima o poi\", e \"prima o poi\" le modifiche saranno applicate sulle repliche:<\/p>\n<ol>\n<li>Registrazione della transazione nel registro del database.<\/li>\n<li>Applicazione della transazione nel motore del database.<\/li>\n<li>Restituzione della conferma al cliente sull'applicazione riuscita della transazione.<\/li>\n<li><b>Invio dei dati alle repliche e applicazione delle modifiche da parte loro.<\/b><\/li>\n<\/ol>\n<p>\nQuesto approccio porta a un cluster che funziona rapidamente, poich\u00e9 non teniamo il cliente in attesa finch\u00e9 i dati arrivano alle repliche e devono anche essere confermati.<\/p>\n<p>Ma la condizione di invio dei dati alle repliche \"prima o poi\" pu\u00f2 portare alla perdita di una transazione, e in particolare alla perdita di una transazione confermata all'utente, poich\u00e9 se i dati non sono stati replicati in tempo, la conferma al cliente sull'esito positivo dell'operazione \u00e8 stata inviata, mentre nel nodo che ha ricevuto le modifiche, l'HDD \u00e8 andato in crash, perdiamo la transazione, il che pu\u00f2 portare a conseguenze molto spiacevoli.<\/p>\n<h2>Replicazione semisincrona (semisync)<\/h2>\n<p>\nFinalmente siamo arrivati alla replica semisincrona. Questo tipo di replica non \u00e8 molto conosciuto e non \u00e8 molto diffuso, ma presenta un notevole interesse, poich\u00e9 pu\u00f2 combinare i vantaggi sia della replica sincronizzata che di quella asincrona.<\/p>\n<p>Proviamo a unire i 2 approcci precedenti. Non terremo a lungo il cliente, ma richiederemo che i dati vengano replicati:<\/p>\n<ol>\n<li>Registrazione della transazione nel registro del database.<\/li>\n<li>Applicazione della transazione nel motore del database.<\/li>\n<li><b>Invio dei dati alle repliche.<\/b><\/li>\n<li><b>Ricezione della conferma dalla replica sulla ricezione delle modifiche (esse saranno applicate \"quando sar\u00e0 possibile\").<\/b><\/li>\n<li>Restituzione della conferma al cliente sull'applicazione riuscita della transazione.<\/li>\n<\/ol>\n<p>\nSi noti che con questo algoritmo la perdita di transazione si verifica solo in caso di arresto sia del nodo che riceve le modifiche sia del nodo-replica. La probabilit\u00e0 di un guasto di questo tipo \u00e8 considerata bassa, e questi rischi sono accettati. <\/p>\n<p>Ma con questo approccio \u00e8 possibile il rischio di letture fantasma. Immaginiamo il seguente scenario: al passo 4 non abbiamo ricevuto conferma da nessuna replica. Dobbiamo annullare questa transazione e non restituire alcuna conferma al cliente. Poich\u00e9 i dati sono stati applicati al passo 2, tra la fine del passo 2 e l'annullamento della transazione si crea un intervallo di tempo in cui transazioni parallele possono vedere quelle modifiche che non dovrebbero esserci nel database. <\/p>\n<h2>Replica semisincera senza perdita<\/h2>\n<p>\nSe ci pensiamo un attimo, basta solo scambiare i passi dell'algoritmo per risolvere il problema delle letture fantasma in questo scenario:<\/p>\n<ol>\n<li>Registrazione della transazione nel registro del database.<\/li>\n<li><b>Invio dei dati della replica.<\/b><\/li>\n<li><b>Ricezione della conferma dalla replica sulla ricezione delle modifiche (esse saranno applicate \"quando sar\u00e0 possibile\").<\/b><\/li>\n<li>Applicazione della transazione nel motore del database.<\/li>\n<li>Restituzione della conferma al cliente sull'applicazione riuscita della transazione.<\/li>\n<\/ol>\n<p>\nOra confermiamo le modifiche solo se sono state replicate. <\/p>\n<h2>Conclusione<\/h2>\n<p>\nCome sempre, non esistono soluzioni ideali, ma piuttosto un insieme di soluzioni, ognuna delle quali ha i propri vantaggi e svantaggi e si adatta a diverse classi di problemi. Questo \u00e8 altrettanto vero per la scelta del meccanismo di sincronizzazione dei dati in un database replicato. L'insieme dei vantaggi che offre la replica semisincrona \u00e8 abbastanza solido e interessante da essere considerato degno di attenzione, nonostante la sua scarsa diffusione.<\/p>\n<p><b>Questo \u00e8 tutto. Ci vediamo a <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/jvDY\/\">corso<\/a><\/noindex>!<\/b><br \/>\n<br \/>Fonte: <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.1.1 - 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\/it\/blog\/administrirovanie\/pochemu-mozhet-ponadobitsya-polusinhronnaya-replikacziya\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\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\/it\/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\udd47Perch\u00e9 potrebbe essere necessaria la replica semisincrona? | ProHoster","description":"Ciao a tutti. Sono Vladislav Rodin. Attualmente insegno sul portale OTUS corsi dedicati all'architettura del software e all'architettura del software soggetta a carichi elevati.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/pochemu-mozhet-ponadobitsya-polusinhronnaya-replikacziya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/73446","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=73446"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/73446\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/73447"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=73446"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=73446"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=73446"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}