Maraming tao ang pamilyar sa PostgreSQL DBMS, at napatunayan nito ang sarili nito sa maliliit na pag-install. Gayunpaman, ang trend patungo sa Open Source ay naging mas malinaw, kahit na pagdating sa malalaking kumpanya at mga kinakailangan sa enterprise. Sa artikulong ito sasabihin namin sa iyo kung paano isama ang Postgres sa isang corporate environment at ibahagi ang aming karanasan sa paggawa ng backup system (BSS) para sa database na ito gamit ang Commvault backup system bilang isang halimbawa.
Napatunayan na ng PostgreSQL ang halaga nito - mahusay na gumagana ang DBMS, ginagamit ito ng mga naka-istilong digital na negosyo tulad ng Alibaba at TripAdvisor, at ang kakulangan ng mga bayarin sa paglilisensya ay ginagawa itong isang mapang-akit na alternatibo sa mga halimaw gaya ng MS SQL o Oracle DB. Ngunit sa sandaling magsimula kaming mag-isip tungkol sa PostgreSQL sa landscape ng Enterprise, agad kaming tumakbo sa mga mahigpit na kinakailangan: "Paano ang pagpapaubaya sa pagkakamali sa pagsasaayos? paglaban sa kalamidad? nasaan ang comprehensive monitoring? Paano ang tungkol sa mga awtomatikong pag-backup? Paano naman ang paggamit ng tape library nang direkta at sa pangalawang storage?β
Sa isang banda, ang PostgreSQL ay walang mga built-in na backup na tool, tulad ng "pang-adulto" na mga DBMS tulad ng RMAN sa Oracle DB o SAP Database Backup. Sa kabilang banda, ang mga supplier ng corporate backup system (Veeam, Veritas, Commvault) bagama't sinusuportahan nila ang PostgreSQL, sa katunayan ay gumagana lamang sila sa isang tiyak (karaniwang standalone) na configuration at may isang hanay ng iba't ibang mga paghihigpit.
Ang mga backup system na espesyal na idinisenyo para sa PostgreSQL, tulad ng Barman, Wal-g, pg_probackup, ay napakapopular sa maliliit na pag-install ng PostgreSQL DBMS o kung saan hindi kailangan ang mabibigat na backup ng iba pang elemento ng IT landscape. Halimbawa, bilang karagdagan sa PostgreSQL, maaaring kabilang sa imprastraktura ang mga pisikal at virtual na server, OpenShift, Oracle, MariaDB, Cassandra, atbp. Maipapayo na i-back up ang lahat ng ito gamit ang isang karaniwang tool. Ang pag-install ng isang hiwalay na solusyon na eksklusibo para sa PostgreSQL ay isang masamang ideya: ang data ay makokopya sa isang lugar sa disk, at pagkatapos ay kailangan itong alisin sa tape. Ang dobleng backup na ito ay nagpapataas ng oras ng pag-backup, at gayundin, mas kritikal, ang oras ng pagbawi.
Sa isang enterprise na solusyon, ang backup ng pag-install ay nangyayari sa isang tiyak na bilang ng mga node sa isang nakalaang cluster. Kasabay nito, halimbawa, ang Commvault ay maaari lamang gumana sa isang dalawang-node na cluster, kung saan ang Pangunahin at Pangalawa ay mahigpit na itinalaga sa ilang mga node. At makatuwiran lamang na mag-backup mula sa Pangunahing, dahil may mga limitasyon ang backup mula sa Pangalawang. Dahil sa mga kakaibang katangian ng DBMS, ang isang dump ay hindi nilikha sa Pangalawang, at samakatuwid ay ang posibilidad lamang ng isang backup ng file ang nananatili.
Para bawasan ang panganib ng downtime, kapag gumagawa ng fault-tolerant system, isang "live" na configuration ng cluster ang gagawin, at maaaring unti-unting lumipat ang Primary sa pagitan ng iba't ibang server. Halimbawa, ang software ng Patroni mismo ay naglulunsad ng Primary sa isang random na napiling cluster node. Ang IBS ay walang paraan upang masubaybayan ito sa labas ng kahon, at kung magbabago ang pagsasaayos, masisira ang mga proseso. Iyon ay, ang pagpapakilala ng panlabas na kontrol ay pumipigil sa ISR na gumana nang epektibo, dahil ang control server ay hindi lamang nauunawaan kung saan at kung anong data ang kailangang kopyahin.
Ang isa pang problema ay ang pagpapatupad ng backup sa Postgres. Ito ay posible sa pamamagitan ng dump, at ito ay gumagana sa maliliit na database. Ngunit sa malalaking database, ang dump ay tumatagal ng mahabang panahon, nangangailangan ng maraming mapagkukunan at maaaring humantong sa pagkabigo ng halimbawa ng database.
Itinatama ng backup ng file ang sitwasyon, ngunit sa malalaking database ay mabagal ito dahil gumagana ito sa single-threaded mode. Bilang karagdagan, ang mga vendor ay may ilang karagdagang mga paghihigpit. Alinman sa hindi mo maaaring gamitin ang file at dump backup nang sabay, o hindi sinusuportahan ang deduplication. Maraming problema, at kadalasan ay mas madaling pumili ng mahal ngunit napatunayang DBMS sa halip na Postgres.
Wala nang matatakbuhan! Nasa likod ang mga developer ng Moscow!
Gayunpaman, kamakailan lamang ay nahaharap ang aming koponan sa isang mahirap na hamon: sa proyektong lumikha ng AIS OSAGO 2.0, kung saan nilikha namin ang imprastraktura ng IT, pinili ng mga developer ang PostgreSQL para sa bagong system.
Ito ay mas madali para sa malalaking software developer na gumamit ng "naka-istilong" open-source na mga solusyon. Ang Facebook ay may sapat na mga espesyalista upang suportahan ang pagpapatakbo ng DBMS na ito. At sa kaso ng RSA, lahat ng mga gawain ng "ikalawang araw" ay nahulog sa aming mga balikat. Kinailangan kaming tiyakin ang fault tolerance, mag-assemble ng cluster at, siyempre, mag-set up ng backup. Ang lohika ng pagkilos ay ang mga sumusunod:
- Turuan ang SRK na gumawa ng mga backup mula sa Primary node ng cluster. Upang magawa ito, dapat itong mahanap ng SRK - na nangangahulugang kailangan ang pagsasama sa isa o isa pang solusyon sa pamamahala ng cluster ng PostgreSQL. Sa kaso ng RSA, ginamit ang software ng Patroni para dito.
- Magpasya sa uri ng backup batay sa dami ng data at mga kinakailangan sa pagbawi. Halimbawa, kapag kailangan mong i-restore ang mga page nang granularly, gumamit ng dump, at kung malaki ang mga database at hindi kinakailangan ang granular restoration, gumana sa antas ng file.
- Ilakip ang posibilidad ng pag-block ng backup sa solusyon upang lumikha ng backup na kopya sa multi-threaded mode.
Kasabay nito, una kaming nagtakda upang lumikha ng isang epektibo at simpleng sistema nang walang napakalaking harness ng mga karagdagang bahagi. Ang mas kaunting saklay, mas kaunting workload sa mga kawani at mas mababa ang panganib ng IBS failure. Agad naming ibinukod ang mga diskarte na gumamit ng Veeam at RMAN, dahil ang isang hanay ng dalawang solusyon ay nagpapahiwatig na sa hindi pagiging maaasahan ng system.
Isang maliit na magic para sa negosyo
Kaya, kailangan naming garantiyahan ang maaasahang backup para sa 10 cluster ng 3 node bawat isa, na may parehong imprastraktura na naka-mirror sa backup na data center. Ang mga sentro ng data sa mga tuntunin ng PostgreSQL ay gumagana sa active-passive na prinsipyo. Ang kabuuang laki ng database ay 50 TB. Anumang corporate-level control system ay madaling makayanan ito. Ngunit ang caveat ay ang Postgres sa una ay walang pahiwatig para sa buo at malalim na pagkakatugma sa mga backup system. Samakatuwid, kinailangan naming maghanap ng solusyon na sa una ay may pinakamataas na pag-andar kasabay ng PostgreSQL, at pinuhin ang system.
Naghawak kami ng 3 panloob na "hackathon" - tumingin kami sa higit sa limampung mga pag-unlad, sinubukan ang mga ito, gumawa ng mga pagbabago na may kaugnayan sa aming mga hypotheses, at sinubukan muli ang mga ito. Pagkatapos suriin ang mga available na opsyon, pinili namin ang Commvault. Sa labas ng kahon, ang produktong ito ay maaaring gumana sa pinakasimpleng PostgreSQL cluster installation, at ang bukas na arkitektura nito ay nagtaas ng pag-asa (na makatwiran) para sa matagumpay na pag-unlad at pagsasama. Ang Commvault ay maaari ding mag-backup ng mga PostgreSQL log. Halimbawa, ang Veritas NetBackup sa mga tuntunin ng PostgreSQL ay maaari lamang gumawa ng buong backup.
Higit pa tungkol sa arkitektura. Ang mga server ng pamamahala ng Commvault ay na-install sa bawat isa sa dalawang data center sa isang configuration ng CommServ HA. Ang system ay sinasalamin, pinamamahalaan sa pamamagitan ng isang console at, mula sa HA point of view, nakakatugon sa lahat ng mga kinakailangan ng enterprise.
Naglunsad din kami ng dalawang pisikal na server ng media sa bawat data center, kung saan ikinonekta namin ang mga disk array at tape library na partikular na nakatuon para sa mga backup sa pamamagitan ng SAN sa pamamagitan ng Fiber Channel. Tiniyak ng pinalawak na mga database ng pag-deduplication ang fault tolerance ng mga media server, at ang pagkonekta sa bawat server sa bawat CSV ay nagpagana ng tuluy-tuloy na operasyon kung ang anumang bahagi ay nabigo. Ang arkitektura ng system ay nagpapahintulot sa backup na magpatuloy kahit na ang isa sa mga data center ay bumagsak.
Tinutukoy ni Patroni ang isang Pangunahing node para sa bawat cluster. Maaari itong maging anumang libreng node sa data center - ngunit karamihan lamang. Sa backup, ang lahat ng mga node ay Pangalawa.
Upang maunawaan ng Commvault kung aling cluster node ang Primary, isinama namin ang system (salamat sa bukas na arkitektura ng solusyon) sa Postgres. Para sa layuning ito, nilikha ang isang script na nag-uulat ng kasalukuyang lokasyon ng Pangunahing node sa server ng pamamahala ng Commvault.
Sa pangkalahatan, ang proseso ay ganito:
Pinipili ni Patroni ang Pangunahin β Kinuha ng Keepalived ang IP cluster at pinapatakbo ang script β ang ahente ng Commvault sa napiling cluster node ay makakatanggap ng notification na ito ang Pangunahin β Awtomatikong muling kino-configure ng Commvault ang backup sa loob ng pseudo-client.
Ang bentahe ng diskarteng ito ay hindi naaapektuhan ng solusyon ang pagkakapare-pareho, kawastuhan ng mga log, o pagbawi ng instance ng Postgres. Madali din itong ma-scalable, dahil hindi na kailangang ayusin ang Commvault Primary at Secondary node. Sapat na na maunawaan ng system kung nasaan ang Primary, at ang bilang ng mga node ay maaaring tumaas sa halos anumang halaga.
Ang solusyon ay hindi nagpapanggap na perpekto at may sariling mga nuances. Maaari lamang i-backup ng Commvault ang buong instance, at hindi ang mga indibidwal na database. Samakatuwid, ang isang hiwalay na halimbawa ay nilikha para sa bawat database. Ang mga tunay na kliyente ay pinagsama sa mga virtual na pseudo-client. Ang bawat Commvault pseudo-client ay isang UNIX cluster. Ang mga cluster node kung saan naka-install ang Commvault agent para sa Postgres ay idinagdag dito. Bilang resulta, lahat ng virtual node ng pseudo-client ay naka-back up bilang isang pagkakataon.
Sa loob ng bawat pseudo-client, ang aktibong node ng cluster ay ipinahiwatig. Ito ang tinutukoy ng aming solusyon sa pagsasama para sa Commvault. Ang prinsipyo ng pagpapatakbo nito ay medyo simple: kung ang isang cluster IP ay nakataas sa isang node, ang script ay nagtatakda ng "aktibong node" na parameter sa Commvault agent binary - sa katunayan, ang script ay nagtatakda ng "1" sa kinakailangang bahagi ng memorya . Ipinapadala ng ahente ang data na ito sa CommServe, at gumagawa ang Commvault ng backup mula sa gustong node. Bilang karagdagan, ang kawastuhan ng pagsasaayos ay sinusuri sa antas ng script, na tumutulong upang maiwasan ang mga error kapag nagsisimula ng isang backup.
Kasabay nito, ang malalaking database ay naka-back up sa mga bloke sa maraming mga thread, nakakatugon sa mga kinakailangan sa RPO at backup na window. Ang pag-load sa system ay hindi gaanong mahalaga: Ang mga kumpletong kopya ay hindi nangyayari nang madalas, sa ibang mga araw ay mga log lamang ang kinokolekta, at sa mga panahon ng mababang pagkarga.
Siyanga pala, naglapat kami ng hiwalay na mga patakaran para sa pag-back up ng mga PostgreSQL archive log - iniimbak ang mga ito ayon sa iba't ibang panuntunan, kinopya ayon sa ibang iskedyul, at hindi pinagana ang deduplication para sa kanila, dahil naglalaman ang mga log na ito ng natatanging data.
Upang matiyak ang pagkakapare-pareho sa buong imprastraktura ng IT, ang mga hiwalay na kliyente ng Commvault file ay naka-install sa bawat isa sa mga cluster node. Ibinubukod nila ang mga Postgres file mula sa mga backup at inilaan lamang para sa OS at mga backup ng application. Ang bahaging ito ng data ay mayroon ding sariling patakaran at panahon ng imbakan.
Sa kasalukuyan, hindi naaapektuhan ng IBS ang mga serbisyo sa pagiging produktibo, ngunit kung magbabago ang sitwasyon, maaaring paganahin ng Commvault ang paglilimita sa pagkarga.
Maganda ba? Magaling!
Kaya, nakatanggap kami hindi lamang ng isang magagawa, kundi pati na rin ng isang ganap na awtomatikong backup para sa isang PostgreSQL cluster installation, at natutugunan nito ang lahat ng mga kinakailangan para sa mga tawag sa enterprise.
Ang mga parameter ng RPO at RTO na 1 oras at 2 oras ay sakop ng margin, na nangangahulugang susunod ang system sa kanila kahit na may makabuluhang pagtaas sa dami ng nakaimbak na data. Taliwas sa maraming pagdududa, ang PostgreSQL at ang kapaligiran ng negosyo ay naging medyo magkatugma. At ngayon alam namin mula sa aming sariling karanasan na ang pag-backup para sa mga naturang DBMS ay posible sa iba't ibang uri ng mga pagsasaayos.
Siyempre, sa landas na ito kailangan naming magsuot ng pitong pares ng bakal na bota, pagtagumpayan ang ilang mga paghihirap, tapakan ang ilang mga rake at itama ang ilang mga pagkakamali. Ngunit ngayon ang diskarte ay nasubok na at maaaring magamit upang ipatupad ang Open Source sa halip na pagmamay-ari na DBMS sa malupit na mga kondisyon ng negosyo.
Nasubukan mo na bang magtrabaho kasama ang PostgreSQL sa isang corporate environment?
Mga May-akda:
Oleg Lavrenov, inhinyero ng disenyo ng mga sistema ng pag-iimbak ng data, Jet Infosystems
Dmitry Erykin, design engineer ng mga computer system sa Jet Infosystems
Pinagmulan: www.habr.com