\u00c9 necess\u00e1rio monitoramento adicional da opera\u00e7\u00e3o do failover, e temos 12 shards PostgreSQL, o que significa que devemos monitorar 12 clusters. Ao aumentar o n\u00famero de shards, n\u00e3o devemos esquecer de atualizar o failover.<\/li>\n<\/ul>\nUm failover personalizado parece muito complicado e exige suporte n\u00e3o trivial. Com um cluster PostgreSQL, esta ser\u00e1 a op\u00e7\u00e3o mais simples, mas n\u00e3o escal\u00e1vel, portanto, n\u00e3o \u00e9 adequada para n\u00f3s.<\/p>\n
Repmgr<\/h3>\n Gerenciador de Replica\u00e7\u00e3o para clusters PostgreSQL, que pode gerenciar o funcionamento do cluster PostgreSQL. Por\u00e9m, n\u00e3o possui failover autom\u00e1tico 'pronto para uso', portanto, ser\u00e1 necess\u00e1rio escrever uma 'camada' personalizada em cima da solu\u00e7\u00e3o existente. Isso pode resultar em algo at\u00e9 mais complicado do que scripts personalizados, por isso nem sequer tentamos o Repmgr.<\/p>\n
AWS RDS<\/h3>\n Suporta tudo o que precisamos, realiza backups e oferece suporte a pool de conex\u00f5es. Possui troca autom\u00e1tica: quando o mestre falha, a r\u00e9plica se torna o novo mestre, e a AWS altera o registro DNS para o novo mestre, enquanto as r\u00e9plicas podem estar em diferentes AZs.<\/p>\n
Entre os pontos negativos, est\u00e1 a falta de configura\u00e7\u00f5es detalhadas. Um exemplo de configura\u00e7\u00f5es detalhadas: nos nossos inst\u00e2ncias, h\u00e1 restri\u00e7\u00f5es para conex\u00f5es tcp, o que, infelizmente, n\u00e3o pode ser feito no RDS:<\/p>\n
net.ipv4.tcp_keepalive_time=10\nnet.ipv4.tcp_keepalive_intvl=1\nnet.ipv4.tcp_keepalive_probes=5\nnet.ipv4.tcp_retries2=3\n<\/code><\/pre>\nAl\u00e9m disso, o pre\u00e7o do AWS RDS \u00e9 quase o dobro do pre\u00e7o normal da inst\u00e2ncia, que foi a principal raz\u00e3o para desistirmos dessa solu\u00e7\u00e3o.<\/p>\n
Patroni<\/h3>\n Este \u00e9 um template em python para gerenciar PostgreSQL com boa documenta\u00e7\u00e3o, failover autom\u00e1tico e c\u00f3digo fonte no github.<\/p>\n
Vantagens do Patroni:<\/p>\n
\nCada par\u00e2metro de configura\u00e7\u00e3o \u00e9 detalhado, e \u00e9 f\u00e1cil entender como funciona;<\/li>\n O failover autom\u00e1tico funciona pronto para uso;<\/li>\n Escrito em python, e como n\u00f3s mesmos escrevemos muito em python, ser\u00e1 mais f\u00e1cil lidarmos com problemas e at\u00e9 mesmo ajudar no desenvolvimento do projeto;<\/li>\n Gerencia completamente o PostgreSQL, permitindo a altera\u00e7\u00e3o de configura\u00e7\u00f5es em todos os n\u00f3s do cluster de uma vez, e se a nova configura\u00e7\u00e3o exigir a reinicializa\u00e7\u00e3o do cluster, isso tamb\u00e9m pode ser feito com o Patroni.<\/li>\n<\/ul>\nPontos negativos:<\/p>\n
\nA documenta\u00e7\u00e3o n\u00e3o deixa claro como trabalhar corretamente com o PgBouncer. Embora isso seja dif\u00edcil de chamar de desvantagem, j\u00e1 que a tarefa do Patroni \u00e9 gerenciar o PostgreSQL, e como as conex\u00f5es ser\u00e3o direcionadas ao Patroni \u00e9 um problema nosso;<\/li>\n Existem poucos exemplos de implementa\u00e7\u00e3o do Patroni em grandes volumes, mas muitos exemplos de implanta\u00e7\u00e3o desde o in\u00edcio.<\/li>\n<\/ul>\nComo resultado, escolhemos o Patroni para criar um cluster com alta disponibilidade.<\/p>\n
O processo de implementa\u00e7\u00e3o do Patroni<\/h2>\n Antes do Patroni, t\u00ednhamos 12 shards do PostgreSQL na configura\u00e7\u00e3o de um mestre e uma r\u00e9plica com replica\u00e7\u00e3o ass\u00edncrona. Os servidores de aplica\u00e7\u00e3o se conectavam aos bancos de dados atrav\u00e9s de um Network Load Balancer, que tinha dois inst\u00e2ncias com PgBouncer, seguidos por todos os servidores PostgreSQL.
Para implementar o Patroni, precis\u00e1vamos escolher um armazenamento de configura\u00e7\u00e3o distribu\u00eddo para o cluster. O Patroni funciona com sistemas de armazenamento de configura\u00e7\u00f5es distribu\u00eddas, como etcd, Zookeeper e Consul. Temos um cluster Consul completo em produ\u00e7\u00e3o, que opera em conjunto com o Vault e n\u00e3o o utilizamos de outra forma. \u00c9 uma \u00f3tima oportunidade para come\u00e7ar a utilizar o Consul para seu prop\u00f3sito planejado.<\/p>\n
Como o Patroni funciona com o Consul<\/h3>\n Temos um cluster Consul que consiste em tr\u00eas n\u00f3s e um cluster Patroni, que \u00e9 composto por um l\u00edder e uma r\u00e9plica (no Patroni, o mestre \u00e9 chamado de l\u00edder do cluster, e os escravos s\u00e3o as r\u00e9plicas). Cada inst\u00e2ncia do cluster Patroni envia constantemente informa\u00e7\u00f5es sobre o estado do cluster para o Consul. Portanto, \u00e9 sempre poss\u00edvel consultar a configura\u00e7\u00e3o atual do cluster Patroni no Consul e quem \u00e9 o l\u00edder no momento.<\/p>\n
Para conectar o Patroni ao Consul, \u00e9 suficiente consultar a documenta\u00e7\u00e3o oficial, onde est\u00e1 escrito que precisamos fornecer um host no formato http ou https, dependendo de como estamos trabalhando com o Consul, e o esquema de conex\u00e3o, opcionalmente:<\/p>\n
host: o host:porta para o endpoint do Consul, no formato: http(s):\/\/host:porta\nscheme: (opcional) http ou https, padr\u00e3o \u00e9 http<\/code><\/pre>\nParece simples, mas aqui come\u00e7am as armadilhas. Estamos trabalhando com o Consul atrav\u00e9s de uma conex\u00e3o segura via https, e nossa configura\u00e7\u00e3o de conex\u00e3o ficar\u00e1 assim:<\/p>\n
consul:\n host: https:\/\/server.production.consul:8080 \n verify: true\n cacert: {{ consul_cacert }}\n cert: {{ consul_cert }}\n key: {{ consul_key }}<\/code><\/pre>\nMas assim n\u00e3o funciona. Ao iniciar, o Patroni n\u00e3o consegue se conectar ao Consul, porque est\u00e1 tentando usar http.<\/p>\n
Resolver o problema foi poss\u00edvel gra\u00e7as ao c\u00f3digo-fonte do Patroni. Felizmente, ele \u00e9 escrito em Python. Descobriu-se que o par\u00e2metro host n\u00e3o \u00e9 analisado, e o protocolo deve ser especificado no esquema. Veja como fica o bloco de configura\u00e7\u00e3o funcional para operar com o Consul em nosso caso:<\/p>\n
consul:\n host: server.production.consul:8080\n scheme: https\n verify: true\n cacert: {{ consul_cacert }}\n cert: {{ consul_cert }}\n key: {{ consul_key }}<\/code><\/pre>\nConsul-template<\/h3>\n Assim, escolhemos o armazenamento para a configura\u00e7\u00e3o. Agora precisamos entender como o PgBouncer alternar\u00e1 sua configura\u00e7\u00e3o ao mudar o l\u00edder no cluster Patroni. N\u00e3o h\u00e1 resposta para essa quest\u00e3o na documenta\u00e7\u00e3o, j\u00e1 que n\u00e3o descreve a opera\u00e7\u00e3o com o PgBouncer.<\/p>\n
Na busca por uma solu\u00e7\u00e3o, encontramos um artigo (n\u00e3o me lembro o nome, infelizmente), onde era mencionado que o Consul-template ajudou muito na integra\u00e7\u00e3o entre PgBouncer e Patroni. Isso nos motivou a investigar o funcionamento do Consul-template.<\/p>\n
Descobrimos que o Consul-template monitora continuamente a configura\u00e7\u00e3o do cluster PostgreSQL no Consul. Quando o l\u00edder muda, ele atualiza a configura\u00e7\u00e3o do PgBouncer e envia o comando para recarreg\u00e1-la.<\/p>\n
Uma grande vantagem do template \u00e9 que ele \u00e9 armazenado como c\u00f3digo, portanto, ao adicionar um novo shard, basta fazer um novo commit e atualizar o template automaticamente, mantendo o princ\u00edpio de Infrastructure as Code.<\/p>\n
Nova arquitetura com Patroni<\/h3>\n Como resultado, obtivemos o seguinte esquema de trabalho:
Todos os servidores da aplica\u00e7\u00e3o se conectam ao balanceador \u2192 atr\u00e1s dele h\u00e1 duas inst\u00e2ncias do PgBouncer \u2192 em cada inst\u00e2ncia est\u00e1 em execu\u00e7\u00e3o o Consul-template, que monitora o estado de cada cluster Patroni e verifica a atualidade da configura\u00e7\u00e3o do PgBouncer, que redireciona as solicita\u00e7\u00f5es para o atual l\u00edder de cada cluster.<\/p>\n
Teste manual<\/h3>\n Antes de implantar em produ\u00e7\u00e3o, testamos esse esquema em um pequeno ambiente de teste e verificamos o funcionamento da troca autom\u00e1tica. Abrimos um quadro, movemos um adesivo e, nesse momento, 'matamos' o l\u00edder do cluster. Na AWS, basta desligar a inst\u00e2ncia atrav\u00e9s do console.<\/p>\n
O adesivo retornou ao seu lugar em 10-20 segundos e depois come\u00e7ou a se mover normalmente novamente. Isso significa que o cluster Patroni funcionou corretamente: trocou de l\u00edder, enviou as informa\u00e7\u00f5es ao Consul, e o Consul-template imediatamente capturou essas informa\u00e7\u00f5es, substituiu a configura\u00e7\u00e3o do PgBouncer e enviou o comando para reload.<\/p>\n
Como sobreviver sob alta carga e manter o downtime m\u00ednimo?<\/h2>\n Tudo est\u00e1 funcionando perfeitamente! Mas surgem novas perguntas: como isso funcionar\u00e1 sob alta carga? Como implantar tudo de forma r\u00e1pida e segura em produ\u00e7\u00e3o?<\/p>\n
Responder \u00e0 primeira pergunta \u00e9 facilitado pelo ambiente de teste, onde realizamos testes de carga. Ele \u00e9 id\u00eantico \u00e0 produ\u00e7\u00e3o em termos de arquitetura e possui dados de teste gerados que s\u00e3o aproximadamente iguais em volume \u00e0 produ\u00e7\u00e3o. Decidimos \"eliminar\" um dos mestres PostgreSQL durante o teste e ver o que acontece. Mas antes disso, \u00e9 importante verificar a automa\u00e7\u00e3o, pois neste ambiente temos v\u00e1rios shards PostgreSQL, ent\u00e3o teremos uma \u00f3tima testagem dos scripts de configura\u00e7\u00e3o antes de irem para a produ\u00e7\u00e3o.<\/p>\n
Ambas as tarefas parecem ambiciosas, mas estamos com o PostgreSQL 9.6. Podemos atualizar diretamente para a vers\u00e3o 11.2?<\/p>\n
Decidimos fazer isso em duas etapas: primeiro atualizar para a vers\u00e3o 11.2, depois iniciar o Patroni.<\/p>\n
Atualiza\u00e7\u00e3o do PostgreSQL<\/h3>\n Para uma r\u00e1pida atualiza\u00e7\u00e3o da vers\u00e3o do PostgreSQL, \u00e9 necess\u00e1rio usar a op\u00e7\u00e3o -k<\/b>, que cria hard links no disco, sem a necessidade de copiar seus dados. Em bancos de 300-400 GB, a atualiza\u00e7\u00e3o leva 1 segundo.<\/p>\n
Temos muitos shards, por isso a atualiza\u00e7\u00e3o precisa ser feita de forma autom\u00e1tica. Para isso, escrevemos um playbook do Ansible, que executa todo o processo de atualiza\u00e7\u00e3o para n\u00f3s:<\/p>\n
\/usr\/lib\/postgresql\/11\/bin\/pg_upgrade \n<b>--link <\/b>\n--old-datadir='' --new-datadir='' \n --old-bindir='' --new-bindir='' \n --old-options=' -c config_file=' \n --new-options=' -c config_file='<\/code><\/pre>\nAqui \u00e9 importante notar que antes de iniciar a atualiza\u00e7\u00e3o, \u00e9 necess\u00e1rio rod\u00e1-la com o par\u00e2metro \u2014verifique<\/b>, para ter certeza de que a atualiza\u00e7\u00e3o \u00e9 poss\u00edvel. Al\u00e9m disso, nosso script faz a substitui\u00e7\u00e3o dos configs durante a atualiza\u00e7\u00e3o. O script foi executado em 30 segundos, o que \u00e9 um \u00f3timo resultado.<\/p>\nIn\u00edcio do Patroni<\/h3>\n
Para resolver o segundo problema, basta olhar a configura\u00e7\u00e3o do Patroni. No reposit\u00f3rio oficial h\u00e1 um exemplo de configura\u00e7\u00e3o com initdb, que \u00e9 respons\u00e1vel pela inicializa\u00e7\u00e3o do novo banco na primeira execu\u00e7\u00e3o do Patroni. Mas como j\u00e1 temos um banco pronto, apenas removemos essa se\u00e7\u00e3o da configura\u00e7\u00e3o.<\/p>\n
Quando come\u00e7amos a instalar o Patroni em um cluster PostgreSQL existente e a execut\u00e1-lo, nos deparamos com um novo problema: ambos os servidores estavam sendo iniciados como l\u00edderes. O Patroni n\u00e3o tem conhecimento do estado anterior do cluster e tenta iniciar ambos os servidores como dois clusters separados com o mesmo nome. Para resolver esse problema, \u00e9 necess\u00e1rio remover o diret\u00f3rio de dados no slave:<\/p>\n
rm -rf \/var\/lib\/postgresql\/<\/code><\/pre>\nIsso deve ser feito apenas no slave!<\/b><\/p>\n
Ao conectar uma r\u00e9plica limpa, o Patroni faz um basebackup do l\u00edder e o restaura na r\u00e9plica, e ent\u00e3o sincroniza o estado atual pelos logs wal.<\/p>\n
Mais uma dificuldade que encontramos \u00e9 que todos os clusters PostgreSQL s\u00e3o nomeados como main por padr\u00e3o. Quando cada cluster n\u00e3o sabe nada sobre o outro, isso \u00e9 aceit\u00e1vel. Mas quando voc\u00ea quer usar o Patroni, todos os clusters devem ter um nome \u00fanico. A solu\u00e7\u00e3o \u00e9 alterar o nome do cluster na configura\u00e7\u00e3o do PostgreSQL.<\/p>\n
Teste de carga<\/h3>\n Executamos um teste que simula o trabalho dos usu\u00e1rios em pain\u00e9is. Quando a carga atingiu nossa m\u00e9dia di\u00e1ria, repetimos exatamente o mesmo teste, desligando uma inst\u00e2ncia com o leader PostgreSQL. O failover autom\u00e1tico funcionou como esper\u00e1vamos: o Patroni trocou o l\u00edder, o Consul-template atualizou a configura\u00e7\u00e3o do PgBouncer e emitiu o comando para reload. Nossos gr\u00e1ficos no Grafana mostraram que havia atrasos de 20 a 30 segundos e um pequeno volume de erros dos servidores relacionados \u00e0 conex\u00e3o com o banco. Essa \u00e9 uma situa\u00e7\u00e3o normal, esses valores s\u00e3o aceit\u00e1veis para nosso failover e definitivamente melhores do que o tempo de inatividade do servi\u00e7o.<\/p>\n
Sa\u00edda do Patroni em produ\u00e7\u00e3o<\/h2>\n No final, nosso plano ficou assim:<\/p>\n
\nImplanta\u00e7\u00e3o do Consul-template nos servidores PgBouncer e in\u00edcio;<\/li>\n Atualiza\u00e7\u00e3o do PostgreSQL para a vers\u00e3o 11.2;<\/li>\n Mudan\u00e7a do nome do cluster;<\/li>\n In\u00edcio do cluster Patroni.<\/li>\n<\/ul>\nAo mesmo tempo, nosso esquema permite que o primeiro ponto seja feito a qualquer momento, podemos remover cada PgBouncer da opera\u00e7\u00e3o um por um e realizar a implanta\u00e7\u00e3o e o in\u00edcio do consul-template. E foi isso que fizemos.<\/p>\n
Para uma r\u00e1pida implementa\u00e7\u00e3o, usamos o Ansible, j\u00e1 que todos os playbooks foram testados em ambiente de teste, e o tempo de execu\u00e7\u00e3o do cen\u00e1rio completo variou de 1,5 a 2 minutos por sharding. Poder\u00edamos implantar cada sharding um por um sem parar nosso servi\u00e7o, mas ter\u00edamos que desligar cada PostgreSQL por alguns minutos. Nesse caso, os usu\u00e1rios cujos dados est\u00e3o nesse shard n\u00e3o poderiam trabalhar plenamente nesse intervalo, o que \u00e9 inaceit\u00e1vel para n\u00f3s.<\/p>\n
A solu\u00e7\u00e3o para essa situa\u00e7\u00e3o foi uma manuten\u00e7\u00e3o programada que realizamos a cada 3 meses. Este \u00e9 um per\u00edodo para trabalhos planejados, quando desligamos completamente nosso servi\u00e7o e atualizamos as inst\u00e2ncias dos bancos de dados. Restava uma semana at\u00e9 a pr\u00f3xima janela, e decidimos apenas esperar e nos preparar mais. Durante o tempo de espera, tomamos algumas precau\u00e7\u00f5es: levantamos uma r\u00e9plica de reserva para cada shard do PostgreSQL por precau\u00e7\u00e3o contra falhas, para manter os dados mais recentes, e adicionamos uma nova inst\u00e2ncia para cada shard, que deve se tornar uma nova r\u00e9plica no cluster Patroni, de modo que n\u00e3o precis\u00e1ssemos executar o comando para excluir dados. Tudo isso ajudou a minimizar o risco de erro.
Reiniciamos nosso servi\u00e7o, tudo funcionou como deveria, os usu\u00e1rios continuaram a trabalhar, mas notamos uma carga anormalmente alta nos servidores do Consul nos gr\u00e1ficos.
Por que n\u00e3o vimos isso no ambiente de teste? Este problema ilustra bem a necessidade de seguir o princ\u00edpio de Infrastructure as Code e aprimorar toda a infraestrutura, desde os ambientes de teste at\u00e9 o de produ\u00e7\u00e3o. Caso contr\u00e1rio, \u00e9 muito f\u00e1cil enfrentar um problema como o que tivemos. O que aconteceu? O Consul apareceu primeiro no ambiente de produ\u00e7\u00e3o e depois nos ambientes de teste; no final, a vers\u00e3o do Consul nos ambientes de teste era mais alta que a do ambiente de produ\u00e7\u00e3o. Em uma das vers\u00f5es, uma vazamento de CPU ao trabalhar com consul-template foi resolvido. Portanto, simplesmente atualizamos o Consul, resolvendo assim o problema.<\/p>\n
Reiniciar o cluster Patroni<\/h3>\n No entanto, encontramos um novo problema do qual nem suspeit\u00e1vamos. Ao atualizar o Consul, simplesmente removemos o n\u00f3 do Consul do cluster com o comando consul leave \u2192 o Patroni se conecta a outro servidor Consul \u2192 tudo funciona. Mas, quando chegamos \u00e0 \u00faltima inst\u00e2ncia do cluster Consul e enviamos a ele o comando consul leave, todos os clusters Patroni simplesmente reiniciaram, e nos logs vimos o seguinte erro:<\/p>\n
ERRO: get_cluster\nRastreamento (chamada mais recente por último):\n...\nRetryFailedError: 'Prazo de repetição excedido'\nERRO: Erro na comunicação com DCS\n<b>LOG: o sistema de banco de dados foi encerrado<\/b><\/code><\/pre>\nO cluster Patroni n\u00e3o conseguiu obter informa\u00e7\u00f5es sobre o seu cluster e reiniciou.<\/p>\n
Para encontrar uma solu\u00e7\u00e3o, entramos em contato com os autores do Patroni atrav\u00e9s de uma issue no GitHub. Eles sugeriram melhorias em nossos arquivos de configura\u00e7\u00e3o:<\/p>\n
consul:\n consul.checks: []\nbootstrap:\n dcs:\n retry_timeout: 8<\/code><\/pre>\nConseguimos reproduzir o problema no ambiente de teste e testamos esses par\u00e2metros l\u00e1, mas, infelizmente, eles n\u00e3o funcionaram.<\/p>\n
O problema ainda n\u00e3o foi resolvido. Pretendemos tentar as seguintes op\u00e7\u00f5es de solu\u00e7\u00e3o:<\/p>\n
\nUsar o agente Consul em cada inst\u00e2ncia do cluster Patroni;<\/li>\n Corrigir o problema no c\u00f3digo.<\/li>\n<\/ul>\nEntendemos onde a falha ocorre: provavelmente, o problema est\u00e1 no uso do timeout padr\u00e3o, que n\u00e3o \u00e9 redefinido atrav\u00e9s do arquivo de configura\u00e7\u00e3o. Ao remover o \u00faltimo servidor Consul do cluster, todo o cluster Consul congela por mais de um segundo, o que impede o Patroni de obter o estado do cluster e faz com que ele reinicie todo o cluster.<\/p>\n
Felizmente, n\u00e3o encontramos mais erros.<\/p>\n
Resultados do uso do Patroni<\/h2>\n Ap\u00f3s o lan\u00e7amento bem-sucedido do Patroni, adicionamos uma r\u00e9plica extra em cada cluster. Agora, cada cluster possui um tipo de quorum: um l\u00edder e duas r\u00e9plicas, para garantir a seguran\u00e7a em caso de split-brain durante a troca.
No ambiente de produ\u00e7\u00e3o, o Patroni est\u00e1 em funcionamento h\u00e1 mais de tr\u00eas meses. Durante esse tempo, j\u00e1 nos ajudou bastante. Recentemente, o l\u00edder de um dos clusters na AWS falhou, e o failover autom\u00e1tico ocorreu, permitindo que os usu\u00e1rios continuassem trabalhando. O Patroni cumpriu sua principal tarefa.<\/p>\n
Um pequeno resumo do uso do Patroni:<\/b><\/p>\n\nFacilidade de altera\u00e7\u00e3o da configura\u00e7\u00e3o. Basta alterar a configura\u00e7\u00e3o em uma inst\u00e2ncia e ela se aplicar\u00e1 ao todo o cluster. Se for necess\u00e1ria uma reinicializa\u00e7\u00e3o para aplicar a nova configura\u00e7\u00e3o, o Patroni informar\u00e1 sobre isso. O Patroni pode reiniciar todo o cluster com um \u00fanico comando, o que tamb\u00e9m \u00e9 muito conveniente.<\/li>\n O failover autom\u00e1tico funciona e j\u00e1 nos ajudou.<\/li>\n Atualiza\u00e7\u00e3o do PostgreSQL sem downtime da aplica\u00e7\u00e3o. Primeiro, \u00e9 necess\u00e1rio atualizar as r\u00e9plicas para a nova vers\u00e3o, em seguida, trocar o l\u00edder no cluster Patroni e atualizar o l\u00edder antigo. Durante esse processo, o teste do failover autom\u00e1tico \u00e9 realizado.<\/li>\n<\/ul>\nFonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0434\u043e\u0448\u043b\u0438 \u043a \u0432\u043e\u043f\u0440\u043e\u0441\u0443 \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 PostgreSQL, \u043f\u043e\u0447\u0435\u043c\u0443 \u044d\u0442\u043e \u0441\u0442\u0430\u043b\u043e \u0434\u043b\u044f \u043d\u0430\u0441 \u0432\u0430\u0436\u043d\u043e \u0438 \u0447\u0442\u043e \u0432 \u0438\u0442\u043e\u0433\u0435 \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c. \u0423 \u043d\u0430\u0441 \u0432\u044b\u0441\u043e\u043a\u043e\u043d\u0430\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u044b\u0439 \u0441\u0435\u0440\u0432\u0438\u0441: 2,5 \u043c\u043b\u043d \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443, 50\u041a+ \u0430\u043a\u0442\u0438\u0432\u043d\u044b\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u043a\u0430\u0436\u0434\u044b\u0439 \u0434\u0435\u043d\u044c. \u0421\u0435\u0440\u0432\u0435\u0440\u0430 \u043d\u0430\u0445\u043e\u0434\u044f\u0442\u0441\u044f \u0432 Amazone \u0432 \u043e\u0434\u043d\u043e\u043c \u0440\u0435\u0433\u0438\u043e\u043d\u0435 \u0418\u0440\u043b\u0430\u043d\u0434\u0438\u0438: \u0432 \u0440\u0430\u0431\u043e\u0442\u0435 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e 100+ \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432, \u0438\u0437 \u043d\u0438\u0445 \u043f\u043e\u0447\u0442\u0438 50 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26749,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35706","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"PostgreSQL](\"\/wp-content\/uploads\/2019\/06\/443f85815b0560fade7db5b639942935.png\")
![\"PostgreSQL](\"\/wp-content\/uploads\/2019\/06\/674dd77de4c8b48a946c9f64c0b2fdd1.png\")
<\/p>\n![\"PostgreSQL](\"\/wp-content\/uploads\/2019\/06\/dabcb7f6006520c4fec85fb925e8975e.png\")
<\/p>\n![\"PostgreSQL](\"\/wp-content\/uploads\/2019\/06\/2c1f1e7d9f7be4fdeb43858520d55e36.png\")
<\/p>\n![\"PostgreSQL](\"\/wp-content\/uploads\/2019\/06\/8e5350d2466311593e11add30d5b1bdc.png\")
<\/p>\n![\"PostgreSQL](\"\/wp-content\/uploads\/2019\/06\/3234594b363904424fdce64c9d77fca5.png\")
<\/p>\n![\"PostgreSQL](\"\/wp-content\/uploads\/2019\/06\/6cf92996a127bb6637ab81dc45fdd60a.png\")
<\/p>\n![\"PostgreSQL](\"\/wp-content\/uploads\/2019\/06\/bf9a9eff675a26039e3f76b16c6cd713.png\")
<\/p>\n![\"PostgreSQL](\"\/wp-content\/uploads\/2019\/06\/d670fe373b774f1b52bfd8a8c3b53a21.png\")
<\/p>\n![\"PostgreSQL](\"\/wp-content\/uploads\/2019\/06\/29e5c5f50dbfebfe5665fa0aeb009728.png\")
<\/p>\n![\"PostgreSQL](\"\/wp-content\/uploads\/2019\/06\/af0eef9ac235706c0aac62d2e1ee179d.png\")
<\/p>\n![\"PostgreSQL](\"\/wp-content\/uploads\/2019\/06\/3bb4c0495fea274b04edd2e99b59eacb.png\")
<\/p>\n