{"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\/nl\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","title":{"rendered":"PostgreSQL en de instellingen voor de consistentie van schrijfacties voor elke specifieke verbinding","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><em>De vertaling van het artikel is speciaal voorbereid voor studenten van de cursus <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/jCX0\/\">Databases<\/a><\/noindex>. Wil je je in deze richting ontwikkelen? We nodigen je uit voor de <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/jCX0\/\">Open Dag<\/a><\/noindex>, waar we uitgebreid uitleggen over het programma, de kenmerken van het online formaat, de vaardigheden en carri\u00e8remogelijkheden die afgestudeerden na de opleiding te wachten staan.<\/em><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"PostgreSQL en de instellingen voor de consistentie van schrijfacties voor elke specifieke verbinding\" src=\"\/wp-content\/uploads\/2019\/10\/e69e30ba059af157f021c9cb33a59f51.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>PostgreSQL en de instellingen voor de consistentie van schrijfacties voor elke specifieke verbinding<br \/>\nBij Compose hebben we te maken met veel databases, wat ons de kans geeft om beter kennis te maken met hun functionaliteit en tekortkomingen. Terwijl we leren de functionele kenmerken van nieuwe databases te waarderen, denken we soms na over hoe prettig het zou zijn als dergelijke functies ook aanwezig waren in de meer volwassen tools waarmee we al lange tijd werken. Een van de nieuwe functies die we in PostgreSQL wilden zien, was instelbare consistentie van schrijfoperaties per verbinding in het hele cluster. En het blijkt dat we die al hebben, en vandaag willen we je vertellen hoe je deze kunt gebruiken.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p><\/p>\n<h1 id=\"zachem-mne-eto\">Waarom heb ik dit nodig?<\/h1>\n<p><\/p>\n<p>De manier waarop het cluster zich gedraagt, hangt af van je applicatie. Neem bijvoorbeeld een applicatie voor het betalen van rekeningen. Je hebt honderd procent consistentie in het cluster nodig, dus moet je synchronisatiecommits inschakelen, zodat je database wacht totdat alle wijzigingen zijn doorgevoerd. Maar als je applicatie een snelgroeiend sociaal netwerk is, geef je waarschijnlijk de voorkeur aan een snelle respons boven honderd procent consistentie. Om dit te bereiken, kun je asynchrone commits in je cluster gebruiken.<\/p>\n<p><\/p>\n<h2 id=\"znakomtes-kompromiss\">Maak kennis met de compromis<\/h2>\n<p><\/p>\n<p>Je moet een compromis sluiten tussen dataconsistentie en prestatie. PostgreSQL verschuift van consistentie, aangezien de standaardconfiguratie in dit geval voorspelbaar en zonder onverwachte verrassingen is. Laten we nu de compromissen verkennen.<\/p>\n<p><\/p>\n<h3 id=\"kompromiss-1-proizvoditelnost\">Compromis 1: Prestatie<\/h3>\n<p><\/p>\n<p>Als een PostgreSQL-cluster geen consistentie vereist, kan het vrij goed asynchroon werken. Schrijven gebeurt op de leider van het cluster, en zijn replica's ontvangen na enkele milliseconden de updates. Wanneer een PostgreSQL-cluster consistentie vereist, moet het synchroon werken. Het schrijven gebeurt op de clusterleider, die de updates naar de replica's verstuurt en wacht op bevestiging dat elke replica de opname heeft gedaan voordat de leider een bevestiging naar de cli\u00ebnt stuurt die de opname heeft ge\u00efnitieerd, dat deze succesvol was. Het praktische verschil tussen deze benaderingen is dat de asynchrone methode twee netwerkhops vereist, terwijl de synchrone vier vereist. <\/p>\n<p><\/p>\n<h3 id=\"kompromiss-2-soglasovannost\">Compromis 2: Consistentie<\/h3>\n<p><\/p>\n<p>Het resultaat in het geval van een falen van de leider in deze twee benaderingen zal ook verschillend zijn. Als de verwerking asynchroon is, zullen niet alle opnames door de replica's zijn bevestigd bij het optreden van een dergelijke fout. Hoeveel gaat er verloren? Dit hangt af van de applicatie zelf en de effici\u00ebntie van de replicatie. De Compose-replicatie voorkomt dat een replica leider wordt als de hoeveelheid informatie daarin 1 MB minder is dan die van de leider, wat betekent dat er potentieel tot 1 MB aan opnames verloren kan gaan bij asynchroon werken. <\/p>\n<p><\/p>\n<p>In de synchrone modus gebeurt dit niet. Als de leider faalt, worden alle replica's bijgewerkt, omdat elke opname die op de leider is bevestigd, ook in de replica's moet worden bevestigd. Dat is consistentie. <\/p>\n<p><\/p>\n<p>Synchrone werking is zinvol in een applicatie voor factuurbetalingen, waar consistentie een duidelijk voordeel heeft bij het zoeken naar een compromis tussen consistentie en prestaties. Het belangrijkste voor zo'n applicatie zijn geldige gegevens. En denk nu aan een sociaal netwerk waar de belangrijkste taak is om de aandacht van de gebruiker vast te houden door aanvragen zo snel mogelijk te beantwoorden. In dat geval hebben prestaties met minder netwerk-hops en minder wachttijd voor bevestigingen prioriteit. Maar het compromis tussen prestaties en consistentie is niet de enige waarover moet worden nagedacht.<\/p>\n<p><\/p>\n<h3 id=\"kompromiss-3-sboi\">Compromis 3: Falen<\/h3>\n<p><\/p>\n<p>Het is belangrijk om te begrijpen hoe een cluster zich gedraagt tijdens een storing. Laten we de situatie bekijken waarin \u00e9\u00e9n of meer replicas falen. Wanneer commits asynchroon worden verwerkt, blijft de leader functioneren, dat wil zeggen, hij blijft records accepteren en verwerken zonder te wachten op ontbrekende replicas. Wanneer de replicas terugkeren naar het cluster, halen ze de leader in. Bij synchronisatie van replicas, als de replicas niet reageren, heeft de leader geen keuze en blijft hij wachten op bevestiging van de commit totdat de replica terugkeert naar het cluster en de record kan accepteren en bevestigen.<\/p>\n<p><\/p>\n<h2 id=\"po-odnomu-soedineniyu-na-tranzakciyu\">E\u00e9n verbinding per transactie?<\/h2>\n<p><\/p>\n<p>Elk applicatie heeft een specifieke combinatie van consistentie en prestaties nodig. Tenzij het natuurlijk onze factureringsapplicatie is, die we volledig consistent voorstellen, of onze bijna ongrijpbare sociale media-app. In alle andere gevallen zullen er momenten zijn waarop sommige operaties synchroon moeten zijn en sommige asynchroon. Je wilt misschien niet dat het systeem wacht totdat een bericht dat in de chat is verzonden is gecommit, maar als er in dezelfde applicatie een betaling plaatsvindt, moet je wel wachten.<\/p>\n<p><\/p>\n<p>Al deze beslissingen worden uiteraard door de applicatieontwikkelaar genomen. De juiste keuzes over wanneer welke aanpak toe te passen helpen om het meeste uit het cluster te halen. Het is belangrijk dat de ontwikkelaar kan schakelen tussen deze op het SQL-niveau voor verbindingen en voor transacties. <\/p>\n<p><\/p>\n<h2 id=\"obespechenie-kontrolya-na-praktike\">Het waarborgen van controle in de praktijk<\/h2>\n<p><\/p>\n<p>Standaard zorgt PostgreSQL voor consistentie. Dit wordt gecontroleerd door de serverparameter <code>synchronous_commit<\/code>. Standaard staat deze op <code>on<\/code>, maar er zijn drie andere opties: <code>local<\/code>, <code>remote_write<\/code> of <code>off<\/code>.<\/p>\n<p><\/p>\n<p>Wanneer de parameter wordt ingesteld op <code>off<\/code> worden alle synchrone commits gestopt, zelfs in het lokale systeem. De parameter in local definieert de synchrone modus voor het lokale systeem, maar de records naar de replicas worden asynchroon uitgevoerd. <code>Remote_write<\/code> gaat nog verder: records naar de replicas worden asynchroon verzonden, maar worden teruggestuurd wanneer de replica de record heeft geaccepteerd, maar deze nog niet op schijf heeft geschreven.<\/p>\n<p><\/p>\n<p>Bij het overwegen van de beschikbare opties, kiezen we het gedrag en, ons herinnerend dat <code>on<\/code> \u2013 dit zijn synchrone records, kiezen we <code>local<\/code> voor asynchrone commits over het netwerk, terwijl we lokale commits synchroon laten.<\/p>\n<p><\/p>\n<p>Nu zullen we je vertellen hoe je dit in een oogwenk kunt instellen, maar stel je voor dat we <code>synchronous_commit<\/code> in <code>local<\/code> voor de server hebben ge\u00efnstalleerd. We vroegen ons af of we de parameter <code>synchronous_commit<\/code> on-the-fly konden wijzigen, en het bleek dat dit niet alleen mogelijk is, er zijn zelfs twee manieren om dit te doen. De eerste is om de sessie van je verbinding als volgt in te stellen:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">SET SESSION synchronous_commit TO ON;  \n\/\/ Je schijft hier<\/code><\/pre>\n<p><\/p>\n<p>Alle daaropvolgende schrijfbewerkingen in de sessie zullen de schrijfoperaties voor de replicaties bevestigen voordat ze een positieve return aan de aangesloten client geven. Tenzij je natuurlijk de instelling <code>synchronous_commit<\/code> opnieuw wijzigt. Je kunt het deel <code>SESSION<\/code> in de opdracht weglaten, aangezien deze op de standaardwaarde zal staan.<\/p>\n<p><\/p>\n<p>De tweede methode is goed wanneer je gewoon wilt verzekeren dat je synchrone replicatie voor \u00e9\u00e9n transactie krijgt. In veel 'NoSQL'-databases bestaat het begrip transactie niet, maar het is wel aanwezig in PostgreSQL. In dit geval start je een transactie en stel je vervolgens in <code>synchronous_commit<\/code> in <code>on<\/code> in voordat je een schrijfoperatie voor de transactie uitvoert. <code>COMMIT<\/code> zal de transactie vastleggen, met welk waardeparameter <code>synchronous_commit<\/code>, dat op dat moment is ingesteld, hoewel het beter is om de variabele van tevoren in te stellen, zodat andere ontwikkelaars begrijpen dat de schrijfbewerkingen niet asynchroon zijn.<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">BEGIN;  \nSET LOCAL synchronous_commit TO ON;  \n\/\/ Je schijft hier\nCOMMIT;  <\/code><\/pre>\n<p><\/p>\n<p>Alle commits van transacties zullen nu worden bevestigd als geschreven naar de replicaties nog voordat de database een positieve reactie aan de aangesloten client teruggeeft.<\/p>\n<p><\/p>\n<h2 id=\"nastroyka-postgresql\">Configuratie van PostgreSQL<\/h2>\n<p><\/p>\n<p>Daarvoor hebben we ons een PostgreSQL-systeem voorgesteld met <code>synchronous_commit<\/code>, ingesteld op <code>local<\/code>. Om dit realistisch te maken aan de serverzijde, moet je twee serverconfiguratieparameters instellen. Een andere parameter <code>synchronous_standby_names<\/code> zal van kracht worden wanneer <code>synchronous_commit<\/code> in <code>on<\/code>. Het definieert welke replicaties recht hebben op synchroniseerde commits, en we zullen het instellen op <code>*<\/code>, wat betekent dat alle replicaties betrokken worden. Deze waarden worden meestal ingesteld in <noindex><a rel=\"nofollow\" href=\"http:\/\/www.postgresql.org\/docs\/9.4\/static\/config-setting.html#CONFIG-SETTING-CONFIGURATION-FILE\">het configuratiebestand<\/a><\/noindex> door toe te voegen: <\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">synchronous_commit = local  \nsynchronous_standby_names='*'<\/code><\/pre>\n<p><\/p>\n<p>Door de parameter in te stellen op <code>synchronous_commit<\/code> op de waarde van <code>local<\/code>, cre\u00ebren we een systeem waarin lokale schijven synchron zijn, maar de commits van netwerkreplicaties standaard asynchroon zijn. Tenzij we natuurlijk besluiten om deze commits synchron te maken, zoals hierboven aangegeven.<\/p>\n<p><\/p>\n<p>Als je de ontwikkeling van <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/compose\/governor\">project Governor hebt gevolgd<\/a><\/noindex>, u hebt misschien enkele recente wijzigingen opgemerkt (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/compose\/governor\/commit\/87f18c01f150b3f1b6f948e852c7add2949f7360\">1<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/compose\/governor\/commit\/dcbe849d33c535b1522ce767803cb77a3ac91a7e\">2<\/a><\/noindex>), die gebruikers in staat stelden om deze parameters te testen en hun consistentie te controleren.<\/p>\n<p><\/p>\n<h2 id=\"esche-para-slov\">Nog een paar woorden\u2026<\/h2>\n<p><\/p>\n<p>Letterlijk een week geleden zou ik u hebben verteld dat het onmogelijk is om PostgreSQL zo fijn te tunen. Precies toen drong Kurt, lid van het Compose-platformteam, erop aan dat deze mogelijkheid er wel is. Hij kalmeerde mijn bezwaren en vond in de PostgreSQL-documentatie <noindex><a rel=\"nofollow\" href=\"http:\/\/www.postgresql.org\/docs\/devel\/static\/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT\">het volgende<\/a><\/noindex>:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"PostgreSQL en de instellingen voor de consistentie van schrijfacties voor elke specifieke verbinding\" src=\"\/wp-content\/uploads\/2019\/10\/e77e97e588fa3d1e8acbe5de0e26436a.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><em>Deze parameter kan op elk moment worden gewijzigd. Het gedrag van een transactie wordt bepaald door de instelling die van kracht is bij het committen. Daarom kan het nuttig zijn dat voor sommige transacties commits synchroon plaatsvinden, terwijl voor andere dit asynchroon gebeurd. Bijvoorbeeld om \u00e9\u00e9n <code>multistatement<\/code> transactie asynchroon commits te laten uitvoeren, wanneer de standaardparameter het tegenovergestelde is, stelt u <\/em><code>SET LOCAL synchronous_commit TO OFF<\/code> <em>in de transactie.<\/em><\/p>\n<p><\/p>\n<p>Met zo'n kleine aanpassing in het configuratiebestand hebben we gebruikers de mogelijkheid gegeven om hun consistentie en prestaties te controleren.<\/p>\n<p>Bron: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/472364\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\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 [&hellip;]<\/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<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\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?\" \/>\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\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya\" \/>\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\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\" \/>\n\t\t<meta property=\"og:description\" content=\"\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?\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya\" \/>\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=\"2019-10-31T19:28:14+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:28:14+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\udd47PostgreSQL en afstemming van de consistentie van records voor elke specifieke verbinding | ProHoster","description":"De vertaling van het artikel is speciaal voorbereid voor studenten van de cursus 'Databases'. Ge\u00efnteresseerd in ontwikkeling in dit domein?","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","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\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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/39169","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=39169"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/39169\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/29395"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=39169"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=39169"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=39169"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}