{"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\/et\/blog\/administrirovanie\/kak-vpisat-svobodnuyu-postgresql-v-surovoe-enterprise-okruzhenie","title":{"rendered":"Kuidas integreerida \u00abvaba\u00bb PostgreSQL karmidesse ettev\u00f5tte keskkondadesse","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Paljuski tunnevad PostgreSQL andmebaasi, ja see on end v\u00e4ikestes paigaldustes suurep\u00e4raselt t\u00f5estanud. Siiski on \u00fcleminek avatud l\u00e4htekoodile saanud aina selgemaks suundumuseks, isegi suurte ettev\u00f5tete ja ettev\u00f5tlusn\u00f5uete puhul. Selles artiklis r\u00e4\u00e4gime, kuidas integreerida Postgres ettev\u00f5tte keskkonda, ning jagame oma kogemusi varunduss\u00fcsteemi (VKS) loomisel selle andmebaasi jaoks Commvaulti varunduss\u00fcsteemi n\u00e4itel. <\/p>\n

\"Kuidas
\nPostgreSQL on juba t\u00f5estanud oma usaldusv\u00e4\u00e4rsust \u2014 andmebaas t\u00f6\u00f6tab suurep\u00e4raselt, seda kasutavad trendikad digitaalsed ettev\u00f5tted nagu Alibaba ja TripAdvisor, ning litsentsitasude puudumine teeb selle ahvatlevaks alternatiiviks sellistele hiidudele nagu MS SQL v\u00f5i Oracle DB. Kuid niipea, kui hakkame m\u00f5tlema PostgreSQL-le ettev\u00f5tlusmaastikul, puutume kokku rangete n\u00f5udmistega: 'Kuidas on lood konfiguratsiooni talitlush\u00e4irete ja katastroofitaluvuse, p\u00f5hjaliku j\u00e4lgimise, automatiseeritud varundamise ning lintteekide kasutamisega, nii otse kui ka sekundaarse salvestusena?'
\n<\/a><\/noindex>
\n\"Kuidas
\n\u00dchelt poolt ei ole PostgreSQL-il sisseehitatud varundamise vahendeid nagu Oracle DB v\u00f5i SAP Database Backup'i k\u00fcpsed DBMS-id, nagu RMAN. Teiselt poolt toetavad ettev\u00f5tte varunduss\u00fcsteemide pakkujad (Veeam, Veritas, Commvault) k\u00fcll PostgreSQL-i, kuid tegelikult t\u00f6\u00f6tavad nad vaid kindlate (tavaliselt standalone) konfiguratsioonide ja erinevate piirangute komplektiga. <\/p>\n

Spetsiaalselt PostgreSQL-i jaoks loodud varunduss\u00fcsteemid, nagu Barman, Wal-g, pg_probackup, on \u00e4\u00e4rmiselt populaarsed v\u00e4ikestes PostgreSQL-i andmebaasi paigaldustes v\u00f5i seal, kus ei ole vaja keerulisi varukoopiaid teiste IT-maastiku elementide suhtes. N\u00e4iteks v\u00f5ivad infrastruktuuris olla f\u00fc\u00fcsilised ja virtuaalsed serverid<\/a>, OpenShift, Oracle, MariaDB, Cassandra jne. K\u00f5ike seda on soovitatav varundada \u00fchtse t\u00f6\u00f6riistaga. Eraldi lahenduse paigaldamine ainult PostgreSQL-ile on eba\u00f5nnestunud idee: andmed kopeeritakse kuskile kettale ja siis tuleb need lindile viia. Selline kahekordne varundamine pikendab varundamise aega ja mis veelgi kriitilisem \u2014 taastamist.<\/p>\n

Enterprise lahenduses toimub installatsioonide varundamine teatud arvude eraldi klastrite nodidega. N\u00e4iteks Commvault suudab t\u00f6\u00f6tada ainult kahe nodiga klastriga, kus Primary ja Secondary on kindlalt seotud kindlate nodidega. Ja varundamine on m\u00f5istlik ainult Primary kaudu, sest Secondaryst varundamine toob kaasa omad piirangud. Due to DBMS features, a dump is not created on Secondary, leaving only the option for file backup.<\/p>\n

Kuna seisakute riske tuleb v\u00e4hendada, luuakse vea- ja katkestustaluv s\u00fcsteem, milles moodustatakse \"elav\" klastrikonfiguratsioon ja Primary v\u00f5ib j\u00e4rk-j\u00e4rgult migreeruda erinevate serverite vahel. N\u00e4iteks k\u00e4ivitab tarkvara Patroni ise Primary uue juhuslikult valitud nodi klastris. SRC-l puuduvad vahendid selle j\u00e4lgimiseks \"kastist v\u00e4lja\" ja kui konfiguratsioon muutub, siis protsessid lagunevad. Seega v\u00e4line juhtimise rakendamine takistab SRK efektiivset t\u00f6\u00f6d, kuna juhtimisserver ei saa lihtsalt aru, kust ja milliseid andmeid on vaja kopeerida.<\/p>\n

Veel probleem on PostgreSQL-i varundamine. See on v\u00f5imalik dump'i kaudu ja v\u00e4ikeste andmebaaside puhul toimib see. Kuid suurte andmebaaside puhul on dumpimine aegan\u00f5udev, n\u00f5uab palju ressursse ja v\u00f5ib p\u00f5hjustada andmebaasi eksemplari kokkuvarisemise.<\/p>\n

Faili varukoopia parandab olukorda, kuid suurte andmebaaside puhul toimub see aeglaselt, kuna see t\u00f6\u00f6tab \u00fchesuunalises re\u017eiimis. Lisaks on vendoritel terve rida t\u00e4iendavaid piiranguid. M\u00f5nikord ei saa \u00fcheaegselt kasutada faili ja dump varukoopiates, m\u00f5nikord pole deduplikatsioon toetatud. Probleeme on palju ja tihti on lihtsam valida kallim, kuid usaldusv\u00e4\u00e4rne andmebaas PostgreSQL-i asemel.<\/p>\n

Tagasi pole minna! Moskva arendajad on seljataga!<\/h2>\n

\nKuid hiljuti seisis meie meeskond keerulise v\u00e4ljakutse ees: OSAGO 2.0 AIS-i loomise projektis, kus me t\u00f6\u00f6tasime IT-infrastruktuuri, valisid arendajad uue s\u00fcsteemi jaoks PostgreSQL-i. <\/p>\n

Suurte tarkvaraarendajate jaoks on palju lihtsam kasutada \"moes\" avatud l\u00e4htekoodiga lahendusi. Facebooki t\u00f6\u00f6tajate seas on piisavalt spetsialiste, kes toetavad selle andmebaasi toimimist. Kuid RSC puhul langesid k\u00f5ik \u201eteise p\u00e4eva\u201d \u00fclesanded meie \u00f5lgadele. Meilt n\u00f5uti, et tagame veakindluse, kogume klusteri ja loomulikult korraldame varundamise. Meie tegevuse loogika oli j\u00e4rgmine: <\/p>\n