{"id":93878,"date":"2020-09-10T19:42:02","date_gmt":"2020-09-10T17:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie"},"modified":"2020-09-10T19:42:02","modified_gmt":"2020-09-10T17:42:02","slug":"kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie","title":{"rendered":"Como integrar o PostgreSQL \"livre\" em um ambiente empresarial desafiador","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Muitos est\u00e3o familiarizados com o SGBD PostgreSQL, que se destacou em instala\u00e7\u00f5es pequenas. No entanto, a tend\u00eancia de migra\u00e7\u00e3o para solu\u00e7\u00f5es Open Source se tornou cada vez mais evidente, mesmo em grandes empresas e em requisitos empresariais. Neste artigo, abordaremos como integrar o Postgres em um ambiente corporativo e compartilharemos experi\u00eancias na cria\u00e7\u00e3o de um sistema de backup (SBK) para esse banco de dados, usando como exemplo o sistema de backup Commvault. <\/p>\n

\"Como
\nO PostgreSQL j\u00e1 provou sua efic\u00e1cia \u2014 o SGBD funciona perfeitamente, sendo utilizado por neg\u00f3cios digitais modernos como Alibaba e TripAdvisor, e a aus\u00eancia de custos de licenciamento o torna uma alternativa atraente a gigantes como MS SQL ou Oracle DB. No entanto, quando come\u00e7amos a considerar o PostgreSQL no cen\u00e1rio corporativo, imediatamente nos deparamos com requisitos rigorosos: \u201cE quanto \u00e0 resili\u00eancia da configura\u00e7\u00e3o? E a recupera\u00e7\u00e3o em desastres? Onde est\u00e1 a monitora\u00e7\u00e3o abrangente? E o backup automatizado? Qual \u00e9 o uso de bibliotecas de fitas, tanto diretamente quanto como armazenamento secund\u00e1rio?\u201d
\n<\/a><\/noindex>
\n\"Como
\nPor um lado, o PostgreSQL n\u00e3o possui ferramentas de backup integradas, como os \u2018SGBDs maduros\u2019 RMAN da Oracle DB ou SAP Database Backup. Por outro lado, fornecedores de sistemas de backup corporativo (Veeam, Veritas, Commvault) suportam PostgreSQL, mas na pr\u00e1tica funcionam somente com configurac\u00f5es espec\u00edficas (geralmente standalone) e um conjunto de v\u00e1rias limita\u00e7\u00f5es. <\/p>\n

Sistemas de backup projetados especificamente para PostgreSQL, como Barman, Wal-g, pg_probackup, s\u00e3o extremamente populares em pequenas instala\u00e7\u00f5es do SGBD PostgreSQL ou onde n\u00e3o s\u00e3o necess\u00e1rios backups pesados de outros elementos da paisagem de TI. Por exemplo, al\u00e9m do PostgreSQL, a infraestrutura pode incluir f\u00edsicos e virtuais servidores<\/a>, OpenShift, Oracle, MariaDB, Cassandra, etc. Todos esses devem preferencialmente ser respaldados por uma ferramenta comum. Implementar uma solu\u00e7\u00e3o separada exclusivamente para o PostgreSQL \u00e9 uma ideia ruim: os dados ser\u00e3o copiados para um disco e depois precisam ser transferidos para uma fita. Essa duplica\u00e7\u00e3o de backups aumenta o tempo de backup e, mais criticamente, o de restaura\u00e7\u00e3o.<\/p>\n

Na solu\u00e7\u00e3o enterprise, o backup da instala\u00e7\u00e3o ocorre com um certo n\u00famero de n\u00f3s de um cluster dedicado. Por exemplo, o Commvault s\u00f3 consegue trabalhar com um cluster de dois n\u00f3s, onde o Primary e o Secondary est\u00e3o rigidamente fixados a n\u00f3s espec\u00edficos. E faz sentido fazer backup apenas do Primary, pois o backup do Secondary tem suas limita\u00e7\u00f5es. Devido \u00e0s caracter\u00edsticas do SGBD, o dump no Secondary n\u00e3o \u00e9 criado, e, portanto, a \u00fanica possibilidade \u00e9 o backup de arquivos.<\/p>\n

Para reduzir os riscos de inatividade, ao criar um sistema de alta disponibilidade, gera-se uma configura\u00e7\u00e3o de cluster \"viva\", e o Primary pode migrar gradualmente entre diferentes servidores. Por exemplo, o software Patroni inicia o Primary em um n\u00f3 escolhido aleatoriamente do cluster. O SRM n\u00e3o possui uma maneira de rastrear isso \"pronto para uso\" e, se a configura\u00e7\u00e3o mudar, os processos falham. Ou seja, a implementa\u00e7\u00e3o de um gerenciamento externo impede o SRM de funcionar de maneira eficaz, porque o servidor de gerenciamento simplesmente n\u00e3o entende de onde e quais dados precisam ser copiados.<\/p>\n

Outro problema \u00e9 a implementa\u00e7\u00e3o do backup no Postgres. \u00c9 poss\u00edvel atrav\u00e9s do dump e funciona bem em bancos pequenos. Mas em grandes bases de dados, o dump leva muito tempo, requer muitos recursos e pode causar a falha da inst\u00e2ncia do banco de dados.<\/p>\n

O backup de arquivos corrige a situa\u00e7\u00e3o, mas em grandes bases ele \u00e9 lento, pois trabalha em modo de thread \u00fanico. Al\u00e9m disso, os fornecedores imp\u00f5em uma s\u00e9rie de restri\u00e7\u00f5es adicionais. Por exemplo, n\u00e3o \u00e9 poss\u00edvel usar ao mesmo tempo backup de arquivos e de dumps, ou ent\u00e3o a deduplica\u00e7\u00e3o n\u00e3o \u00e9 suportada. Existem muitos problemas, e na maioria das vezes \u00e9 mais f\u00e1cil escolher um SGBD caro, mas confi\u00e1vel, em vez do Postgres.<\/p>\n

N\u00e3o h\u00e1 como recuar! Atr\u00e1s, est\u00e3o os desenvolvedores de Moscovo!<\/h2>\n

\nNo entanto, recentemente nossa equipe enfrentou um desafio dif\u00edcil: no projeto de cria\u00e7\u00e3o do AIS OSAGO 2.0, onde criamos a infraestrutura de TI, os desenvolvedores escolheram o PostgreSQL para o novo sistema. <\/p>\n

Para grandes desenvolvedores de software, \u00e9 muito mais simples usar solu\u00e7\u00f5es open-source \"da moda\". No mesmo time do Facebook, h\u00e1 especialistas suficientes para manter esse SGBD funcionando. No caso do RCA, todas as tarefas do \"segundo dia\" reca\u00edam sobre n\u00f3s. Era nossa responsabilidade garantir a alta disponibilidade, montar o cluster e, claro, implementar o backup. A l\u00f3gica das a\u00e7\u00f5es era a seguinte: <\/p>\n