{"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\/pt\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","title":{"rendered":"PostgreSQL e configura\u00e7\u00f5es de consist\u00eancia de grava\u00e7\u00e3o para cada conex\u00e3o espec\u00edfica","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A tradu\u00e7\u00e3o do artigo foi preparada especialmente para os alunos do curso \u00abBancos de Dados\u00bb<\/a><\/noindex>. Est\u00e1 interessado em se desenvolver nesta \u00e1rea? Convidamos voc\u00ea para o Dia de Portas Abertas<\/a><\/noindex>, onde explicamos em detalhes sobre o programa, as caracter\u00edsticas do formato online, as compet\u00eancias e as perspectivas de carreira que aguardam os graduados ap\u00f3s a forma\u00e7\u00e3o.<\/em><\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

PostgreSQL e configura\u00e7\u00f5es de consist\u00eancia de grava\u00e7\u00e3o para cada conex\u00e3o espec\u00edfica
\nNa Compose, lidamos com muitos bancos de dados, e isso nos permite conhecer melhor suas funcionalidades e limita\u00e7\u00f5es. \u00c0 medida que aprendemos a apreciar os recursos funcionais de novos bancos de dados, \u00e0s vezes come\u00e7amos a pensar em como seria bom se essas funcionalidades tamb\u00e9m estivessem presentes em ferramentas mais maduras com as quais j\u00e1 trabalhamos h\u00e1 muito tempo. Um dos novos recursos que gostar\u00edamos de ver no PostgreSQL era a consist\u00eancia de grava\u00e7\u00e3o configur\u00e1vel por conex\u00e3o em todo o cluster. E, como se revelou, j\u00e1 temos isso, e hoje queremos compartilhar com voc\u00ea informa\u00e7\u00f5es sobre como voc\u00ea pode us\u00e1-lo.<\/a><\/noindex><\/p>\n

<\/p>\n

Por que isso \u00e9 relevante para mim?<\/h1>\n

<\/p>\n

A forma como o cluster deve se comportar depende do seu aplicativo. Vamos dar um exemplo, um aplicativo de pagamento de contas. Voc\u00ea vai precisar de consist\u00eancia de 100% no cluster, ent\u00e3o ter\u00e1 que habilitar commits s\u00edncronos para que seu banco de dados espere at\u00e9 que todas as mudan\u00e7as sejam feitas. No entanto, se seu aplicativo for uma rede social em r\u00e1pido crescimento, \u00e9 bem prov\u00e1vel que voc\u00ea prefira uma resposta r\u00e1pida em vez de 100% de consist\u00eancia. Para alcan\u00e7ar isso, voc\u00ea pode usar commits ass\u00edncronos em seu cluster.<\/p>\n

<\/p>\n

Conhe\u00e7a, o compromisso<\/h2>\n

<\/p>\n

Voc\u00ea precisar\u00e1 fazer um compromisso entre a consist\u00eancia dos dados e o desempenho. O PostgreSQL avan\u00e7a na dire\u00e7\u00e3o da consist\u00eancia, pois a configura\u00e7\u00e3o padr\u00e3o nesse caso se torna previs\u00edvel e sem surpresas indesejadas. Agora, vamos nos familiarizar com os compromissos.<\/p>\n

<\/p>\n

Compromisso 1: Desempenho<\/h3>\n

<\/p>\n

Se um cluster PostgreSQL n\u00e3o requer consist\u00eancia, ele pode operar de forma ass\u00edncrona. As grava\u00e7\u00f5es s\u00e3o feitas no l\u00edder do cluster, e suas r\u00e9plicas receber\u00e3o as atualiza\u00e7\u00f5es ap\u00f3s alguns milissegundos. Quando o cluster PostgreSQL requer consist\u00eancia, ele deve operar de forma s\u00edncrona. As grava\u00e7\u00f5es ser\u00e3o feitas no l\u00edder do cluster, que enviar\u00e1 as atualiza\u00e7\u00f5es para as r\u00e9plicas e aguardar\u00e1 a confirma\u00e7\u00e3o de que cada uma gravou os dados antes de enviar a confirma\u00e7\u00e3o ao cliente que iniciou a grava\u00e7\u00e3o, informando que foi conclu\u00edda com sucesso. A diferen\u00e7a pr\u00e1tica entre esses m\u00e9todos \u00e9 que o m\u00e9todo ass\u00edncrono requer duas idas pela rede, enquanto o s\u00edncrono requer quatro. <\/p>\n

<\/p>\n

Compromisso 2: Consist\u00eancia<\/h3>\n

<\/p>\n

O resultado em caso de falha do l\u00edder nesses dois abordagens tamb\u00e9m ser\u00e1 diferente. Se o trabalho for executado de forma ass\u00edncrona, ao ocorrer um erro desse tipo, nem todas as grava\u00e7\u00f5es estar\u00e3o confirmadas pelas r\u00e9plicas. Quanto ser\u00e1 perdido? Depende do pr\u00f3prio aplicativo e da efic\u00e1cia da replica\u00e7\u00e3o. A replica\u00e7\u00e3o Compose impedir\u00e1 que a r\u00e9plica se torne o l\u00edder caso a quantidade de informa\u00e7\u00f5es nela seja 1 MB menor do que a do l\u00edder, ou seja, potencialmente at\u00e9 1 MB de grava\u00e7\u00f5es pode ser perdido durante a opera\u00e7\u00e3o ass\u00edncrona. <\/p>\n

<\/p>\n

No modo s\u00edncrono, isso n\u00e3o ocorre. Se o l\u00edder falhar, todas as r\u00e9plicas s\u00e3o atualizadas, pois qualquer grava\u00e7\u00e3o confirmada no l\u00edder deve ser confirmada nas r\u00e9plicas. Aqui est\u00e1 a consist\u00eancia. <\/p>\n

<\/p>\n

O comportamento s\u00edncrono faz sentido em um aplicativo de pagamento de contas, onde a consist\u00eancia tem uma vantagem clara na busca por um compromisso entre consist\u00eancia e desempenho. O mais importante para tal aplicativo s\u00e3o os dados v\u00e1lidos. Agora, lembre-se de uma rede social, na qual a tarefa principal \u00e9 manter a aten\u00e7\u00e3o do usu\u00e1rio, respondendo \u00e0s solicita\u00e7\u00f5es o mais r\u00e1pido poss\u00edvel. Nesse caso, o desempenho com menos idas pela rede e menos espera pelos commits ter\u00e1 prioridade. No entanto, o compromisso entre desempenho e consist\u00eancia n\u00e3o \u00e9 o \u00fanico que deve ser considerado.<\/p>\n

<\/p>\n

Compromisso 3: Falhas<\/h3>\n

<\/p>\n

\u00c9 muito importante entender como um cluster se comporta durante uma falha. Vamos considerar a situa\u00e7\u00e3o em que uma ou mais r\u00e9plicas falham. Quando os commits s\u00e3o processados de forma ass\u00edncrona, o l\u00edder continuar\u00e1 funcionando, ou seja, aceitar\u00e1 e processar\u00e1 entradas sem esperar pelas r\u00e9plicas ausentes. Quando as r\u00e9plicas retornarem ao cluster, elas se alinhar\u00e3o com o l\u00edder. Com a replica\u00e7\u00e3o s\u00edncrona, se as r\u00e9plicas n\u00e3o responderem, o l\u00edder n\u00e3o ter\u00e1 escolha e continuar\u00e1 esperando a confirma\u00e7\u00e3o do commit at\u00e9 que a r\u00e9plica retorne ao cluster e possa aceitar e confirmar a entrada.<\/p>\n

<\/p>\n

Uma conex\u00e3o por transa\u00e7\u00e3o?<\/h2>\n

<\/p>\n

Cada aplica\u00e7\u00e3o necessita de um tipo especial de combina\u00e7\u00e3o entre consist\u00eancia e desempenho. A menos que seja a nossa aplica\u00e7\u00e3o de pagamento de contas, que imaginamos totalmente consistente, ou a nossa quase ef\u00eamera aplica\u00e7\u00e3o de rede social. Em todos os outros casos, haver\u00e1 momentos em que algumas opera\u00e7\u00f5es devem ser s\u00edncronas e outras ass\u00edncronas. Voc\u00ea pode n\u00e3o querer que o sistema espere at\u00e9 que uma mensagem enviada no chat seja confirmada, mas se nesse mesmo aplicativo um pagamento estiver em andamento, ent\u00e3o a espera ser\u00e1 necess\u00e1ria.<\/p>\n

<\/p>\n

Todas essas decis\u00f5es, claro, s\u00e3o tomadas pelo desenvolvedor da aplica\u00e7\u00e3o. Decidir corretamente quando aplicar uma abordagem ou outra ajudar\u00e1 a extrair o m\u00e1ximo do cluster. \u00c9 importante que o desenvolvedor possa alternar entre elas no n\u00edvel do SQL para conex\u00f5es e para transa\u00e7\u00f5es. <\/p>\n

<\/p>\n

Implementando controle na pr\u00e1tica<\/h2>\n

<\/p>\n

Por padr\u00e3o, o PostgreSQL garante consist\u00eancia. Isso \u00e9 controlado pela configura\u00e7\u00e3o do servidor synchronous_commit<\/code>. Por padr\u00e3o, ele est\u00e1 definido como ativado<\/code>, mas possui outras tr\u00eas op\u00e7\u00f5es: local<\/code>, remote_write<\/code> ou off<\/code>.<\/p>\n

<\/p>\n

Ao definir o par\u00e2metro como off<\/code> todas as confirma\u00e7\u00f5es s\u00edncronas s\u00e3o interrompidas, mesmo no sistema local. O par\u00e2metro em local define o modo s\u00edncrono para o sistema local, mas as entradas nas r\u00e9plicas s\u00e3o feitas de forma ass\u00edncrona. Remote_write<\/code> vai ainda mais longe: as entradas nas r\u00e9plicas s\u00e3o feitas de forma ass\u00edncrona, mas retornam quando a r\u00e9plica aceita a entrada, mas n\u00e3o a gravou no disco.<\/p>\n

<\/p>\n

Considerando o conjunto de op\u00e7\u00f5es dispon\u00edvel, escolhemos o comportamento e, lembrando que ativado<\/code> \u2014 s\u00e3o entradas s\u00edncronas, escolheremos local<\/code> para commits ass\u00edncronos pela rede, mantendo os commits locais s\u00edncronos.<\/p>\n

<\/p>\n

Agora, vamos mostrar como configurar isso em um instante, mas imagine que instalamos synchronous_commit<\/code> em local<\/code> para o servidor. N\u00f3s nos perguntamos se \u00e9 poss\u00edvel alterar o par\u00e2metro synchronous_commit<\/code> em tempo real, e descobrimos que n\u00e3o s\u00f3 \u00e9 poss\u00edvel, como existem dois m\u00e9todos para isso. O primeiro \u00e9 definir a sess\u00e3o da sua conex\u00e3o da seguinte forma:<\/p>\n

<\/p>\n

SET SESSION synchronous_commit TO ON;  \n\/\/ Suas grava\u00e7\u00f5es v\u00e3o aqui<\/code><\/pre>\n
<\/p>\n
Todos os registros subsequentes na sess\u00e3o confirmar\u00e3o as opera\u00e7\u00f5es de grava\u00e7\u00e3o para as r\u00e9plicas antes de retornar um resultado positivo ao cliente conectado. Se, \u00e9 claro, voc\u00ea n\u00e3o alterar a configura\u00e7\u00e3o synchronous_commit<\/code> novamente. \u00c9 poss\u00edvel omitir a parte SESSION<\/code> no comando, pois ela estar\u00e1 no valor padr\u00e3o.<\/p>\n
<\/p>\n
A segunda op\u00e7\u00e3o \u00e9 boa quando voc\u00ea s\u00f3 quer garantir que est\u00e1 obtendo a replica\u00e7\u00e3o s\u00edncrona para uma transa\u00e7\u00e3o. Em muitos bancos de dados do tipo \"NoSQL\", o conceito de transa\u00e7\u00f5es n\u00e3o existe, mas ele est\u00e1 presente no PostgreSQL. Nesse caso, voc\u00ea inicia uma transa\u00e7\u00e3o e depois configura synchronous_commit<\/code> em ativado<\/code> antes de executar a grava\u00e7\u00e3o para a transa\u00e7\u00e3o. COMMIT<\/code> confirmar\u00e1 a transa\u00e7\u00e3o, usando qualquer valor do par\u00e2metro synchronous_commit<\/code>, que foi definido naquele momento, embora seja melhor definir a vari\u00e1vel com anteced\u00eancia, para garantir que outros desenvolvedores entendam que as grava\u00e7\u00f5es n\u00e3o s\u00e3o ass\u00edncronas.<\/p>\n
<\/p>\n
BEGIN;  \nSET LOCAL synchronous_commit TO ON;  \n\/\/ Suas grava\u00e7\u00f5es v\u00e3o aqui\nCOMMIT;  <\/code><\/pre>\n
<\/p>\n
Todos os commits de transa\u00e7\u00f5es agora ser\u00e3o confirmados como gravados nas r\u00e9plicas antes mesmo da base de dados retornar uma resposta positiva ao cliente conectado.<\/p>\n
<\/p>\n
Configura\u00e7\u00e3o do PostgreSQL<\/h2>\n
<\/p>\n
Antes disso, n\u00f3s imagin\u00e1vamos um sistema PostgreSQL com synchronous_commit<\/code>, definido em local<\/code>. Para que isso seja real do lado do servidor, voc\u00ea precisar\u00e1 definir dois par\u00e2metros de configura\u00e7\u00e3o do servidor. Outro par\u00e2metro synchronous_standby_names<\/code> entrar\u00e1 em vigor quando synchronous_commit<\/code> estiver em ativado<\/code>. Ele define quais r\u00e9plicas t\u00eam permiss\u00e3o para commits s\u00edncronos, e n\u00f3s o configuraremos em *<\/code>, o que significar\u00e1 ativar todas as r\u00e9plicas. Esses valores geralmente s\u00e3o configurados em arquivo de configura\u00e7\u00e3o<\/a><\/noindex> adicionando: <\/p>\n
<\/p>\n
synchronous_commit = local  \nsynchronous_standby_names='*'<\/code><\/pre>\n
<\/p>\n
Definindo o par\u00e2metro synchronous_commit<\/code> como valor local<\/code>, estamos criando um sistema onde os discos locais permanecem s\u00edncronos, mas os commits das r\u00e9plicas de rede s\u00e3o, por padr\u00e3o, ass\u00edncronos. Se, \u00e9 claro, n\u00e3o decidirmos tornar esses commits s\u00edncronos, como mostrado acima.<\/p>\n
<\/p>\n
Se voc\u00ea acompanhou o desenvolvimento do projeto Governor<\/a><\/noindex>, voc\u00ea pode ter notado algumas mudan\u00e7as recentes (1<\/a><\/noindex>, 2<\/a><\/noindex>), que permitiu aos usu\u00e1rios do Governor testar esses par\u00e2metros e controlar sua consist\u00eancia.<\/p>\n
<\/p>\n
Mais algumas palavras\u2026<\/h2>\n
<\/p>\n
Literalmente, uma semana atr\u00e1s, eu diria que n\u00e3o era poss\u00edvel ajustar t\u00e3o finamente o PostgreSQL. Foi ent\u00e3o que Kurt, membro da equipe da plataforma Compose, insistiu que essa possibilidade existia. Ele acalmou minhas obje\u00e7\u00f5es e encontrou na documenta\u00e7\u00e3o do PostgreSQL o seguinte<\/a><\/noindex>:<\/p>\n
<\/p>\n
\"PostgreSQL<\/p>\n
<\/p>\n
Esse par\u00e2metro pode ser alterado a qualquer momento. O comportamento de qualquer transa\u00e7\u00e3o \u00e9 determinado pela configura\u00e7\u00e3o em vigor no momento do commit. Portanto, pode ser \u00fatil que alguns commits de transa\u00e7\u00f5es sejam feitos de forma s\u00edncrona, enquanto outros o sejam de forma ass\u00edncrona. Por exemplo, para fazer uma multistatement<\/code> transa\u00e7\u00e3o realizar commits de forma ass\u00edncrona, quando o valor padr\u00e3o do par\u00e2metro \u00e9 oposto, defina <\/em>SET LOCAL synchronous_commit TO OFF<\/code> na transa\u00e7\u00e3o.<\/em><\/p>\n
<\/p>\n
Com essa pequena modifica\u00e7\u00e3o no arquivo de configura\u00e7\u00e3o, concedemos aos usu\u00e1rios o controle sobre sua consist\u00eancia e desempenho.<\/p>\n
Fonte: 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 e configura\u00e7\u00f5es de consist\u00eancia de grava\u00e7\u00e3o para cada conex\u00e3o espec\u00edfica | ProHoster","description":"A tradu\u00e7\u00e3o do artigo foi preparada especialmente para os alunos do curso 'Bancos de Dados'. Est\u00e1 interessado em se desenvolver nessa \u00e1rea?","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/39169","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=39169"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/39169\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/29395"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=39169"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=39169"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=39169"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}