Seueur jalma anu wawuh sareng PostgreSQL DBMS, sareng éta parantos ngabuktikeun diri dina pamasangan leutik. Tapi, trend nuju Open Source geus jadi beuki jelas, sanajan datang ka pausahaan badag sarta syarat perusahaan. Dina artikel ieu kami baris ngabejaan Anjeun kumaha ngahijikeun Postgres kana lingkungan perusahaan tur babagi pangalaman urang nyieun sistem cadangan (BSS) pikeun database ieu ngagunakeun sistem cadangan Commvault salaku conto.
PostgreSQL parantos ngabuktikeun nilaina - DBMS tiasa dianggo saé, dianggo ku usaha digital modis sapertos Alibaba sareng TripAdvisor, sareng kurangna biaya lisénsi ngajantenkeun alternatif anu pikabitaeun pikeun monster sapertos MS SQL atanapi Oracle DB. Tapi pas urang mimiti mikir ngeunaan PostgreSQL dina lanskap Perusahaan, urang langsung ngajalankeun syarat anu ketat: "Naon upami kasabaran kasalahan konfigurasi? lalawanan bencana? mana monitoring komprehensif? Kumaha upami cadangan otomatis? Kumaha upami nganggo perpustakaan kasét langsung sareng dina panyimpenan sekundér?"
Di hiji sisi, PostgreSQL teu gaduh alat cadangan anu diwangun, sapertos DBMS "dewasa" sapertos RMAN di Oracle DB atanapi SAP Database Backup. Di sisi anu sanésna, panyadia sistem cadangan perusahaan (Veeam, Veritas, Commvault) sanaos ngadukung PostgreSQL, kanyataanna aranjeunna ngan ukur tiasa dianggo sareng konfigurasi anu tangtu (biasana mandiri) sareng sakumpulan sababaraha larangan.
Sistem cadangan anu dirarancang khusus pikeun PostgreSQL, sapertos Barman, Wal-g, pg_probackup, populer pisan dina pamasangan leutik PostgreSQL DBMS atanapi dimana cadangan beurat unsur-unsur bentang IT henteu diperyogikeun. Salaku conto, salian ti PostgreSQL, infrastruktur tiasa kalebet server fisik sareng virtual, OpenShift, Oracle, MariaDB, Cassandra, jsb. Disarankeun nyadangkeun sadayana ieu nganggo alat anu umum. Masang solusi anu misah sacara éksklusif pikeun PostgreSQL mangrupikeun ide anu goréng: data bakal disalin dimana waé kana disk, teras éta kedah dipiceun kana kasét. Cadangan ganda ieu ningkatkeun waktos cadangan, sareng ogé, langkung kritis, waktos pamulihan.
Dina solusi perusahaan, cadangan pamasangan lumangsung kalayan sababaraha titik dina kluster khusus. Dina waktos anu sami, contona, Commvault ngan ukur tiasa damel sareng kluster dua titik, dimana primér sareng sekundér ditugaskeun ka titik-titik anu tangtu. Sareng ngan ukur asup akal pikeun nyadangkeun ti Primer, sabab cadangan ti Secondary gaduh watesanana. Alatan peculiarities tina DBMS, dump teu dijieun dina sekundér, sarta ku kituna ngan kamungkinan cadangan file tetep.
Pikeun ngurangan résiko downtime, nalika nyieun sistem kasalahan-toleran, a "hirup" konfigurasi klaster dijieun, sarta primér laun bisa migrasi antara server béda. Contona, software Patroni sorangan ngajalankeun primér dina titik klaster dipilih acak. IBS henteu gaduh jalan pikeun ngalacak ieu tina kotak, sareng upami konfigurasina robih, prosésna rusak. Nyaéta, bubuka kontrol éksternal nyegah ISR ti jalan éféktif, sabab server kontrol saukur teu ngarti dimana jeung naon data kudu disalin.
Masalah sanésna nyaéta palaksanaan cadangan di Postgres. Ieu mungkin ngaliwatan dump, sarta gawéna dina database leutik. Tapi dina database ageung, dump butuh waktos anu lami, peryogi seueur sumber daya sareng tiasa ngakibatkeun gagalna conto database.
Cadangan file ngabenerkeun kaayaan, tapi dina pangkalan data ageung éta laun sabab tiasa dianggo dina modeu benang tunggal. Salaku tambahan, padagang ngagaduhan sababaraha larangan tambahan. Boh anjeun teu tiasa nganggo file sareng dump cadangan dina waktos anu sami, atanapi deduplikasi henteu didukung. Aya seueur masalah, sareng sering langkung gampang milih DBMS anu mahal tapi kabuktian tinimbang Postgres.
Henteu aya tempat pikeun mundur! pamekar Moscow balik!
Nanging, nembé tim kami nyanghareupan tangtangan anu sesah: dina proyék pikeun nyiptakeun AIS OSAGO 2.0, dimana kami nyiptakeun infrastruktur IT, pamekar milih PostgreSQL pikeun sistem énggal.
Éta langkung gampang pikeun pamekar parangkat lunak ageung ngagunakeun solusi open-source "trendi". Facebook boga cukup spesialis pikeun ngarojong operasi DBMS ieu. Sareng dina kasus RSA, sadaya tugas "dinten kadua" murag kana taktak urang. Kami diwajibkeun pikeun mastikeun kasabaran kasalahan, ngumpul klaster sareng, tangtosna, nyetél cadangan. Logika tindakan nyaéta kieu:
- Ngajarkeun SRK nyieun cadangan tina titik primér kluster. Jang ngalampahkeun ieu, SRK kedah mendakanana - anu hartosna integrasi sareng hiji atanapi solusi manajemén klaster PostgreSQL anu sanés diperyogikeun. Dina kasus RSA, parangkat lunak Patroni dianggo pikeun ieu.
- Mutuskeun jenis cadangan dumasar kana volume data jeung sarat recovery. Salaku conto, nalika anjeun kedah ngabalikeun halaman sacara granular, anggo dump, sareng upami database ageung sareng restorasi granular henteu diperyogikeun, damel di tingkat file.
- Gantelkeun kamungkinan cadangan blok kana solusi pikeun nyiptakeun salinan cadangan dina modeu multi-threaded.
Dina waktos anu sami, urang mimitina badé nyiptakeun sistem anu épéktip sareng sederhana tanpa abah-abah komponén tambahan. Pangsaeutikna crutches, nu kirang workload on staf jeung handap résiko gagal IBS. Urang langsung ngaluarkeun pendekatan anu ngagunakeun Veeam sareng RMAN, sabab sakumpulan dua solusi parantos nunjukkeun yén sistem teu tiasa dipercaya.
A magic saeutik pikeun perusahaan
Janten, urang kedah ngajamin cadangan anu dipercaya pikeun 10 klaster tina 3 titik masing-masing, kalayan infrastruktur anu sami dicerminkeun dina pusat data cadangan. Puseur data dina hal PostgreSQL dianggo dina prinsip aktip-pasip. Total ukuran database éta 50 TB. Sakur sistem kontrol tingkat perusahaan tiasa gampang ngatasi ieu. Tapi caveat éta mimitina Postgres teu gaduh clue pikeun kasaluyuan lengkep sareng jero sareng sistem cadangan. Ku alatan éta, urang kedah milarian solusi anu mimitina ngagaduhan fungsionalitas maksimal sareng PostgreSQL, sareng nyaring sistem.
Kami ngayakeun 3 "hackathon" internal - kami ningali langkung ti lima puluh pamekaran, nguji aranjeunna, ngadamel parobihan anu aya hubunganana sareng hipotesis kami, sareng diuji deui. Saatos marios pilihan anu sayogi, kami milih Commvault. Out of the box, produk ieu tiasa dianggo sareng pamasangan klaster PostgreSQL pangbasajanna, sareng arsitéktur kabuka na naékkeun harepan (anu diyakinkeun) pikeun pangwangunan sareng integrasi anu suksés. Commvault ogé tiasa nyadangkeun log PostgreSQL. Contona, Veritas NetBackup dina hal PostgreSQL ngan ukur tiasa ngadamel cadangan lengkep.
Langkung seueur ngeunaan arsitéktur. Server manajemén Commvault dipasang dina unggal dua pusat data dina konfigurasi CommServ HA. Sistim ieu mirrored, dikelola ngaliwatan hiji konsol jeung, ti sudut pandang HA, meets sagala sarat perusahaan.
Kami ogé ngaluncurkeun dua server média fisik dina unggal pusat data, dimana kami nyambungkeun susunan disk sareng perpustakaan pita khusus pikeun cadangan via SAN via Fiber Channel. Basis data deduplikasi anu diperpanjang mastikeun kasabaran kasalahan tina server média, sareng ngahubungkeun unggal server ka unggal CSV ngamungkinkeun operasi kontinyu upami aya komponén anu gagal. Arsitéktur sistem ngamungkinkeun cadangan neruskeun sanajan salah sahiji puseur data ragrag.
Patroni nangtukeun titik primér pikeun tiap klaster. Bisa wae titik bébas dina puseur data - tapi ngan lolobana. Dina cadangan, sadaya titik sékundér.
Supados Commvault ngartos titik kluster mana anu primér, kami ngahijikeun sistem (hatur nuhun kana arsitéktur solusi anu kabuka) sareng Postgres. Pikeun tujuan ieu, skrip dijieun anu ngalaporkeun lokasi ayeuna titik primér ka server manajemén Commvault.
Sacara umum, prosésna sapertos kieu:
Patroni milih primér → Keepalived nyokot kluster IP tur ngajalankeun skrip → agén Commvault dina titik kluster dipilih narima béwara yén ieu Primer → Commvault otomatis reconfigures cadangan dina pseudo-klien.
Kauntungannana pendekatan ieu nyaeta solusi henteu mangaruhan konsistensi, correctness of log, atawa recovery ti conto Postgres. Éta ogé gampang diskalakeun, sabab henteu kedah deui ngalereskeun titik Commvault Primer sareng Secondary. Ieu cukup yén sistem understands mana primér, sarta jumlah titik bisa ngaronjat nepi ka ampir sagala nilai.
Solusina henteu pura-pura idéal sareng gaduh nuansa sorangan. Commvault ngan ukur tiasa nyadangkeun sadayana conto, sanés database individu. Ku alatan éta, hiji conto misah dijieun pikeun tiap database. Klién nyata digabungkeun kana pseudo-klien virtual. Unggal pseudo-klien Commvault mangrupakeun gugusan UNIX. Titik kluster anu dipasang agén Commvault pikeun Postgres ditambah kana éta. Hasilna, sadaya titik virtual tina pseudo-klien dicadangkeun salaku hiji conto.
Dina unggal pseudo-klien, titik aktif klaster dituduhkeun. Ieu mangrupikeun solusi integrasi kami pikeun Commvault. Prinsip operasina cukup saderhana: upami klaster IP diangkat dina titik, skrip netepkeun parameter "titik aktif" dina binér agén Commvault - kanyataanna, naskah nyetél "1" dina bagian mémori anu diperyogikeun. . Agén ngirimkeun data ieu ka CommServe, sareng Commvault ngadamel cadangan tina titik anu dipikahoyong. Salaku tambahan, kabeneran konfigurasi dipariksa di tingkat naskah, ngabantosan ngahindarkeun kasalahan nalika ngamimitian cadangan.
Dina waktos anu sami, pangkalan data ageung dicadangkeun dina blok dina sababaraha utas, nyumponan RPO sareng syarat jandela cadangan. Beban dina sistem teu pati penting: Salinan lengkep henteu sering kajantenan, dina dinten anu sanés ngan ukur log dikumpulkeun, sareng salami beban rendah.
Ku jalan kitu, kami parantos nerapkeun kawijakan anu misah pikeun nyadangkeun log arsip PostgreSQL - aranjeunna disimpen dumasar kana aturan anu béda, disalin dumasar kana jadwal anu béda, sareng deduplikasi henteu diaktipkeun pikeun aranjeunna, sabab log ieu ngandung data unik.
Pikeun mastikeun konsistensi dina sakabéh infrastruktur IT, klien file Commvault misah dipasang dina unggal titik klaster. Aranjeunna ngaluarkeun file Postgres tina cadangan sareng dimaksudkeun ngan pikeun cadangan OS sareng aplikasi. Ieu bagian tina data ogé boga kawijakan jeung periode neundeun sorangan.
Ayeuna, IBS henteu mangaruhan jasa produktivitas, tapi upami kaayaanna robih, Commvault tiasa ngaktifkeun ngawatesan beban.
Éta saé? alus!
Janten, kami nampi henteu ngan ukur tiasa dianggo, tapi ogé cadangan otomatis otomatis pikeun pamasangan klaster PostgreSQL, sareng nyumponan sadaya sarat pikeun telepon perusahaan.
Parameter RPO sareng RTO 1 jam sareng 2 jam ditutupan ku margin, anu hartosna sistem bakal sasuai sareng aranjeunna sanajan paningkatan anu signifikan dina volume data anu disimpen. Sabalikna sareng seueur mamang, PostgreSQL sareng lingkungan perusahaan tétéla cukup cocog. Sareng ayeuna urang terang tina pangalaman urang sorangan yén cadangan pikeun DBMS sapertos ieu mungkin dina rupa-rupa konfigurasi.
Tangtosna, sapanjang jalan ieu urang kedah ngagem kaluar tujuh pasang sapatu beusi, nungkulan sababaraha kasusah, lengkah dina sababaraha rake jeung ngabenerkeun sababaraha kasalahan. Tapi ayeuna pendekatanna parantos diuji sareng tiasa dianggo pikeun nerapkeun Open Source tinimbang DBMS proprietary dina kaayaan perusahaan anu parah.
Naha anjeun nyobian damel sareng PostgreSQL di lingkungan perusahaan?
Pangarang:
Oleg Lavrenov, insinyur desain sistem panyimpen data, Jet Infosystems
Dmitry Erykin, insinyur desain sistem komputer di Jet Infosystems
sumber: www.habr.com