Andrey Borodin-en 2019 hasierako txostenaren transkripzioa irakurtzea gomendatzen dizut "Babeskopiak WAL-G-rekin. Zer dago 2019an?"
Kaixo guztioi! Nire izena Andrey Borodin da. Yandex-en garatzailea naiz. 2016az geroztik interesatzen zait PostgreSQL, garatzaileekin hitz egin eta dena erraza dela esan ondoren: iturburu kodea hartu eta eraiki, eta dena ondo aterako da. Eta harrezkero ezin naiz gelditu - era guztietako gauza desberdinak idazten ditut.
Lantzen ari naizen gauzetako bat babeskopia sistema bat da. . Orokorrean, Yandex-en denbora luzez aritu gara PostgreSQL-en babeskopia-sistemetan. Eta Interneten aurki ditzakezu segurtasun-kopiak egiteko sistemak nola egiten ditugun aztertzen dituen sei txostenez. Eta urtero pixka bat eboluzionatzen dute, pixka bat garatzen dute eta fidagarriagoak bihurtzen dira.
Baina gaurko txostena ez da soilik zer egin dugun, baizik eta zein sinplea den eta zer den. Zuetako zenbatek ikusi dituzu dagoeneko WAL-G-ri buruzko nire txostenak? Ona da jende dezente ikusi ez izana, errazenetik hasiko naizelako.
Bat-batean PostgreSQL kluster bat baduzu, eta uste dut denek haiekin pare bat dituztela, eta bat-batean oraindik ez dago babeskopia sistemarik, S3 biltegiratze bat edo Google Cloud biltegiratze bateragarria lortu behar duzu.
Adibidez, gure standera etor zaitezke eta Yandex Object Storagerako promozio-kode bat har dezakezu, S3 bateragarria dena.
Ondoren, sortu Bucket bat. Informaziorako edukiontzi bat besterik ez da.
Sortu zerbitzu-erabiltzaile bat.
Sortu zerbitzuaren erabiltzailearentzat sarbide-gako bat: aws-s3-key.
Deskargatu WAL-G-ren azken bertsio egonkorra.
Zertan bereizten dira gure aurre-estreinaldiak estreinaldietatik? Askotan eskatzen didate goiz askatzeko. Eta bertsioan nahikoa denboran akatsik ez badago, adibidez, hilabete bat, orduan askatzen dut. Hona hemen azaroko argitalpen hau. Eta horrek esan nahi du hilero akatsen bat aurkitu genuela, normalean funtzionalitate ez-kritikoan, baina oraindik ez dugu kaleratu bertsiorik. Aurreko bertsioa azaroa baino ez da. Bertan ez dago ezagutzen ditugun akatsik, hau da, proiektuak aurrera egin ahala akatsak gehitu ziren.
WAL-G deskargatu ondoren, "backup zerrenda" komando sinple bat exekutatu dezakezu, ingurune-aldagaiak pasatuz. Eta Object Storage-ra konektatuko da eta zer babeskopiak dituzun esango dizu. Hasieran, noski, ez zenuke babeskopiarik izan behar. Diapositiba honen helburua dena nahiko sinplea dela erakustea da. Hau ingurune-aldagaiak onartzen dituen kontsolaren komandoa da eta azpikomandoak exekutatzen ditu.
Horren ondoren, zure lehen babeskopia egin dezakezu. Esan "backup-push" WAL-G-n eta zehaztu WAL-G-n zure klusterraren pgdata kokapena. Eta ziurrenik, PostgreSQL-k esango dizu, lehendik babeskopia-sistemarik ez baduzu, "artxibo-modua" gaitu behar duzula.
Horrek esan nahi du ezarpenetara joan eta "archive_mode = on" aktibatu eta "archive_command" gehitu behar duzula, hau ere WAL-G-n azpikomando bat dena. Baina arrazoiren batengatik jendeak sarritan erabiltzen ditu gai honi buruzko barra-scriptak eta WAL-G-en inguruan biltzen ditu. Mesedez, ez egin hau. Erabili WAL-G-n aurkitutako funtzionaltasuna. Zerbait falta bazaizu, idatzi helbide honetara . WAL-G-k artxibo_aginduan exekutatzen den programa bakarra dela suposatzen du.
WAL-G erabiltzen dugu batez ere erabilgarritasun handiko kluster bat sortzeko Yandex datu-baseen kudeaketan.
Eta normalean Master baten eta hainbat erreplikaren topologia batean erabiltzen da. Aldi berean, segurtasun kopia bat egiten du Yandex Object Storage-n.
Egoera ohikoenak kluster baten kopiak sortzea dira Point in time berreskuratzea erabiliz. Baina kasu honetan, babeskopia sistemaren errendimendua ez da hain garrantzitsua guretzat. Babeskopiatik kluster berri bat igo besterik ez dugu egin behar.
Normalean, segurtasun-kopia sistemaren errendimendua behar dugu nodo berri bat gehitzean. Zergatik da garrantzitsua? Normalean jendeak nodo berri bat gehitzen du kluster bati, lehendik dagoen klusterrak ezin duelako irakurri irakurketa-karga kudeatu. Erreplika berri bat gehitu behar dute. pg_basebackup-tik Masterra gehitzen badiogu karga, orduan Masterra tolestu daiteke. Hori dela eta, guretzat oso garrantzitsua zen artxibotik nodo berri bat azkar igo ahal izatea, Masterrean karga minimoa sortuz.
Eta antzeko beste egoera bat. Hau da maisu zaharra berrabiarazteko beharra, konexioa galdu zen Cluster Master-a datu-zentrotik aldatu ondoren.
- Ondorioz, kopia-sistemaren eskakizunak formulatzean, konturatu ginen pg_basebackup ez dela egokia hodeian jarduten dugunean.
- Gure datuak konprimitu ahal izatea nahi genuen. Baina kaxan datorrena ez den ia edozein babeskopia-sistemak datu-konpresioa emango du.
- Dena paralelizatu nahi izan dugu, hodeian dagoen erabiltzaile batek prozesadore nukleo kopuru handia erosten duelako. Baina eragiketa batzuetan paralelismorik ez badugu, nukleo kopuru handi bat alferrikakoa bihurtzen da.
- Enkriptatzea behar dugu, askotan datuak ez direlako gureak eta ezin direlako testu garbian gorde. Bide batez, WAL-G-ri gure ekarpena enkriptatzearekin hasi zen. WAL-G-n zifratzea osatu genuen, eta ondoren galdetu ziguten: "Agian gutako batek proiektua garatuko du?" Eta ordutik urtebete baino gehiago daramat WAL-G-rekin lanean.
- Baliabideen throttling ere behar genuen, hodeia erabiliz denborarekin, batzuetan jendeak janari-karga garrantzitsua izaten duela gauez eta karga hori ezin dela oztopatu. Horregatik gehitu dugu baliabideen throttling.
- Baita zerrenda eta kudeaketa ere.
- Eta egiaztapena.
Tresna ezberdin asko aztertu ditugu. Zorionez, aukeraketa handia dugu PostgreSQL-en. Eta edonon zerbait falta zitzaigun, funtzio txiki bat, ezaugarri txiki bat.
Eta dauden sistemak aztertuta, WAL-G garatuko dugula ondorioztatu genuen. Proiektu berria zen orduan. Nahiko erraza izan zen babes-sistemaren hodeiko azpiegituraren garapenean eragitea.
Guk atxikitzen dugun ideologia nagusia da WAL-G balalaika bezain sinplea izan behar dela.
WAL-G-k 4 komando ditu. Hau:
WAL-PUSH - artxibatu ardatza.
WAL-FETCH - lortu ardatz bat.
BACKUP-PUSH - egin babeskopia.
BACKUP-FETCH - lortu babeskopia sistematik.
Izan ere, WAL-G-k babeskopia horien kudeaketa ere badu, hau da, momentuz beharrezkoak ez diren erregistroak eta historiako babeskopiak zerrendatu eta ezabatzen ditu.
Funtzio garrantzitsuenetako bat delta kopiak sortzeko funtzioa da.
Delta kopiek esan nahi dute ez dugula kluster osoaren babeskopia osoa sortzen, baizik eta klusterreko aldatutako fitxategien orri aldatuak soilik. Badirudi funtzionalki WAL erabiliz berreskuratzeko gaitasunaren oso antzekoa dela. Baina WAL hari bakarreko delta babeskopia bat egin dezakegu paraleloan. Horren arabera, larunbatean oinarrizko babeskopia bat dugunean, delta babeskopiak egunero, eta ostegunean huts egiten dugunean, orduan 4 delta babeskopia eta 10 ordu WAL bildu behar ditugu. Gutxi gorabehera denbora berdina beharko du, delta babeskopiek paraleloan egiten dutelako.
LSNn oinarritutako deltak - honek esan nahi du babeskopia bat sortzean, orrialde bakoitza konbinatu eta bere LSN egiaztatu beharko dugula aurreko babeskopiaren LSNrekin, aldatu egin dela ulertzeko. Aldatutako datuak izan ditzakeen orrialde oro delta babeskopian egon beharko litzateke.
Esan bezala, paralelismoari arreta handia jarri zitzaion.
Baina PostgreSQL-en artxiboko APIa koherentea da. PostgreSQL-k WAL fitxategi bat artxibatu egiten du eta leheneratzen denean WAL fitxategi bat eskatzen du. Baina datu-baseak "WAL-FETCH" komandoa erabiliz WAL fitxategi bat eskatzen duenean, "WAL-PREFETCH" komandoa deitzen dugu, hurrengo 8 fitxategiak objektu-biltegitik datuak paraleloan eskuratzeko prestatzen dituena.
Eta datu-baseak fitxategi bat artxibatzeko eskatzen digunean, archive_status-ari begiratuko diogu eta ikusten dugu beste WAL fitxategirik dagoen. Eta paraleloki WAL deskargatzen saiatzen ari gara. Horrek errendimendu-irabazi handia ematen du eta artxibatu gabeko WAL kopuruan distantzia nabarmen murrizten du. Babeskopia-sistemen garatzaile askok uste dute sistema arriskutsua dela, PostgreSQL APIa ez den kodearen barneko ezagutzan oinarritzen garelako. PostgreSQL-k ez digu bermatzen archive_status karpetaren presentzia eta ez du bermatzen semantika, WAL fitxategietarako prest dauden seinaleen presentzia bertan. Hala ere, iturburu kodea aztertzen ari gara, hori horrela dela ikusten dugu eta ustiatzen saiatzen ari gara. Eta PostgreSQL garatzen ari den norabidea kontrolatzen dugu; bat-batean mekanismo hau apurtzen bada, erabiltzeari utziko diogu.
Bere forma hutsean, LSNn oinarritutako WAL delta-k aurreko babeskopia egin zenetik fitxategi-sisteman modu-denbora aldatu duen edozein cluster fitxategi irakurtzea eskatzen du. Denbora luzez bizi izan ginen honekin, ia urtebete. Eta azkenean WAL deltak ditugula ondorioztatu genuen.
Horrek esan nahi du Masterrean WAL artxibatzen dugun bakoitzean, konprimitu, enkriptatu eta sarera bidaltzen ez ezik, aldi berean irakurtzen dugula ere. Bertan dauden erregistroak aztertu eta irakurtzen ditugu. Zein bloke aldatu diren ulertzen dugu eta delta fitxategiak biltzen ditugu.
Delta fitxategi batek WAL fitxategi sorta jakin bat deskribatzen du, WAL sorta honetan zein bloke aldatu diren buruzko informazioa deskribatzen du. Eta gero delta fitxategi hauek ere artxibatu egiten dira.
Hemen dena nahiko azkar paralelizatu genuenaren aurrean gaude, baina ezin dugu historia sekuentzial bat paraleloan irakurri, segmentu jakin batean aurreko WAL erregistroaren amaierarekin topo egin baitezakegu, oraindik zerikusirik ez dugunarekin, zeren eta. irakurketa paraleloak ekarri zuen lehendabizi etorkizuna aztertzen dugula, oraindik iraganik ez duena.
Ondorioz, _delta_partzial fitxategietan pieza ulergaitzak jarri behar izan ditugu. Ondorioz, iraganera itzultzean, WAL diskoaren zatiak bakarrean itsatsiko ditugu, ondoren analizatu eta bertan zer aldatu den ulertuko dugu.
Gure ardatzaren analisiaren historian gertatzen ari zena ulertzen ez dugun puntu bat gutxienez badago, orduan, horren arabera, hurrengo segurtasun-kopian zehar kluster osoa berriro irakurtzera behartuta egongo gara, LSN arrunt batekin egin genuen bezala. -oinarritutako delta.
Ondorioz, gure sufrimendu guztiak WAL-G analisi-liburutegia kode irekia izatera eraman zuen. Nik dakidala, oraindik inork ez du erabiltzen, baina inork nahi badu, idatzi eta erabili, domeinu publikoa da. (Esteka eguneratua )
Ondorioz, informazio-fluxu guztiek nahiko konplikatuak dirudite. Gure Masterrak ardatza artxibatu eta delta fitxategiak artxibatu egiten ditu. Eta babeskopia egiten duen erreplikak delta fitxategiak jaso behar ditu babeskopien artean igaro den denboran. Kasu honetan, historiaren zatiak multzoan gehitu eta analizatu beharko dira, historia osoa ez baita segmentu handietan sartzen. Eta horren ondoren bakarrik erreplikak delta babeskopia osoa artxiba dezake.
Grafikoetan dena askoz sinpleagoa da. Hau gure benetako kluster batetik deskarga bat da. LSNn oinarritutakoa dugu, egun bakarrean egina. Eta ikusten dugu LSNn oinarritutako delta babeskopia goizeko hiruretatik goizeko bostetara exekutatzen ari zela. Hau da prozesadore-nukleoen kopuruaren karga. WAL-deltak 20 minutu inguru behar izan genituen hemen.Hau da, nabarmen azkarrago bihurtu zen, baina, aldi berean, sarean truke biziagoa izan zen.
Datu-basearen historian zein bloke aldatu diren eta zein momentutan aldatu diren informazioa dugunez, harago joan eta funtzionalitateak integratzea erabaki dugu: "pg_prefaulter" izeneko PostgreSQL luzapena.
Horrek esan nahi du stand-by-baseak leheneratzeko komandoa exekutatzen duenean, WAL-G-i hurrengo WAL fitxategia eskuratzeko esaten diola. Gutxi gorabehera, WAL berreskuratzeko prozesuak etorkizun hurbilean zein datu-bloke sartuko dituen ulertzen dugu eta bloke horietan irakurketa-eragiketa bat hasiko dugu. Hau SSD kontrolagailuen errendimendua handitzeko egin zen. WAL erroilua aldatu behar den orrialdera iritsiko baita. Orri hau diskoan dago eta ez dago orriaren cachean. Eta sinkronoki itxarongo du orrialde hau iristeko. Baina gertu dago WAL-G, zeinak badaki WALen hurrengo ehun megabyteetan orrialde jakin batzuk beharko ditugula eta aldi berean berotzen hasten dela. Hainbat disko-sarbide abiarazten ditu, paraleloan exekutatu daitezen. Honek ondo funtzionatzen du SSD unitateetan, baina, zoritxarrez, ez da guztiz aplikagarria disko gogorrean, gure abisuekin soilik oztopatzen dugulako.
Hau da orain kodean dagoena.
Gehitu nahiko genituzkeen ezaugarriak daude.
Irudi honek WAL-deltak denbora nahiko laburra hartzen duela erakusten du. Eta hau egunean zehar datu basean gertatutako aldaketak irakurtzen ari da. WAL-delta egin genezake gauez ez ezik, jada ez baita karga iturri esanguratsu bat. WAL-delta minuturo irakur dezakegu, merkea delako. Minutu batean klusterrean gertatu diren aldaketa guztiak eskaneatu ditzakegu. Eta horri "instant WAL-delta" deitu liteke.
Kontua da multzoa leheneratzen dugunean, sekuentzialki bildu behar ditugun istorioen kopurua murrizten dugula. Hau da, PostgreSQL-k jaurtitzen duen WAL-kopurua murriztu beharko litzateke, denbora handia behar duelako.
Baina hori ez da guztia. Bloke batzuk babeskopien koherentziaraino aldatuko direla badakigu, ezin dugu iraganean aldatu. Hau da, orain WAL-delta birbidalketaren fitxategiz fitxategi optimizatu dugu. Horrek esan nahi du, adibidez, asteartean taularen bat guztiz ezabatu bazen edo fitxategi batzuk taulatik guztiz ezabatu baziren, astelehenean delta itzultzen denean eta larunbateko pg_basebackup berreskuratzen denean, ez ditugu datu hauek sortuko ere.
Teknologia hau orrialde mailara zabaldu nahi dugu. Hau da, astelehenean fitxategiaren zatiren bat aldatzen bada, baina asteazkenean gainidatziko bada, ostegunean puntu batera berrezartzean, ez ditugu orrien lehen bertsioak diskoan idatzi beharrik.
Baina gure baitan aktiboki eztabaidatzen ari den ideia da oraindik, baina oraindik ez da kodera iritsi.
Ezaugarri bat gehiago egin nahi dugu WAL-G-en. Zabalgarri egin nahi dugu datu-base desberdinak onartzen ditugulako eta babeskopien kudeaketa modu berean jorratu ahal izatea gustatuko litzaiguke. Baina arazoa da MySQL APIak zeharo desberdinak direla. MySQL-en, PITR ez da WAL erregistro fisikoan oinarritzen, binlog-ean baizik. Eta ez dugu MySQL-n artxibatzeko sistemarik kanpoko sistema bati esango liokeen binlog hau amaitu dela eta artxibatu behar dela. Cron-en nonbait egon behar dugu datu-basearekin eta egiaztatu zerbait prest dagoen?
Eta era berean, MySQL zaharberritze batean, ez dago sistemari horrelako fitxategiak behar ditudala esan diezaiokeen leheneratzeko komandorik. Zure klusterra berreraikitzen hasi aurretik, zein fitxategi beharko dituzun jakin behar duzu. Zuk zeuk asmatu behar duzu zein fitxategi beharko dituzun. Baina arazo hauek nolabait saihestu daitezke. (Azalpena: MySQL dagoeneko onartzen da)
Erreportajean, WAL-G zuretzat egokia ez den kasu horietaz ere hitz egin nahi nuen.
Erreplika sinkronikorik ez baduzu, WAL-G-k ez du bermatzen azken segmentua gordeko denik. Eta artxibatzea historiako azken zatien atzean geratzen bada, hori arriskua da. Erreplika sinkronorik ez badago, ez nuke gomendatuko WAL-G erabiltzea. Hala ere, batez ere hodeiko instalazio baterako diseinatuta dago, eta horrek Erabilgarritasun Handiko konponbide bat suposatzen du erreplika sinkrono batekin, konprometitutako azken byteen segurtasunaz arduratzen dena.
Askotan ikusten dut jendea WAL-G eta WAL-E aldi berean exekutatzen saiatzen ari dela. Atzerako bateragarritasuna onartzen dugu, WAL-G-k WAL-E-tik fitxategi bat leheneratu dezakeela eta WAL-E-n egindako babeskopia berreskura dezakeelako. Baina bi sistema hauek wal-push paraleloa erabiltzen dutenez, fitxategiak elkarri lapurtzen hasten dira. WAL-G-n konpontzen badugu, WAL-E-n jarraituko du. WAL-E-n, artxibo-egoera aztertzen du, amaitutako fitxategiak ikusten ditu eta artxibatu egiten ditu, beste sistema batzuek, berriz, ez dute jakingo WAL fitxategi hau existitzen zenik, PostgreSQL ez delako bigarren aldiz artxibatzen saiatuko.
Zer konponduko dugu hemen WAL-G aldean? Ez diogu PostgreSQLri fitxategi hau paraleloki transferitu denik jakinaraziko, eta PostgreSQL-k artxibatzeko eskatzen digunean, dagoeneko jakingo dugu modu-denbora honekin eta md5 honekin artxibatuta dagoela eta PostgreSQL besterik gabe esango dugu - Ados, dena prest dago funtsean ezer egin gabe.
Baina arazo hau WAL-E aldean nekez konponduko da, beraz, gaur egun ezinezkoa da fitxategia WAL-G zein WAL-E-n artxibatuko duen artxibo-komando bat sortzea.
Horrez gain, badaude WAL-G zuretzat egokia ez den kasuak, baina behin betiko konponduko dugu.
Lehenik eta behin, ez dugu babeskopien egiaztapen integratua. Ez dugu egiaztapenik ez babeskopia edo berreskuratzean. Jakina, hau hodeian ezartzen da. Baina hau aurrez egiaztatzea besterik ez da inplementatzen, klusterra leheneratu besterik ez. Erabiltzaileei funtzionalitate hau eman nahiko nieke. Baina egiaztatzen, suposatzen dut WAL-G-n posible izango dela klusterra berrezartzea eta abiaraztea, eta ke-probak egitea: pg_dumpall to /dev/null eta amcheck index verification.
Gaur egun WAL-G-n ez dago WAL-en babeskopia bat atzeratzeko modurik. Hau da, leiho batzuk onartzen ditugu. Adibidez, azken zazpi egunak gordetzea, azken hamar segurtasun kopiak gordetzea, azken hiru segurtasun kopiak gordetzea. Askotan jendea etortzen da eta esaten du: "Urte Berrian gertatutakoaren babeskopia behar dugu eta betirako gorde nahi dugu". WAL-G-k ezin du oraindik hau egin. (Oharra - Hau konpondu da dagoeneko. Gehiago irakurri - Backup-mark aukera hemen )
Eta PITR baliozkotzean ez dugu orrien batuketarik eta osotasun egiaztapenik ardatz-segmentu guztientzat.
Guzti honetatik Google Summer of Coderako proiektu bat osatu nuen. Go-n zerbait idatzi eta "G" hizkiarekin enpresa batetik hainbat mila dolar lortu nahi dituzten ikasle adimentsuak ezagutzen badituzu, gomendatu gure proiektua. Proiektu honen tutore gisa arituko naiz, egin dezakete. Ikaslerik ez badago, orduan neuk hartuko dut eta udan egingo dut.
Eta beste arazo txiki asko ditugu pixkanaka lantzen ari garenok. Eta gauza nahiko arraro batzuk gertatzen dira.
Adibidez, WAL-G-ri babeskopia huts bat ematen badiozu, besterik gabe eroriko da. Adibidez, karpeta huts baten babeskopia egin behar duela esaten badiozu. pg_control fitxategia ez da egongo. Eta zerbait ulertzen ez duela pentsatuko du. Teorian, kasu honetan mezu normal bat idatzi behar diozu erabiltzaileari tresna nola erabili azaltzeko. Baina hori ez da programazioaren ezaugarri bat ere, hizkuntza on eta ulergarri baten ezaugarria baizik.
Ez dakigu lineaz kanpoko babeskopia nola egin. Datu-basea gezurra bada, ezin dugu babeskopia egin. Baina dena oso erraza da hemen. LSN-k babeskopiak deitzen ditugu abian denean. Azpiko oinarriaren LSN kontrol fitxategitik irakurri behar da. Eta hori gauzatu gabeko ezaugarria da. Babeskopia-sistema askok azpiko datu-base baten babeskopia egin dezakete. Eta komenigarria da.
Une honetan ezin dugu babeskopien espazio falta behar bezala kudeatu. Normalean etxean babeskopia handiekin lan egiten dugulako. Eta ez ziren lortu. Baina norbaitek Go-n oraintxe bertan programatu nahi badu, gehitu espaziotik kanpoko akatsen kudeaketa kuboari. Zalantzarik gabe, tira eskaera aztertuko dut.
Eta kezkatzen gaituen gauza nagusia da hainbat eszenatoki egiaztatzen dituzten docker integrazio proba ahalik eta gehien nahi ditugula. Oraintxe bertan oinarrizko eszenatokiak probatzen ari gara. Konpromiso bakoitzean, baina konpromisoz-konpromisoa egiaztatu nahi dugu onartzen ditugun funtzionalitate guztiak. Bereziki, adibidez, PostgreSQL 9.4-9.5rako nahikoa laguntza izango dugu. Komunitateak PostgreSQL onartzen duelako onartzen ditugu, baina ez dugu egiaztatzen konpromisoz-konpromisoa dena hautsi ez dela ziurtatzeko. Eta hori arrisku larria dela iruditzen zait.
WAL-G mila kluster baino gehiagotan exekutatzen dugu Yandex datu-baseen kudeaketan. Eta egunero ehunka terabyteko datuen babeskopia egiten du.
Gure kodean TODO asko ditugu. Programatu nahi baduzu, zatoz, tira eskaeren zain gaude, galderen zain gaude.
Zure galderak
Arratsalde on! Eskerrik asko! Nire ustez, WAL-delta erabiltzen ari bazara, ziurrenik orrialde osoko idazketetan oinarritzen zara. Eta hala bada, probak egin dituzu? Grafiko ederra erakutsi duzu. Zenbat eta ederragoa izango da FPW itzalita badago?
Orrialde osoko idazketak gaituta daude, ez gara desgaitzen saiatu. Hau da, ni, garatzaile gisa, ez naiz saiatu desaktibatzen. Ikertu duten sistema-administratzaileek ziurrenik arazo hau ikertu dute. Baina FPW behar dugu. Ia inork ez du desgaitzen, bestela ezinezkoa baita erreplika batetik babeskopia egitea.
Eskerrik asko erreportajeagatik! Bi galdera ditut. Lehenengo galdera zer gertatuko da tablespaceekin?
Tiro eskaera baten zain gaude. Gure datu-baseak SSD eta NMVE diskoetan bizi dira eta ez dugu funtzio hau behar. Ez nago prest denbora larria pasatzeko ondo egiten. Bihotz osoz defendatzen dut hau onartzen dugula. Bada jendea onartzen zuena, baina beraiei dagokien moduan onartzen zuena. Sardexka bat egin dute, baina ez dute tira eskaerarik egiten. (0.2.13 bertsioan gehitua)
Eta bigarren galdera. Hasieran esan duzu WAL-G-k bere gain hartzen duela bakarrik funtzionatzen duela eta ez dela bilgarririk behar. Nik neuk erabiltzen ditut bilgarriak. Zergatik ez dira erabili behar?
Balalaika bezain sinplea izatea nahi dugu. Horrek esan nahi du ez duzula ezer behar balalaika bat izan ezik. Sistema sinplea izatea nahi dugu. Script batean egin behar dituzun funtzionalitateak badituzu, etorri eta esan iezaguzu: Go-n egingo dugu.
Arratsalde on! Eskerrik asko erreportajeagatik! Ezin izan dugu WAL-G GPG deszifratzearekin lan egin. Normalki zifratzen du, baina ez du deszifratu nahi. Funtzionatu ez zaigun zerbait al da? Egoera etsigarria da.
Sortu arazo bat GitHub-en eta asma dezagun.
Hau da, ez duzu hau topatu?
Errore-txostenaren ezaugarri bat dago WAL-G-k zer fitxategi mota den ulertzen ez duenean, hau galdetzen duela: "Agian enkriptatuta dago?" Agian arazoa ez da batere enkriptatzea. Gai honi buruzko saioa hobetu nahi dut. Deszifratu behar du. Gaur egun gai hau lantzen ari gara, gako publikoak eta pribatuak lortzeko sistema nola antolatzen den ez zaigulako asko gustatzen. Kanpoko GPG deitzen dugulako bere giltzak eman ditzagun. Eta gero gako hauek hartu eta barne GPGra transferitzen ditugu, hau da, PGP irekia, WAL-G barruan konpilatzen zaiguna, eta hor enkriptatzea deitzen dugu. Zentzu honetan, sistema hobetu nahi dugu eta Libsodium enkriptatzea onartu nahi dugu (0.2.15 bertsioan gehitua). Noski, deskodetzeak funtzionatu beharko luke, asma dezagun - sintoma bat gehiago behar duzu hitz pare bat baino. Bozgorailuaren gelan bil zaitezke noizbait eta sistema begiratu. (PGP enkriptatzea kanpoko GPGrik gabe - v0.2.9)
Kaixo! Eskerrik asko erreportajeagatik! Bi galdera ditut. Pg_basebackup eta WAL bi hornitzaile saioa hasteko gogo arraroa dut, hau da, hodei bat eta beste bat egin nahi dut. Ba al dago hori egiteko moduren bat?
Hau ez da existitzen orain, baina ideia interesgarria da.
Ez naiz hornitzaile batean fidatzen, beste batean berdina izan nahi dut, badaezpada.
Ideia interesgarria da. Teknikoki, hau ez da batere zaila ezartzea. Ideia gal ez dadin, GitHub-en arazo bat egiteko eskatu al dizut?
Bai, jakina.
Eta gero, ikasleak Google Summer of Codera etortzen direnean, proiektuan gehituko ditugu, lan gehiago izan dadin horiei etekin handiagoa ateratzeko.
Eta bigarren galdera. Arazo bat dago GitHub-en. Uste dut dagoeneko itxita dagoela. Berrezartzean izua dago. Eta hura garaitzeko, aparteko batzar bat egin zenuten. Gaietan zuzena da. Eta hari batean ingurune aldakorra egiteko aukera dago. Eta horregatik dabil oso poliki. Eta arazo hau aurkitu dugu, eta oraindik ez da konpondu.
Arazoa da arrazoiren batengatik biltegiratzeak (CEPH) konexioa berrezartzen duela aldiberekotasun handiarekin iristen garenean. Zer egin daiteke honen aurrean? Berriro saiakeraren logikak itxura hau du. Fitxategia berriro deskargatzen saiatzen ari gara. Pase batean, deskargatu gabeko fitxategi batzuk izan ditugu, bigarren bat egingo dugu saioa hasi ez duten guztientzat. Eta iterazio bakoitzeko gutxienez fitxategi bat kargatzen den bitartean, errepikatzen dugu eta errepikatzen dugu. Berriro saiatzearen logika hobetu dugu - atzerapen esponentziala. Baina ez dago guztiz argi zer egin behar den konexioa biltegiratze sistemaren aldetik besterik gabe haustea. Hau da, korronte batera kargatzen dugunean, ez ditu konexio horiek hausten. Zer hobetu dezakegu hemen? Sarearen throttling dugu, konexio bakoitza bidaltzen duen byte kopuruaren arabera muga dezakegu. Bestela, ez dakit nola egin aurre objektuen biltegiratzeari ez digula uzten bertatik paraleloan deskargatzen edo deskargatzen.
SLArik ez? Ez al dago idatzita beraientzat nola oinazeak izaten uzten?
Kontua da galdera hau planteatzen dutenek normalean bere ganga propioa dutela. Hau da, inor ez dator Amazon edo Google Cloud edo Yandex Object Storage-tik.
Agian galdera jada ez da zuretzat?
Hemen galdera kasu honetan ez du axola nori. Horri aurre egiteko ideiarik badago, egin dezagun WAL-G-en. Baina orain arte ez daukat horri aurre egiteko ideia onik. Badira objektuen biltegiratze batzuk babeskopiak zerrendatzeko modu ezberdinean onartzen dutenak. Objektuak zerrendatzeko eskatzen diezu, eta karpeta gehitzen dute bertan. WAL-G beldurtu egiten da honetaz - badago hemen fitxategi bat ez den gauza bat, ezin dut berreskuratu, eta horrek esan nahi du babeskopia ez dela leheneratu. Hau da, izan ere, guztiz zaharberritutako kluster bat duzu, baina egoera okerra itzultzen dizu Object Storage-ek guztiz ulertu ez zuen informazio bitxi bat itzuli duelako.
Hau Mail hodeian gertatzen den gauza bat da.
Erreprodukzio bat eraikitzen baduzu...
Koherentziaz erreproduzitzen da...
Erreprodukziorik badago, uste dut berriro saiatuko gara estrategiekin esperimentatu eta hodeiak eskatzen diguna nola saiatu eta ulertuko dugula. Agian egonkorra izango da guretzat hiru konexiotan eta ez du konexioa etengo, orduan kontu handiz hirura iritsiko gara. Orain konexioa oso azkar kentzen dugulako, hau da, 16 harirekin berreskurapena abiarazi badugu, lehen berriro saiatu ondoren 8 hari, 4 hari, 2 hari eta bat egongo dira. Eta gero fitxategia korronte batera eramango du. Balio magiko batzuk badaude, adibidez, 7,5 hariak ponpatzeko egokienak dira, orduan horietan sakonduko gara eta beste 7,5 hari egiten saiatuko gara. Hona hemen ideia bat.
Eskerrik asko erreportajeagatik! Nolakoa da WAL-G-rekin lan egiteko lan-fluxu osoa? Adibidez, orrietan deltarik ez dagoen kasu ergeletan. Eta hasierako babeskopia hartu eta kentzen dugu, ondoren ardatza artxibatu arte aurpegia urdina izan arte. Hemen, nik ulertzen dudanez, matxura bat dago. Uneren batean orrialdeen delta babeskopia egin behar duzu, hau da, kanpoko prozesuren batek hau gidatzen ari da edo nola gertatzen da hau?
Delta backup APIa nahiko erraza da. Zenbaki bat dago hor: delta-urrats maximoak, horrela deitzen da. Lehenetsita zero da. Horrek esan nahi du babeskopia-push bat egiten duzun bakoitzean babeskopia osoa deskargatzen duela. Zenbaki positiboren bat aldatzen baduzu, adibidez, 3, babeskopia-push bat egiten duzun hurrengoan, aurreko babeskopien historiari begiratzen dio. 3 deltako katea gainditzen ez duzula ikusten du eta delta bat egiten du.
Hau da, WAL-G abiarazten dugun bakoitzean babeskopia osoa egiten saiatzen al da?
Ez, WAL-G exekutatzen dugu, eta delta bat egiten saiatzen da zure politikek hala onartzen badute.
Gutxi gorabehera, aldi bakoitzean zerorekin exekutatzen baduzu, pg_basebackup bezalakoa izango da?
Ez, oraindik azkarrago ibiliko da konpresioa eta paralelismoa erabiltzen dituelako. Pg_basebackup-ek ardatza zure ondoan jarriko du. WAL-G-k artxiboa konfiguratuta duzula suposatzen du. Eta abisu bat emango du konfiguratuta ez badago.
Pg_basebackup ardatzik gabe exekutatu daiteke.
Bai, orduan ia berdin jokatuko dute. Pg_basebackup fitxategi-sisteman kopiatzen da. Bide batez, aipatzea ahaztu zait eginbide berri bat dugu. Orain fitxategi-sisteman babeskopia egin dezakegu pg_basebackup-etik. Ez dakit zergatik behar den hau, baina hor dago.
Adibidez, CephFS-en. Denek ez dute objektuen biltegiratzea konfiguratu nahi.
Bai, ziurrenik horregatik egin dute eginbide honi buruzko galdera bat egin ahal izateko. Eta egin genuen.
Eskerrik asko erreportajeagatik! Fitxategi-sistemara kopiatzeari buruzko galdera bat besterik ez dago. Kutxatik kanpo, orain onartzen al duzu urruneko biltegiratze kopiatzea, adibidez, datu-zentroan apalategiren bat edo beste zerbait badago?
Formulazio honetan, galdera zaila da. Bai, onartzen dugu, baina funtzionalitate hau ez dago oraindik inongo bertsioetan. Hau da, aurre-argitalpen guztiek onartzen dute hori, baina kaleratze-bertsioek ez. Funtzionalitate hau 0.2 bertsioan gehitu zen. Zalantzarik gabe, laster kaleratuko da, ezagutzen diren akats guztiak konpondu bezain laster. Baina oraintxe hau aurre-argitalpenean bakarrik egin daiteke. Aurre-oharra bi akats daude. WAL-E berreskuratzeko arazoa, ez dugu konpondu. Eta azken aurreko bertsioan delta-backup-ari buruzko akats bat gehitu zen. Hori dela eta, denei gomendatzen diegu kaleratzeko bertsioak erabiltzea. Aurre-argitalpenean akats gehiago ez dagoen bezain laster, Google Cloud, S3-rekin bateragarriak diren gauzak eta fitxategiak biltegiratzea onartzen ditugula esan dezakegu.
Kaixo, eskerrik asko erreportajeagatik. Nik ulertzen dudanez, WAL-G ez al da tabernariak bezalako sistema zentralizatu bat? Ildo horretatik aurrera egiteko asmoa duzu?
Arazoa da norabide horretatik urrundu garela. WAL-G oinarrizko ostalarian, klusterreko ostalarian eta klusterreko ostalari guztietan bizi da. Hainbat mila multzotara joan ginenean, tabernarien instalazio asko genituen. Eta haiengan zerbait apurtzen den bakoitzean arazo handia da. Konpondu behar direnez, ulertu behar duzu zein klusterek ez duten babeskopiarik. Ez dut WAL-G garatzeko asmorik segurtasun-sistemetarako hardware fisikoaren norabidean. Komunitateak hemen funtzionalitate batzuk nahi baditu, ez zait batere axola.
Biltegiratzeaz arduratzen diren taldeak ditugu. Eta hain ondo sentitzen gara gu ez garela, badirela pertsona bereziak gure fitxategiak fitxategiak seguru dauden lekuan jartzen dituena. Era guztietako kodeketa burutsuak egiten dituzte bertan fitxategi kopuru jakin baten galerari aurre egiteko. Sareko banda zabaleraren arduradunak dira. Tabernari bat duzunean, baliteke bat-batean trafiko asko duten datu-base txikiak bildu direla zerbitzari berean. Leku asko daukazula dirudi, baina arrazoiren batengatik dena ez da sarearen bidez sartzen. Baliteke alderantziz gertatzea. Bertan sare asko daude, prozesadore nukleoak daude, baina hemen ez dago diskorik. Eta nekatu egin ginen zerbait malabareak egiteko behar honetaz, eta datuen biltegiratzea zerbitzu bereizi bat dela izatera pasatu ginen, eta horren ardura duten pertsona berezi bereiziak dira.
PS Bertsio berri bat kaleratu da , eta bertan .walg.json konfigurazio fitxategia erabil dezakezu, lehenespenez postgres hasierako direktorioan dagoena. Bash script-ak alde batera utzi ditzakezu. .walg.json adibidea ale honetan dago
Video:
Iturria: www.habr.com