{"id":39169,"date":"2019-10-31T22:28:14","date_gmt":"2019-10-31T19:28:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya\/"},"modified":"2019-10-31T22:28:14","modified_gmt":"2019-10-31T19:28:14","slug":"postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","title":{"rendered":"PostgreSQL og indstillinger for konsistens af skrivninger for hver enkelt forbindelse","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Overs\u00e6ttelsen er specielt udarbejdet til studerende p\u00e5 kurset \u00abDatabaser\u00bb<\/a><\/noindex>. Er du interesseret i at udvikle dig i dette omr\u00e5de? Vi inviterer dig til \u00c5bent Hus-dag<\/a><\/noindex>, hvor vi detaljeret fort\u00e6ller om programmet, de s\u00e6rlige forhold ved online-formatet, kompetencerne og karrieremulighederne, som venter kandidaterne efter uddannelsen.<\/em><\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

PostgreSQL og indstillinger for konsistens af skrivninger for hver enkelt forbindelse
\nHos Compose arbejder vi med mange databaser, hvilket giver os mulighed for at l\u00e6re deres funktionalitet og begr\u00e6nsninger at kende. Efterh\u00e5nden som vi l\u00e6rer at v\u00e6rds\u00e6tte de funktionelle egenskaber ved nye databaser, begynder vi nogle gange at t\u00e6nke p\u00e5, hvor godt det ville v\u00e6re, hvis s\u00e5danne funktioner ogs\u00e5 blev tilg\u00e6ngelige i mere etablerede v\u00e6rkt\u00f8jer, som vi har arbejdet med i lang tid. En af de nye funktioner, som vi \u00f8nskede at se i PostgreSQL, var konfigurerbar skrivningskonsistens pr. forbindelse i hele klyngen. Og som det viste sig, har vi det allerede, og i dag vil vi dele information med dig om, hvordan du kan bruge det.<\/a><\/noindex><\/p>\n

<\/p>\n

Hvorfor vil jeg have dette?<\/h1>\n

<\/p>\n

Hvordan klyngen skal fungere, afh\u00e6nger af din applikation. Lad os tage et eksempel med en betalingsapplikation. Du vil have 100% konsistens i klyngen, s\u00e5 du bliver n\u00f8dt til at aktivere synkrone commits, s\u00e5 din database venter p\u00e5, at alle \u00e6ndringer er foretaget. Men hvis din applikation er et hurtigt voksende socialt netv\u00e6rk, vil du sandsynligvis foretr\u00e6kke hurtig respons frem for 100% konsistens. For at opn\u00e5 dette kan du bruge asynkrone commits i din klynge.<\/p>\n

<\/p>\n

M\u00f8d kompromiset<\/h2>\n

<\/p>\n

Du skal finde et kompromis mellem datakonsistens og ydeevne. PostgreSQL skrider v\u00e6k fra konsistens, da standardkonfigurationen i dette tilf\u00e6lde er forudsigelig og uden uventede overraskelser. Lad os nu se p\u00e5 kompromiserne.<\/p>\n

<\/p>\n

Kompromis 1: Ydeevne<\/h3>\n

<\/p>\n

Hvis PostgreSQL-clusteret ikke kr\u00e6ver konsistens, kan det fungere asynkront. Skriveoperationer skjer p\u00e5 clusterets leder, og opdateringer vil blive sendt til replikaerne efter et par millisekunder. N\u00e5r PostgreSQL-clusteret kr\u00e6ver konsistens, skal det fungere synkront. Skriveoperationen vil blive udf\u00f8rt p\u00e5 lideren, som sender opdateringen til replikaerne og venter p\u00e5 bekr\u00e6ftelse, s\u00e5 hver replika har udf\u00f8rt skriveoperationen, f\u00f8r den sender bekr\u00e6ftelsen til klienten, der initierede skridningen, om at den blev udf\u00f8rt med succes. Den praktiske forskel mellem disse tilgange er, at den asynkrone metode kr\u00e6ver to netv\u00e6rksspring, mens den synkrone kr\u00e6ver fire. <\/p>\n

<\/p>\n

Kompromis 2: Konsistens<\/h3>\n

<\/p>\n

Resultatet ved en fejl p\u00e5 lederen i disse to tilgange vil ogs\u00e5 v\u00e6re forskelligt. Hvis opgaven udf\u00f8res asynkront, vil ikke alle optegnelser v\u00e6re bekr\u00e6ftet af replikaerne i tilf\u00e6lde af en s\u00e5dan fejl. Hvor meget vil g\u00e5 tabt? Det afh\u00e6nger af applikationen og effektiviteten af replikationen. Compose-replikation forhindrer en replika i at blive leder, hvis m\u00e6ngden af information i den er 1 MB mindre end i lederen, hvilket betyder, at der potentielt kan g\u00e5 op til 1 MB optegnelser tabt ved asynkron drift. <\/p>\n

<\/p>\n

Dette sker ikke i den synkrone tilstand. Hvis lederen fejler, opdateres alle replikaer, da enhver optegnelse, der er bekr\u00e6ftet p\u00e5 lederen, ogs\u00e5 skal bekr\u00e6ftes i replikaerne. Her har vi konsistens. <\/p>\n

<\/p>\n

Synkront adf\u00e6rd giver mening at anvende i en betalingsapplikation, hvor konsistens har en \u00e5benlys fordel i at finde et kompromis mellem konsistens og ydeevne. Det vigtigste for s\u00e5dan en applikation er gyldige data. Og t\u00e6nk nu p\u00e5 et socialt netv\u00e6rk, hvor hovedopgaven er at fastholde brugerens opm\u00e6rksomhed ved at svare p\u00e5 foresp\u00f8rgsler s\u00e5 hurtigt som muligt. I dette tilf\u00e6lde vil ydeevnen med f\u00e6rre netv\u00e6rksspring og kortere ventetid p\u00e5 bekr\u00e6ftelser v\u00e6re prioriteret. Men kompromiset mellem ydeevne og konsistens er ikke det eneste, man skal overveje.<\/p>\n

<\/p>\n

Kompromis 3: Fejl<\/h3>\n

<\/p>\n

Det er meget vigtigt at forst\u00e5, hvordan en klynge opf\u00f8rer sig under en fejl. Lad os overveje en situation, hvor en eller flere replikaer fejler. N\u00e5r commits behandles asynkront, vil lederen forts\u00e6tte med at fungere, dvs. tage imod og behandle optegnelser uden at vente p\u00e5 de manglende replikaer. N\u00e5r replikaerne vender tilbage til klyngen, indhenter de lederen. Ved synkron replikation, hvis replikaerne ikke svarer, har lederen ingen valg og vil forts\u00e6tte med at vente p\u00e5 bekr\u00e6ftelse af commit, indtil replikaen vender tilbage til klyngen og kan modtage og bekr\u00e6fte optegnelsen.<\/p>\n

<\/p>\n

\u00c9n forbindelse pr. transaktion?<\/h2>\n

<\/p>\n

Hver applikation har brug for en s\u00e6rlig type kombination af konsistens og ydeevne. Medmindre det selvf\u00f8lgelig er vores regningsbetalingsapp, som vi forestiller os er helt konsistent, eller vores n\u00e6sten flygtige sociale medieapp. I alle andre tilf\u00e6lde vil der v\u00e6re tidspunkter, hvor nogle operationer skal v\u00e6re synkrone, mens andre skal v\u00e6re asynkrone. Du vil m\u00e5ske ikke have, at systemet skal vente p\u00e5, at en besked sendt i chatten bliver committed, men hvis der ogs\u00e5 foretages en betaling i denne app, m\u00e5 man vente.<\/p>\n

<\/p>\n

Alle disse beslutninger tr\u00e6ffes naturligvis af applikationsudvikleren. De rigtige beslutninger om, hvorn\u00e5r man skal anvende hvilken tilgang, hj\u00e6lper med at maksimere udbyttet af klyngen. Det er vigtigt, at udvikleren kan skifte mellem dem p\u00e5 SQL-niveau for forbindelser og for transaktioner. <\/p>\n

<\/p>\n

At sikre kontrol i praksis<\/h2>\n

<\/p>\n

Som standard sikrer PostgreSQL konsistens. Dette kontrolleres af serverparameteren synchronous_commit<\/code>. Som standard er den i position on<\/code>, men den har tre andre muligheder: local<\/code>, remote_write<\/code> eller off<\/code>.<\/p>\n

<\/p>\n

N\u00e5r parameteren er indstillet til off<\/code> s\u00e6ttes alle synkrone commits p\u00e5 pause, selv i det lokale system. Parameteren i local definerer den synkrone tilstand for det lokale system, men optegnelser til replikaer udf\u00f8res asynkront. Remote_write<\/code> g\u00e5r endnu l\u00e6ngere: optegnelser til replikaer foretages asynkront, men returneres, n\u00e5r replikaen har modtaget optegnelsen, men ikke har skrevet den til disk.<\/p>\n

<\/p>\n

N\u00e5r vi overvejer det eksisterende udvalg af muligheder, v\u00e6lger vi adf\u00e6rden, og vi husker, at on<\/code> \u2013 er synkrone optegnelser, s\u00e5 vi vil v\u00e6lge local<\/code> for asynkrone commits over netv\u00e6rket, mens vi holder lokale commits synkrone.<\/p>\n

<\/p>\n

Nu vil vi fort\u00e6lle dig, hvordan du hurtigt kan konfigurere dette, men forestil dig, at vi installerede synchronous_commit<\/code> i local<\/code> til serveren. Vi spekulerede p\u00e5, om vi kunne \u00e6ndre parameteren synchronous_commit<\/code> on-the-fly, og det viste sig, at det ikke bare var muligt, men der er faktisk to m\u00e5der at g\u00f8re det p\u00e5. Den f\u00f8rste m\u00e5de er at indstille din sessions forbindelse som f\u00f8lger:<\/p>\n

<\/p>\n

SET SESSION synchronous_commit TO ON;  \n\/\/ Dine skrivninger kommer her<\/code><\/pre>\n
<\/p>\n
Alle efterf\u00f8lgende skriver i sessionen vil bekr\u00e6fte skriveoperationer for replikaer, f\u00f8r en positivt resultat returneres til den tilsluttede klient. Medmindre du selvf\u00f8lgelig \u00e6ndrer indstillingen synchronous_commit<\/code> igen. Du kan udelade delen SESSION<\/code> i kommandoen, da den vil v\u00e6re i standardv\u00e6rdien.<\/p>\n
<\/p>\n
Den anden metode er god, n\u00e5r du blot vil sikre dig, at du f\u00e5r synkron replikation for en enkelt transaktion. I mange databaser af typen «NoSQL» findes begrebet transaktioner ikke, men det findes i PostgreSQL. I dette tilf\u00e6lde starter du en transaktion, og derefter s\u00e6tter du synchronous_commit<\/code> i on<\/code> f\u00f8r udf\u00f8relsen af skrivningen til transaktionen. COMMIT<\/code> vil bekr\u00e6fte transaktionen ved hj\u00e6lp af den parameterindstilling synchronous_commit<\/code>, der var indstillet p\u00e5 det tidspunkt, selvom det er bedst at indstille variablen p\u00e5 forh\u00e5nd for at sikre, at andre udviklere forst\u00e5r, at skrivningerne ikke er asynkrone.<\/p>\n
<\/p>\n
BEGIN;  \nSET LOCAL synchronous_commit TO ON;  \n\/\/ Dine skrivninger kommer her\nCOMMIT;  <\/code><\/pre>\n
<\/p>\n
Alle commit-ter for transaktioner vil nu bekr\u00e6ftes som skrevet til replikaer, f\u00f8r databasen returnerer et positivt svar til den tilsluttede klient.<\/p>\n
<\/p>\n
Konfiguration af PostgreSQL<\/h2>\n
<\/p>\n
Indtil nu har vi forestillet os et PostgreSQL-system med synchronous_commit<\/code>, installeret p\u00e5 local<\/code>. For at dette kan realiseres p\u00e5 server siden, skal du indstille to serverkonfigurationsparametre. En anden parameter synchronous_standby_names<\/code> vil tr\u00e6de i kraft, n\u00e5r synchronous_commit<\/code> er i on<\/code>. Det definerer, hvilke replikaer der har ret til synkrone commits, og vi vil indstille den til *<\/code>, hvilket vil betyde, at alle replikaer aktiveres. Disse v\u00e6rdier konfigureres normalt i konfigurationsfilen<\/a><\/noindex> ved at tilf\u00f8je: <\/p>\n
<\/p>\n
synchronous_commit = local  \nsynchronous_standby_names='*'<\/code><\/pre>\n
<\/p>\n
Ved at indstille parameteren synchronous_commit<\/code> til v\u00e6rdien local<\/code>, skaber vi et system, hvor lokale diske forbliver synkrone, men commits til netv\u00e6rksreplikaer som standard er asynkrone. Medmindre vi selvf\u00f8lgelig beslutter at g\u00f8re disse commits synkrone, som vist ovenfor.<\/p>\n
<\/p>\n
Hvis du har fulgt udviklingen af projektet Governor<\/a><\/noindex>, du m\u00e5ske har bem\u00e6rket nogle recente \u00e6ndringer (1<\/a><\/noindex>, 2<\/a><\/noindex>), som har gjort det muligt for brugerne af Governor at teste disse parametre og kontrollere deres konsistens.<\/p>\n
<\/p>\n
Et par ord mere\u2026<\/h2>\n
<\/p>\n
For blot en uge siden ville jeg have sagt, at det var umuligt at finjustere PostgreSQL s\u00e5 pr\u00e6cist. Det var lige da Kurt, medlem af Compose team's platform, insisterede p\u00e5, at der var en mulighed for det. Han tavsede mine indvendinger og fandt i PostgreSQL-dokumentationen f\u00f8lgende<\/a><\/noindex>:<\/p>\n
<\/p>\n
\"PostgreSQL<\/p>\n
<\/p>\n
Denne parameter kan \u00e6ndres n\u00e5r som helst. Adf\u00e6rden for enhver transaktion bestemmes af indstillingen, der g\u00e6lder ved commit. Derfor kan det v\u00e6re nyttigt, at commits for nogle transaktioner foretages synkront, mens de for andre foretages asynkront. For eksempel for at tvinge en multistatement<\/code> transaktion til at udf\u00f8re commits asynkront, n\u00e5r standardv\u00e6rdien for parameteren er den modsatte, skal du indstille <\/em>SET LOCAL synchronous_commit TO OFF<\/code> i transaktionen.<\/em><\/p>\n
<\/p>\n
Med en s\u00e5 lille modification i konfigurationsfilen har vi givet brugerne mulighed for at kontrollere deres konsistens og ydeevne.<\/p>\n
Kilde: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u043e \u0434\u043b\u044f \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432 \u043a\u0443\u0440\u0441\u0430 \u00ab\u0411\u0430\u0437\u044b \u0414\u0430\u043d\u043d\u044b\u0445\u00bb. \u0418\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0434\u0430\u043d\u043d\u043e\u043c \u043d\u0430\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0438? \u041f\u0440\u0438\u0433\u043b\u0430\u0448\u0430\u0435\u043c \u0432\u0430\u0441 \u043d\u0430 \u0414\u0435\u043d\u044c \u041e\u0442\u043a\u0440\u044b\u0442\u044b\u0445 \u0414\u0432\u0435\u0440\u0435\u0439, \u0433\u0434\u0435 \u043c\u044b \u043f\u043e\u0434\u0440\u043e\u0431\u043d\u043e \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0435, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u044f\u0445 \u043e\u043d\u043b\u0430\u0439\u043d-\u0444\u043e\u0440\u043c\u0430\u0442\u0430, \u043a\u043e\u043c\u043f\u0435\u0442\u0435\u043d\u0446\u0438\u044f\u0445 \u0438 \u043a\u0430\u0440\u044c\u0435\u0440\u043d\u044b\u0445 \u043f\u0435\u0440\u0441\u043f\u0435\u043a\u0442\u0438\u0432\u0430\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0436\u0434\u0443\u0442 \u0432\u044b\u043f\u0443\u0441\u043a\u043d\u0438\u043a\u043e\u0432 \u043f\u043e\u0441\u043b\u0435 \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u044f. PostgreSQL \u0438 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438 \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u0438 \u0437\u0430\u043f\u0438\u0441\u0438 \u0434\u043b\u044f \u043a\u0430\u0436\u0434\u043e\u0433\u043e \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u043e\u0433\u043e \u0441\u043e\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u044f \u041d\u0430\u043c \u0432 Compose \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0438\u043c\u0435\u0442\u044c \u0434\u0435\u043b\u043e \u0441\u043e \u043c\u043d\u043e\u0433\u0438\u043c\u0438 \u0431\u0430\u0437\u0430\u043c\u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29395,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39169","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\udd47PostgreSQL og indstillinger for konsistens i skrive til hver specifik forbindelse | ProHoster","description":"Overs\u00e6ttelsen af artiklen er specielt for studerende p\u00e5 kurset 'Database'. Er du interesseret i at udvikle dig inden for dette omr\u00e5de?","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\udd47PostgreSQL \u0438 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438 \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u0438 \u0437\u0430\u043f\u0438\u0441\u0438 \u0434\u043b\u044f \u043a\u0430\u0436\u0434\u043e\u0433\u043e \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u043e\u0433\u043e \u0441\u043e\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u044f | ProHoster","og:description":"\u041f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u043e \u0434\u043b\u044f \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432 \u043a\u0443\u0440\u0441\u0430 \u00ab\u0411\u0430\u0437\u044b \u0414\u0430\u043d\u043d\u044b\u0445\u00bb. \u0418\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0434\u0430\u043d\u043d\u043e\u043c \u043d\u0430\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0438?","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","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:28:14+00:00","article:modified_time":"2019-10-31T19:28:14+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39169","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-24 01:05:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:44","updated":"2026-01-24 01:05:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/39169","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=39169"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/39169\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/29395"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=39169"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=39169"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=39169"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}