{"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\/da\/blog\/administrirovanie\/kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie","title":{"rendered":"Hvordan man integrerer 'gratis' PostgreSQL i et strengt enterprise-milj\u00f8","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Mange kender til databasesystemet PostgreSQL, som har vist sig at v\u00e6re fremragende til sm\u00e5 installationer. Dog er tendensen til at bev\u00e6ge sig mod Open Source blevet mere og mere tydelig, selv n\u00e5r det g\u00e6lder store virksomheder og enterprise krav. I denne artikel vil vi n\u00e6vne, hvordan man integrerer Postgres i en virksomhedsmilj\u00f8 og dele erfaringer om oprettelsen af et backup-system (BK) for denne database ved hj\u00e6lp af Commvault backup-system. <\/p>\n

\"Hvordan
\nPostgreSQL har allerede bevist sin v\u00e6rdi \u2014 databasesystemet fungerer fremragende, det anvendes af trendy digitale virksomheder som Alibaba og TripAdvisor, og frav\u00e6ret af licensafgifter g\u00f8r det til et lokkende alternativ til monstre som MS SQL eller Oracle DB. Men s\u00e5 snart vi begynder at overveje PostgreSQL i enterprise-landskabet, st\u00f8der vi p\u00e5 strenge krav: \"Hvordan er det med konfigurationens fejltolerance? katastrofe-resiliens? hvor er den omfattende overv\u00e5gning? hvad med automatiseret backup? og brugen af b\u00e5ndbiblioteker b\u00e5de direkte og som sekund\u00e6r lagring?\"
\n<\/a><\/noindex>
\n\"Hvordan
\nP\u00e5 den ene side har PostgreSQL ikke indbyggede backup-midler som \"voksne\" databasesystemer som RMAN fra Oracle DB eller SAP Database Backup. P\u00e5 den anden side underst\u00f8tter leverand\u00f8rerne af enterprise backup-l\u00f8sninger (Veeam, Veritas, Commvault) selvom PostgreSQL, men de virker faktisk kun med bestemte (normalt standalone) konfigurationer og et s\u00e6t forskellige begr\u00e6nsninger. <\/p>\n

Backup-systemer som Barman, Wal-g, pg_probackup, specielt designet til PostgreSQL, er meget popul\u00e6re i sm\u00e5 PostgreSQL-installationer eller der, hvor tunge backup-l\u00f8sninger til andre elementer i IT-landskabet ikke er n\u00f8dvendige. For eksempel kan der i infrastrukturen v\u00e6re b\u00e5de fysiske og virtuelle servere<\/a>, OpenShift, Oracle, MariaDB, Cassandra osv. Alle disse b\u00f8r bakkes op med et f\u00e6lles v\u00e6rkt\u00f8j. At installere en separat l\u00f8sning udelukkende til PostgreSQL er en d\u00e5rlig id\u00e9: data vil blive kopieret et sted til en disk, og derefter skal de overf\u00f8res til tape. Denne dobbeltbagage til backup \u00f8ger b\u00e5de tiden for backup og, hvad der er mere kritisk, - for gendannelsen.<\/p>\n

I enterprise-l\u00f8sningen bliver backup af installationen udf\u00f8rt med et antal noder fra det dedikerede klynge. For eksempel kan Commvault kun arbejde med en to-nodes klynge, hvor Primary og Secondary er strengt knyttet til bestemte noder. Der er ogs\u00e5 kun mening i at tage backup fra Primary, fordi backup fra Secondary har sine begr\u00e6nsninger. P\u00e5 grund af databasens s\u00e6rlige egenskaber oprettes der ikke en dump p\u00e5 Secondary, og derfor er der kun mulighed for fil-backup.<\/p>\n

For at reducere risikoen for nedetid, dannes der en \"levende\" klyngekonstruktion, n\u00e5r der oprettes et h\u00f8jtilg\u00e6ngeligt system, og Primary kan gradvist migrere mellem forskellige servere. For eksempel starter software som Patroni selv Primary p\u00e5 en tilf\u00e6ldigt valgt node i klyngen. SRK har ingen m\u00e5de at spore dette \"ud af boksen\", og hvis konfigurationen \u00e6ndrer sig, brydes processerne. Det vil sige, at implementeringen af ekstern styring hindrer SRK i at arbejde effektivt, fordi den styrende server simpelthen ikke forst\u00e5r, hvilke data der skal kopieres, og hvorfra.<\/p>\n

En anden udfordring er implementeringen af backup i Postgres. Det er muligt gennem dump, og det fungerer p\u00e5 sm\u00e5 databaser. Men i store databaser tager dump lang tid, kr\u00e6ver mange ressourcer og kan f\u00f8re til nedbrud af databasens instans.<\/p>\n

Fil-backup l\u00f8ser situationen, men i store databaser g\u00e5r det langsomt, fordi det k\u00f8rer i en enkelt tr\u00e5d. Desuden opst\u00e5r der en r\u00e6kke ekstra begr\u00e6nsninger fra leverand\u00f8rerne. Nogle gange m\u00e5 man ikke bruge b\u00e5de fil- og dump-backup samtidig, eller deduplication underst\u00f8ttes ikke. Der er mange problemer, og oftest er det lettere at v\u00e6lge en dyr, men p\u00e5lidelig database frem for Postgres.<\/p>\n

Der er ikke plads til tilbagetr\u00e6kning! Bagved er Moskva udviklerne!<\/h2>\n

\nMen for nylig stod vores team over for en vanskelig udfordring: i projektet om oprettelse af AIS OSAGO 2.0, hvor vi lavede IT-infrastrukturen, valgte udviklerne PostgreSQL til det nye system. <\/p>\n

Store softwareudviklere har meget lettere ved at bruge \"moderne\" open-source l\u00f8sninger. Hos Facebook er der tilstr\u00e6kkeligt med specialister ansat til at underst\u00f8tte driften af denne database. I tilf\u00e6lde af RSA blev alle opgaverne 'den anden dag' lagt p\u00e5 vores skuldre. Vi skulle sikre h\u00f8jtilg\u00e6ngelighed, samle klyngen og selvf\u00f8lgelig etablere backup. Handlingslogikken var s\u00e5dan: <\/p>\n