{"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\/fr\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","title":{"rendered":"PostgreSQL et les param\u00e8tres de coh\u00e9rence d'\u00e9criture pour chaque connexion sp\u00e9cifique","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La traduction de l'article a \u00e9t\u00e9 pr\u00e9par\u00e9e sp\u00e9cialement pour les \u00e9tudiants du cours \u00abBases de Donn\u00e9es\u00bb<\/a><\/noindex>. Vous \u00eates int\u00e9ress\u00e9 \u00e0 vous d\u00e9velopper dans ce domaine ? Nous vous invitons \u00e0 notre Journ\u00e9e Portes Ouvertes<\/a><\/noindex>, o\u00f9 nous expliciterons le programme, les particularit\u00e9s du format en ligne, les comp\u00e9tences et les perspectives de carri\u00e8re qui attendent les dipl\u00f4m\u00e9s apr\u00e8s leur formation.<\/em><\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

PostgreSQL et les param\u00e8tres de coh\u00e9rence d'\u00e9criture pour chaque connexion sp\u00e9cifique
\nChez Compose, nous travaillons avec de nombreuses bases de donn\u00e9es, ce qui nous permet de mieux conna\u00eetre leurs fonctionnalit\u00e9s et leurs inconv\u00e9nients. Au fur et \u00e0 mesure que nous apprenons \u00e0 appr\u00e9cier les caract\u00e9ristiques fonctionnelles des nouvelles bases de donn\u00e9es, nous commen\u00e7ons parfois \u00e0 nous demander ce que ce serait bien si de telles fonctionnalit\u00e9s \u00e9taient \u00e9galement pr\u00e9sentes dans des outils plus matures avec lesquels nous travaillons depuis longtemps. Une des nouvelles fonctionnalit\u00e9s que nous aurions aim\u00e9 voir dans PostgreSQL \u00e9tait une coh\u00e9rence de l'enregistrement param\u00e9trable par connexion dans tout le cluster. Et il s'av\u00e8re que c'est d\u00e9j\u00e0 le cas, et aujourd'hui, nous souhaitons partager avec vous des informations sur la fa\u00e7on dont vous pouvez l'utiliser.<\/a><\/noindex><\/p>\n

<\/p>\n

Pourquoi est-ce important ?<\/h1>\n

<\/p>\n

Le comportement du cluster d\u00e9pend de votre application. Prenons par exemple une application de paiement de factures. Vous aurez besoin d'une coh\u00e9rence \u00e0 100 % dans le cluster, donc vous devrez activer les engagements synchrones pour que votre base de donn\u00e9es attende que toutes les modifications soient effectu\u00e9es. Toutefois, si votre application est un r\u00e9seau social en pleine expansion, vous pr\u00e9f\u00e9rerez certainement un temps de r\u00e9ponse rapide \u00e0 la coh\u00e9rence \u00e0 100 %. Pour y parvenir, vous pouvez utiliser des engagements asynchrones dans votre cluster.<\/p>\n

<\/p>\n

Voici le compromis<\/h2>\n

<\/p>\n

Vous devrez faire un compromis entre la coh\u00e9rence des donn\u00e9es et la performance. PostgreSQL tend vers la coh\u00e9rence, car la configuration par d\u00e9faut dans ce cas est pr\u00e9visible et sans surprises inattendues. Maintenant, d\u00e9couvrons ces compromis.<\/p>\n

<\/p>\n

Compromis 1 : Performance<\/h3>\n

<\/p>\n

Si le cluster PostgreSQL ne n\u00e9cessite pas de coh\u00e9rence, il peut fonctionner de mani\u00e8re asynchrone. L'\u00e9criture se fait sur le leader du cluster, et ses r\u00e9pliques recevront les mises \u00e0 jour apr\u00e8s quelques millisecondes. Lorsque le cluster PostgreSQL exige la coh\u00e9rence, il doit fonctionner de mani\u00e8re synchrone. L'\u00e9criture sera effectu\u00e9e dans le leader du cluster, qui enverra la mise \u00e0 jour aux r\u00e9pliques et attendra la confirmation que chacune d'elles a enregistr\u00e9 ces donn\u00e9es, avant d'envoyer une confirmation au client qui a initi\u00e9 l'\u00e9criture, informant que celle-ci a \u00e9t\u00e9 effectu\u00e9e avec succ\u00e8s. La diff\u00e9rence pratique entre ces approches r\u00e9side dans le fait que la m\u00e9thode asynchrone n\u00e9cessite deux sauts r\u00e9seau, tandis que la synchronisation en n\u00e9cessite quatre. <\/p>\n

<\/p>\n

Compromis 2 : Coh\u00e9rence<\/h3>\n

<\/p>\n

Le r\u00e9sultat en cas de d\u00e9faillance du leader dans ces deux approches sera \u00e9galement diff\u00e9rent. Si le traitement s'effectue de mani\u00e8re asynchrone, lors d'une telle erreur, toutes les \u00e9critures ne seront pas enregistr\u00e9es par les r\u00e9pliques. Combien seront perdues ? Cela d\u00e9pend de l'application elle-m\u00eame et de l'efficacit\u00e9 de la r\u00e9plication. La r\u00e9plication Compose emp\u00eachera une r\u00e9plique de devenir leader si la quantit\u00e9 d'informations qu'elle contient est inf\u00e9rieure de 1 Mo \u00e0 celle du leader, ce qui signifie qu'il pourrait potentiellement y avoir jusqu'\u00e0 1 Mo d'\u00e9critures perdues en cas de fonctionnement asynchrone. <\/p>\n

<\/p>\n

En mode synchrone, cela ne se produit pas. Si le leader \u00e9choue, toutes les r\u00e9pliques se mettent \u00e0 jour, puisque toute \u00e9criture valid\u00e9e sur le leader doit \u00e9galement \u00eatre confirm\u00e9e dans les r\u00e9pliques. Voil\u00e0 ce qu'est la coh\u00e9rence. <\/p>\n

<\/p>\n

Le comportement synchrone a du sens \u00e0 utiliser dans une application de paiement de factures, o\u00f9 la coh\u00e9rence a un avantage \u00e9vident dans la recherche d'un compromis entre coh\u00e9rence et performance. La chose la plus importante pour une telle application est des donn\u00e9es valides. Pensez maintenant \u00e0 un r\u00e9seau social, o\u00f9 l'objectif principal est de capter l'attention de l'utilisateur en r\u00e9pondant aux demandes le plus rapidement possible. Dans ce cas, la performance, avec moins de sauts r\u00e9seaux et moins d'attente pour les commits, sera prioritaire. Cependant, le compromis entre performance et coh\u00e9rence n'est pas le seul auquel il faut penser.<\/p>\n

<\/p>\n

Compromis 3 : Pannes<\/h3>\n

<\/p>\n

Il est tr\u00e8s important de comprendre comment un cluster se comporte en cas de d\u00e9faillance. Consid\u00e9rons la situation o\u00f9 une ou plusieurs r\u00e9pliques \u00e9chouent. Lorsque les validations sont trait\u00e9es de mani\u00e8re asynchrone, le leader continuera \u00e0 fonctionner, c'est-\u00e0-dire \u00e0 accepter et \u00e0 traiter des enregistrements sans attendre les r\u00e9pliques manquantes. Lorsque les r\u00e9pliques reviennent dans le cluster, elles rattrapent le leader. Avec la r\u00e9plication synchronis\u00e9e, si les r\u00e9pliques ne r\u00e9pondent pas, le leader n'aura d'autre choix que de continuer \u00e0 attendre la confirmation de la validation jusqu'\u00e0 ce que la r\u00e9plique revienne dans le cluster et puisse accepter et confirmer l'enregistrement.<\/p>\n

<\/p>\n

Une connexion par transaction ?<\/h2>\n

<\/p>\n

Chaque application a besoin d'un type particulier de combinaison entre coh\u00e9rence et performance. \u00c0 moins qu'il ne s'agisse de notre application de paiement de factures, que nous consid\u00e9rons comme enti\u00e8rement coh\u00e9rente, ou de notre application de r\u00e9seau social presque \u00e9ph\u00e9m\u00e8re. Dans tous les autres cas, il y aura des moments o\u00f9 certaines op\u00e9rations doivent \u00eatre synchrones et d'autres asynchrones. Vous ne voudrez peut-\u00eatre pas que le syst\u00e8me attende que le message envoy\u00e9 dans le chat soit valid\u00e9, mais si un paiement se d\u00e9roule dans la m\u00eame application, il faudra attendre.<\/p>\n

<\/p>\n

Toutes ces d\u00e9cisions, bien s\u00fbr, sont prises par le d\u00e9veloppeur de l'application. Les bonnes d\u00e9cisions quant \u00e0 quand appliquer telle ou telle approche aideront \u00e0 tirer le meilleur parti du cluster. Il est important que le d\u00e9veloppeur puisse passer d'une m\u00e9thode \u00e0 l'autre au niveau SQL pour les connexions et pour les transactions. <\/p>\n

<\/p>\n

Assurer le contr\u00f4le en pratique<\/h2>\n

<\/p>\n

Par d\u00e9faut, PostgreSQL garantit la coh\u00e9rence. Cela est contr\u00f4l\u00e9 par le param\u00e8tre du serveur synchronous_commit<\/code>. Par d\u00e9faut, il est en position on<\/code>, mais il a trois autres options : local<\/code>, remote_write<\/code> ou off<\/code>.<\/p>\n

<\/p>\n

En r\u00e9glant le param\u00e8tre sur off<\/code> tous les commits synchrones sont arr\u00eat\u00e9s, m\u00eame dans le syst\u00e8me local. Le param\u00e8tre local d\u00e9termine le mode synchrone pour le syst\u00e8me local, mais les enregistrements dans les r\u00e9pliques sont effectu\u00e9s de mani\u00e8re asynchrone. Remote_write<\/code> va encore plus loin : les enregistrements dans les r\u00e9pliques sont effectu\u00e9s de mani\u00e8re asynchrone, mais sont renvoy\u00e9s lorsque la r\u00e9plique a accept\u00e9 l'enregistrement, mais ne l'a pas \u00e9crit sur le disque.<\/p>\n

<\/p>\n

En consid\u00e9rant la gamme d'options disponibles, nous choisissons le comportement et, en gardant \u00e0 l'esprit que on<\/code> sont des enregistrements synchrones, nous choisirons local<\/code> pour les commits asynchrones sur le r\u00e9seau, tout en gardant les commits locaux synchrones.<\/p>\n

<\/p>\n

Nous allons maintenant vous expliquer comment configurer cela en un rien de temps, mais imaginez que nous avons install\u00e9 synchronous_commit<\/code> dans local<\/code> pour le serveur. Nous nous sommes demand\u00e9 s'il \u00e9tait possible de modifier le param\u00e8tre synchronous_commit<\/code> \u00e0 la vol\u00e9e, et il s'av\u00e8re que ce n'est pas seulement possible, il existe m\u00eame deux fa\u00e7ons de le faire. La premi\u00e8re consiste \u00e0 d\u00e9finir la session de votre connexion de la mani\u00e8re suivante:<\/p>\n

<\/p>\n

SET SESSION synchronous_commit TO ON;  \n\/\/ Vos \u00e9critures vont ici<\/code><\/pre>\n
<\/p>\n
Tous les enregistrements ult\u00e9rieurs dans la session confirmeront les op\u00e9rations d'\u00e9criture pour les r\u00e9plicas avant de renvoyer un r\u00e9sultat positif au client connect\u00e9. Bien s\u00fbr, \u00e0 moins que vous ne changiez \u00e0 nouveau le param\u00e8tre synchronous_commit<\/code> . Vous pouvez omettre la partie SESSION<\/code> dans la commande, car elle prendra la valeur par d\u00e9faut.<\/p>\n
<\/p>\n
La deuxi\u00e8me m\u00e9thode est utile lorsque vous souhaitez simplement vous assurer que vous obtenez une r\u00e9plication synchrone pour une transaction. Dans de nombreuses bases de donn\u00e9es de g\u00e9n\u00e9ration \u00ab NoSQL \u00bb, le concept de transaction n'existe pas, mais il existe dans PostgreSQL. Dans ce cas, vous lancez une transaction, puis vous d\u00e9finissez synchronous_commit<\/code> dans on<\/code> avant d'ex\u00e9cuter l'\u00e9criture pour la transaction. COMMIT<\/code> enregistrera la transaction en utilisant n'importe quelle valeur du param\u00e8tre synchronous_commit<\/code>, qui a \u00e9t\u00e9 d\u00e9finie \u00e0 ce moment-l\u00e0, bien qu'il soit pr\u00e9f\u00e9rable de d\u00e9finir la variable \u00e0 l'avance afin de s'assurer que d'autres d\u00e9veloppeurs comprennent que les enregistrements ne sont pas asynchrones.<\/p>\n
<\/p>\n
BEGIN;  \nSET LOCAL synchronous_commit TO ON;  \n\/\/ Vos \u00e9critures vont ici\nCOMMIT;  <\/code><\/pre>\n
<\/p>\n
Tous les engagements de transactions seront d\u00e9sormais confirm\u00e9s, comme s'ils \u00e9taient \u00e9crits dans les r\u00e9plicas avant m\u00eame que la base de donn\u00e9es ne renvoie une r\u00e9ponse positive au client connect\u00e9.<\/p>\n
<\/p>\n
Configuration de PostgreSQL<\/h2>\n
<\/p>\n
Auparavant, nous avions en t\u00eate un syst\u00e8me PostgreSQL avec synchronous_commit<\/code>, install\u00e9 sur local<\/code>. Pour que cela soit r\u00e9el du c\u00f4t\u00e9 serveur, vous devrez d\u00e9finir deux param\u00e8tres de configuration du serveur. Un autre param\u00e8tre synchronous_standby_names<\/code> entrera en vigueur lorsque synchronous_commit<\/code> sera dans on<\/code>. Il d\u00e9finit quelles r\u00e9plicas sont autoris\u00e9es \u00e0 effectuer des engagements synchrones, et nous allons le configurer \u00e0 *<\/code>, ce qui signifiera impliquer tous les r\u00e9plicas. Ces valeurs sont g\u00e9n\u00e9ralement configur\u00e9es dans le fichier de configuration<\/a><\/noindex> en ajoutant : <\/p>\n
<\/p>\n
synchronous_commit = local  \nsynchronous_standby_names='*'<\/code><\/pre>\n
<\/p>\n
En d\u00e9finissant le param\u00e8tre synchronous_commit<\/code> \u00e0 la valeur local<\/code>, nous cr\u00e9ons un syst\u00e8me dans lequel les disques locaux restent synchrones, mais les engagements des r\u00e9plicas r\u00e9seau sont par d\u00e9faut asynchrones. \u00c0 moins, bien s\u00fbr, que nous ne d\u00e9cidions de rendre ces engagements synchrones, comme montr\u00e9 ci-dessus.<\/p>\n
<\/p>\n
Si vous avez suivi l'\u00e9volution du projet Governor<\/a><\/noindex>, vous avez peut-\u00eatre remarqu\u00e9 quelques changements r\u00e9cents (1<\/a><\/noindex>, 2<\/a><\/noindex>), qui ont permis aux utilisateurs de Governor de tester ces param\u00e8tres et de contr\u00f4ler leur coh\u00e9rence.<\/p>\n
<\/p>\n
Encore quelques mots\u2026<\/h2>\n
<\/p>\n
Il y a tout juste une semaine, je vous aurais dit qu'il \u00e9tait impossible de r\u00e9gler PostgreSQL aussi finement. C'est alors que Kurt, membre de l'\u00e9quipe de la plateforme Compose, a insist\u00e9 sur le fait qu'une telle possibilit\u00e9 existait. Il a apais\u00e9 mes objections et a trouv\u00e9 dans la documentation de PostgreSQL ce qui suit<\/a><\/noindex>:<\/p>\n
<\/p>\n
\"PostgreSQL<\/p>\n
<\/p>\n
Ce param\u00e8tre peut \u00eatre modifi\u00e9 \u00e0 tout moment. Le comportement de toute transaction est d\u00e9termin\u00e9 par le r\u00e9glage en vigueur lors du commit. Il est donc possible et utile que pour certaines transactions, les commits soient effectu\u00e9s de mani\u00e8re synchrone, tandis que pour d'autres, cela se fasse de mani\u00e8re asynchrone. Par exemple, pour forcer un multistatement<\/code> transaction \u00e0 effectuer des commits de mani\u00e8re asynchrone, lorsque la valeur du param\u00e8tre par d\u00e9faut est oppos\u00e9e, d\u00e9finissez <\/em>SET LOCAL synchronous_commit TO OFF<\/code> dans la transaction.<\/em><\/p>\n
<\/p>\n
Avec une telle petite modification dans le fichier de configuration, nous avons donn\u00e9 aux utilisateurs la possibilit\u00e9 de contr\u00f4ler leur coh\u00e9rence et leur performance.<\/p>\n
Source : 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\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 et les param\u00e8tres de coh\u00e9rence des enregistrements pour chaque connexion sp\u00e9cifique | ProHoster","description":"La traduction de l'article a \u00e9t\u00e9 pr\u00e9par\u00e9e sp\u00e9cialement pour les \u00e9tudiants du cours \u00ab Bases de Donn\u00e9es \u00bb. Vous souhaitez vous d\u00e9velopper dans ce domaine ?","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/39169","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=39169"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/39169\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/29395"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=39169"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=39169"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=39169"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}