{"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 mage \u00abvaba\u00bb PostgreSQL karmidesse ettev\u00f5tte keskkondadesse","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Paljud tunnevad PostgreSQL andmebaasi, ja see on suurep\u00e4raselt t\u00f5estanud end v\u00e4ikestes installatsioonides. Kuid avatud l\u00e4htekoodiga lahendustele \u00fclemineku trend on saanud \u00fcha selgemaks, isegi suurte ettev\u00f5tete ja ettev\u00f5tte n\u00f5udmiste puhul. Selles artiklis r\u00e4\u00e4gime, kuidas PostgreSQL-i ettev\u00f5tte keskkonda integreerida ning jagame kogemusi varukoopiate loomise s\u00fcsteemi (VKS) loomisel antud andmebaasi jaoks Commvault'i varukoopiate s\u00fcsteemi n\u00e4itel. <\/p>\n

\"Kuidas
\nPostgreSQL on juba t\u00f5estanud oma usaldusv\u00e4\u00e4rsuse - andmebaas t\u00f6\u00f6tab suurep\u00e4raselt, seda kasutavad tuntud digitaalsed \u00e4rid nagu Alibaba ja TripAdvisor ning litsentsitasude puudumine teeb sellest ahvatleva alternatiivi sellistele hiiglastele nagu MS SQL v\u00f5i Oracle DB. Kuid niipea kui hakkame m\u00f5tlema PostgreSQL-ile ettev\u00f5tte maastikus, satume kohe rangete n\u00f5udmiste otsa: \"Kuidas on olukord konfiguratsiooni talitlush\u00e4irete \u00fcleelamisega? katastroofide \u00fcleelamisega? kus on terviklik j\u00e4lgimine? ja automatiseeritud varukoopiad? ja teipekogu kasutamine otse ja teise taseme salvestusena?\"
\n<\/a><\/noindex>
\n\"Kuidas
\n\u00dchest k\u00fcljest ei ole PostgreSQL-il sisseehitatud varundusvahendeid, nagu n\u00e4iteks Oracle DB RMAN v\u00f5i SAP andmebaasi varukoopia. Teisest k\u00fcljest toetavad ettev\u00f5tete varunduss\u00fcsteemide pakkujad (Veeam, Veritas, Commvault) PostgreSQL-i, kuid tegelikult t\u00f6\u00f6tavad nad ainult teatud (tavaliselt iseseisva) konfiguratsiooni ja erinevate piirangutega. <\/p>\n

PostgreSQLile spetsiaalselt v\u00e4lja t\u00f6\u00f6tatud varunduss\u00fcsteemid, nagu Barman, Wal-g, pg_probackup, on \u00e4\u00e4rmiselt populaarsed v\u00e4ikestes PostgreSQL andmebaasi installatsioonides v\u00f5i seal, kus ei ole vaja raskete tagavarade teisi IT-maastiku elemente. N\u00e4iteks, lisaks PostgreSQL-ile v\u00f5ib infrastruktuuris olla f\u00fc\u00fcsilisi ja virtuaalseid komponente. serverid<\/a>, OpenShift, Oracle, MariaDB, Cassandra jne. K\u00f5ike seda on soovitav varundada \u00fchise t\u00f6\u00f6riistaga. Eraldi lahenduse seadmine vaid PostgreSQL-ile on kehv idee: andmed kopeeritakse kuhugi ketastele ja seej\u00e4rel tuleb need lindile asetada. Selline varunduse dubleerimine pikendab varukoopiate aega ning veelgi kriitilisemalt - taastamisaega.<\/p>\n

Enterprise lahenduses toimuvad installatsioonide varukoopiad p\u00fchendatud klastrite teatud arvu s\u00f5lmedelt. N\u00e4iteks suudab Commvault t\u00f6\u00f6tada vaid kahe s\u00f5lmega klastriga, kus Primary ja Secondary on kindlalt m\u00e4\u00e4ratud teatud s\u00f5lmedele. Varukoopia tegemiseks on m\u00f5tet kasutada ainult Primary't, kuna varukoopiad Secondary'lt \u00fcldiselt ei toimi. Andmebaasi erip\u00e4ra t\u00f5ttu ei tehta Secondary-l dump'i, seega j\u00e4\u00e4b alles vaid failide varukoopia v\u00f5imalus.<\/p>\n

Aasta seisaku riski v\u00e4hendamiseks luuakse eba\u00f5nnestumisvastane s\u00fcsteem, mis loob \u201eelava\u201d klastrikonfiguratsiooni ning Primary v\u00f5ib j\u00e4rk-j\u00e4rgult migreeruda erinevate serverite vahel. N\u00e4iteks tarkvara Patroni k\u00e4ivitab ise Primary'st juhuslikult valitud s\u00f5lmel. SRK-l ei ole selle \u201ekastist v\u00e4ljas\u201d j\u00e4lgimise meetodit ja konfiguratsiooni muutudes puruneb protsess. See t\u00e4hendab, et v\u00e4line juhtimine takistab SRK t\u00f5husat t\u00f6\u00f6d, sest juhtimisserver lihtsalt ei m\u00f5ista, kust ja milliseid andmeid kopeerida.<\/p>\n

Veel \u00fcks probleem on varukoopia teostamine Postgreses. See on v\u00f5imalik dump'i kaudu ja v\u00e4ikeste andmebaaside puhul toimib see h\u00e4sti. Kuid suurte andmebaaside puhul kestab dump'imine kaua, n\u00f5uab palju ressursse ja v\u00f5ib p\u00f5hjustada andmebaasi eksemplari kokkuvarisemise.<\/p>\n

Faili varukoopia lahendab probleemi, kuid suurte andmebaaside puhul kulgeb see aeglaselt, kuna see t\u00f6\u00f6tab \u00fchesuunaliselt. Lisaks tekib tootjatel terve rida t\u00e4iendavaid piiranguid. \u00dckski ei tohi samaaegselt kasutada faili- ja dump-varukoopiat ning dedupeerimist ei toetata. Probleeme on palju ja tihti on lihtsam valida kallis, kuid t\u00f5estatud andmebaas Postgresi asemel.<\/p>\n

Taganeda pole kuhugi! Tagapool on Moskvas arendajad!<\/h2>\n

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

Suurtel tarkvaraarendajatel on palju lihtsam kasutada \u201emoodsaid\u201d avatud l\u00e4htekoodiga lahendusi. Facebooki t\u00f6\u00f6tajaskonnas on piisavalt spetsialiste, kes hooldavad selle andmebaasi t\u00f6\u00f6d. RSA puhul langesid k\u00f5ik \u201eteise p\u00e4eva\u201d \u00fclesanded meie \u00f5lule. Meilt n\u00f5uti eba\u00f5nnestumisvastasuse tagamist, klastrite loomist ja loomulikult varukoopia seadistamist. Tegevuse loogika oli j\u00e4rgmine: <\/p>\n