In protte minsken binne bekend mei de PostgreSQL DBMS, en it hat himsels bewiisd yn lytse ynstallaasjes. De trend nei Open Source is lykwols hieltyd dúdliker wurden, sels as it giet om grutte bedriuwen en bedriuweasken. Yn dit artikel sille wy jo fertelle hoe't jo Postgres kinne yntegrearje yn in bedriuwsomjouwing en ús ûnderfining diele mei it meitsjen fan in backupsysteem (BSS) foar dizze databank mei it Commvault-backupsysteem as foarbyld.
PostgreSQL hat syn wearde al bewiisd - de DBMS wurket geweldich, it wurdt brûkt troch modieuze digitale bedriuwen lykas Alibaba en TripAdvisor, en it gebrek oan fergunningferliening makket it in ferliedlik alternatyf foar sokke meunsters as MS SQL of Oracle DB. Mar sadree't wy begjinne te tinken oer PostgreSQL yn it Enterprise-lânskip, komme wy fuortendaliks tsjin strange easken: "Hoe sit it mei konfiguraasjefouttolerânsje? ramp ferset? wêr is de wiidweidige tafersjoch? Hoe sit it mei automatisearre backups? Hoe sit it mei it brûken fan tapebiblioteken sawol direkt as op sekundêre opslach?
Oan 'e iene kant hat PostgreSQL gjin ynboude backup-ark, lykas "folwoeksen" DBMS's lykas RMAN yn Oracle DB of SAP Database Backup. Oan 'e oare kant, leveransiers fan bedriuwsbackupsystemen (Veeam, Veritas, Commvault) hoewol se PostgreSQL stypje, wurkje se yn feite allinich mei in bepaalde (meastal standalone) konfiguraasje en mei in set fan ferskate beheiningen.
Reservekopysystemen spesjaal ûntworpen foar PostgreSQL, lykas Barman, Wal-g, pg_probackup, binne ekstreem populêr yn lytse ynstallaasjes fan de PostgreSQL DBMS of wêr't swiere backups fan oare eleminten fan it IT-lânskip net nedich binne. Bygelyks, neist PostgreSQL, kin de ynfrastruktuer fysike en firtuele servers, OpenShift, Oracle, MariaDB, Cassandra, ensfh. It is oan te rieden om dit alles te meitsjen mei in mienskiplik ark. It ynstallearjen fan in aparte oplossing eksklusyf foar PostgreSQL is in min idee: de gegevens wurde earne nei de skiif kopiearre, en dan moatte se fuortsmiten wurde nei tape. Dizze dûbele reservekopy fergruttet de reservekopytiid, en ek, mear kritysk, de hersteltiid.
Yn in bedriuwsoplossing bart backup fan 'e ynstallaasje mei in bepaald oantal knopen yn in tawijd kluster. Tagelyk, bygelyks, Commvault kin allinnich wurkje mei in twa-knooppunt kluster, dêr't Primary en Secondary wurde strikt tawiisd oan bepaalde knopen. En it makket allinich sin om reservekopy fan Primary te meitsjen, om't reservekopy fan Secondary syn beheiningen hat. Fanwegen de eigenaardichheden fan 'e DBMS wurdt in dump net oanmakke op Secondary, en dêrom bliuwt allinich de mooglikheid fan in triem-backup.
Om it risiko fan downtime te ferminderjen, by it meitsjen fan in fouttolerant systeem, wurdt in "live" klusterkonfiguraasje makke, en Primêr kin stadichoan migrearje tusken ferskate servers. Bygelyks, Patroni software sels lansearret Primêr op in willekeurich selektearre kluster node. De IBS hat gjin manier om dit út 'e doaze te folgjen, en as de konfiguraasje feroaret, brekke de prosessen. Dat is, de ynfiering fan eksterne kontrôle foarkomt dat de ISR effektyf wurket, om't de kontrôletsjinner gewoan net begrypt wêr't en hokker gegevens moatte wurde kopieare.
In oar probleem is de ymplemintaasje fan backup yn Postgres. It is mooglik fia dump, en it wurket op lytse databases. Mar yn grutte databases nimt de dump in lange tiid, fereasket in protte boarnen en kin liede ta it mislearjen fan 'e database-eksimplaar.
File-backup korrigearret de situaasje, mar op grutte databases is it stadich, om't it wurket yn single-threaded modus. Derneist hawwe ferkeapers in oantal ekstra beheiningen. Of jo kinne gjin triem- en dump-backups tagelyk brûke, of deduplikaasje wurdt net stipe. D'r binne in protte problemen, en meastentiids is it makliker om in djoere, mar bewiisde DBMS te kiezen ynstee fan Postgres.
D'r is nearne om werom te lûken! Moskou-ûntwikkelders binne efter!
Koartlyn stie ús team lykwols foar in drege útdaging: yn it projekt om AIS OSAGO 2.0 te meitsjen, wêr't wy de IT-ynfrastruktuer makken, keas de ûntwikkelders PostgreSQL foar it nije systeem.
It is folle makliker foar grutte software-ûntwikkelders om "trendy" iepen boarne-oplossingen te brûken. Facebook hat genôch spesjalisten om de wurking fan dizze DBMS te stypjen. En yn it gefal fan RSA foelen alle taken fan 'e "twadde dei" op ús skouders. Wy wiene ferplichte om fouttolerânsje te garandearjen, in kluster te sammeljen en, fansels, reservekopy yn te stellen. De logika fan aksje wie as folget:
- Lear de SRK om backups te meitsjen fanút de Primêre knooppunt fan it kluster. Om dit te dwaan, moat de SRK it fine - wat betsjut dat yntegraasje mei ien of oare PostgreSQL-klusterbehearoplossing nedich is. Yn it gefal fan RSA waard dêrfoar Patroni-software brûkt.
- Beslute oer it type reservekopy basearre op it folume fan gegevens en herstel easken. Bygelyks, as jo siden granulêr moatte weromsette, brûk dan in dump, en as de databases grut binne en korrelige restauraasje net nedich is, wurkje dan op it bestânnivo.
- Befestigje de mooglikheid fan blokkearjen fan reservekopy oan 'e oplossing om in reservekopy te meitsjen yn multi-threaded modus.
Tagelyk hawwe wy yn 't earstoan útsteld om in effektyf en ienfâldich systeem te meitsjen sûnder in meunsterlike harnas fan ekstra komponinten. Hoe minder krukken, hoe minder wurkdruk op personiel en hoe leger it risiko fan IBS-falen. Wy hawwe fuortendaliks oanpak útsletten dy't Veeam en RMAN brûkten, om't in set fan twa oplossingen al hint op 'e ûnbetrouberens fan it systeem.
In bytsje magy foar ûndernimming
Dat, wy moasten betroubere reservekopy garandearje foar 10 klusters fan elk 3 knopen, mei deselde ynfrastruktuer wjerspegele yn it backupdatasintrum. Datasintra yn termen fan PostgreSQL wurkje op it aktyf-passive prinsipe. De totale databankgrutte wie 50 TB. Elk kontrôlesysteem op bedriuwsnivo kin dit maklik omgean. Mar de warskôging is dat Postgres yn earste ynstânsje gjin oanwizing hat foar folsleine en djippe kompatibiliteit mei backupsystemen. Dêrom moasten wy sykje nei in oplossing dy't yn earste ynstânsje maksimale funksjonaliteit hie yn kombinaasje mei PostgreSQL, en it systeem ferfine.
Wy holden 3 ynterne "hackathons" - wy seagen nei mear as fyftich ûntjouwings, hifke se, makken feroaringen yn ferbân mei ús hypotezen, en testen se opnij. Nei it besjen fan de beskikbere opsjes, hawwe wy keazen foar Commvault. Ut it fak koe dit produkt wurkje mei de ienfâldichste PostgreSQL-klusterynstallaasje, en har iepen arsjitektuer wekte hope op (dy't terjochte wiene) foar suksesfolle ûntwikkeling en yntegraasje. Commvault kin ek PostgreSQL-logs reservekopy meitsje. Bygelyks, Veritas NetBackup yn termen fan PostgreSQL kin allinich folsleine backups meitsje.
Mear oer arsjitektuer. Commvault behear tsjinners waarden ynstallearre yn elk fan de twa data sintra yn in CommServ HA konfiguraasje. It systeem wurdt spegele, beheard fia ien konsole en foldocht, út it eachpunt fan HA, oan alle ûndernimmingseasken.
Wy lansearre ek twa fysike media tsjinners yn elk datasintrum, dêr't wy ferbûn skiif arrays en tape biblioteken wijd spesifyk foar backups fia SAN fia Fibre Channel. Utwreide deduplikaasjedatabases soarge foar fouttolerânsje fan mediaservers, en it ferbinen fan elke tsjinner oan elke CSV ynskeakele trochgeande operaasje as ien komponint mislearre. De systeemarsjitektuer lit de backup trochgean, sels as ien fan 'e datasintra falt.
Patroni definiearret in primêre knooppunt foar elk kluster. It kin elke fergese knooppunt wêze yn it datasintrum - mar allinich meast. Yn 'e reservekopy binne alle knopen Secondary.
Om Commvault te begripen hokker klusterknooppunt Primêr is, yntegrearre wy it systeem (mei tank oan de iepen arsjitektuer fan 'e oplossing) mei Postgres. Foar dit doel is in skript makke dat de hjoeddeistige lokaasje fan 'e Primêre knooppunt rapportearret oan de Commvault-behearserver.
Yn 't algemien sjocht it proses der sa út:
Patroni selektearret Primêr → Keepalive pakt it IP-kluster op en rint it skript → de Commvault-agint op 'e selekteare klusterknooppunt ûntfangt in notifikaasje dat dit de Primêr is → Commvault konfigurearret automatysk de reservekopy binnen de pseudo-kliïnt.
It foardiel fan dizze oanpak is dat de oplossing gjin ynfloed hat op de konsistinsje, korrektheid fan logs, of herstel fan it Postgres-eksimplaar. It is ek maklik skalberber, om't it net mear nedich is om de Commvault Primary and Secondary nodes te reparearjen. It is genôch dat it systeem begrypt wêr't Primêr is, en it oantal knooppunten kin wurde ferhege nei hast elke wearde.
De oplossing docht net foar as ideaal en hat syn eigen nuânses. Commvault kin allinich it heule eksimplaar reservekopy meitsje, en net yndividuele databases. Dêrom is in aparte eksimplaar makke foar elke databank. Echte kliïnten wurde kombinearre yn firtuele pseudo-kliïnten. Elke Commvault pseudo-kliïnt is in UNIX-kluster. Dy klusterknooppunten wêrop de Commvault-agint foar Postgres is ynstalleare, wurde deroan tafoege. As resultaat wurde alle firtuele knooppunten fan 'e pseudo-kliïnt reservekopy makke as ien eksimplaar.
Binnen elke pseudo-kliïnt wurdt de aktive knooppunt fan it kluster oanjûn. Dit is wat ús yntegraasjeoplossing foar Commvault definiearret. It prinsipe fan syn wurking is frij ienfâldich: as in kluster-IP op in knooppunt wurdt ferhege, stelt it skript de parameter "aktive knooppunt" yn yn 'e binêr Commvault-agent - yn feite stelt it skript "1" yn it fereaske diel fan it ûnthâld . De agint stjoert dizze gegevens nei CommServe, en Commvault makket in reservekopy fan 'e winske knooppunt. Derneist wurdt de krektens fan 'e konfiguraasje kontrolearre op it skriptnivo, wat helpt om flaters te foarkommen by it starten fan in reservekopy.
Tagelyk wurde grutte databases reservekopy makke yn blokken oer meardere threaden, foldogge oan RPO- en backupfinstereasken. De lading op it systeem is net folle: folsleine kopyen komme net sa faak foar, op oare dagen wurde allinich logs sammele, en yn perioaden fan lege lading.
Trouwens, wy hawwe apart belied tapast foar reservekopy fan PostgreSQL-argyflogs - se wurde opslein neffens ferskate regels, kopiearre neffens in oar skema, en deduplikaasje is net ynskeakele foar har, om't dizze logs unike gegevens befetsje.
Om konsistinsje te garandearjen oer de heule IT-ynfrastruktuer, wurde aparte Commvault-bestânkliïnten ynstalleare op elk fan 'e klusterknooppunten. Se slúte Postgres-bestannen út fan backups en binne allinich bedoeld foar OS- en applikaasje-backups. Dit diel fan 'e gegevens hat ek in eigen belied en opslachperioade.
Op it stuit hat IBS gjin ynfloed op produktiviteitstsjinsten, mar as de situaasje feroaret, kin Commvault loadbeheining ynskeakelje.
Is it goed? Goed!
Dat, wy hawwe net allinich in wurkbere, mar ek in folslein automatisearre reservekopy krigen foar in PostgreSQL-klusterynstallaasje, en it foldocht oan alle easken foar bedriuwsoproppen.
De RPO- en RTO-parameters fan 1 oere en 2 oeren binne bedekt mei in marzje, wat betsjut dat it systeem har foldwaan sil, sels mei in signifikante ferheging fan it folume fan opsleine gegevens. Yn tsjinstelling ta in protte twifels bliken PostgreSQL en de bedriuwsomjouwing frij kompatibel te wêzen. En no witte wy út eigen ûnderfining dat backup foar sokke DBMS's mooglik is yn in grut ferskaat oan konfiguraasjes.
Fansels moasten wy op dit paad sân pear izeren learzens drage, in oantal swierrichheden oerwinne, op ferskate harken stappe en in oantal flaters korrigearje. Mar no is de oanpak al hifke en kin brûkt wurde om Open Source te ymplementearjen ynstee fan proprietêre DBMS yn hurde ûndernimmingsomstannichheden.
Hawwe jo besocht te wurkjen mei PostgreSQL yn in bedriuwsomjouwing?
De auteurs:
Oleg Lavrenov, ûntwerpyngenieur fan gegevensopslachsystemen, Jet Infosystems
Dmitry Erykin, ûntwerpingenieur fan kompjûtersystemen by Jet Infosystems
Boarne: www.habr.com