Unë ju sugjeroj të lexoni transkriptin e raportit nga fillimi i vitit 2019 nga Andrey Borodin "Rezervime me WAL-G. Çfarë ka në 2019?"
Pershendetje te gjitheve! Emri im është Andrey Borodin. Unë jam një zhvillues në Yandex. Unë kam qenë i interesuar për PostgreSQL që nga viti 2016, pasi fola me zhvilluesit dhe ata thanë se gjithçka është e thjeshtë - ju merrni kodin burimor dhe ndërtoni atë, dhe gjithçka do të funksionojë. Dhe që atëherë nuk mund të ndalem - shkruaj lloj-lloj gjëra të ndryshme.
Një nga gjërat për të cilat jam duke punuar është një sistem rezervë. . Në përgjithësi, në Yandex ne kemi punuar në sistemet rezervë në PostgreSQL për një kohë shumë të gjatë. Dhe mund të gjeni në internet një seri prej gjashtë raportesh se si ne krijojmë sisteme rezervë. Dhe çdo vit ata evoluojnë pak, zhvillohen pak dhe bëhen më të besueshëm.
Por sot raporti nuk ka të bëjë vetëm me atë që kemi bërë, por edhe me atë se sa e thjeshtë është dhe çfarë është. Sa prej jush i kanë parë tashmë raportet e mia rreth WAL-G? Është mirë që jo pak njerëz nuk e kanë parë, sepse do të filloj me gjënë më të thjeshtë.
Nëse befas keni një grup PostgreSQL, dhe mendoj se të gjithë kanë disa prej tyre me vete, dhe befas nuk ka ende një sistem rezervë, atëherë duhet të merrni ndonjë ruajtje S3 ose memorie të përputhshme me Google Cloud.
Për shembull, mund të vini në stendën tonë dhe të merrni një kod promocional për ruajtjen e objekteve Yandex, i cili është i pajtueshëm me S3.
Pastaj krijoni një kovë. Është vetëm një enë për informacion.
Krijoni një përdorues shërbimi.
Krijo një çelës aksesi për përdoruesin e shërbimit: aws-s3-key.
Shkarkoni versionin më të fundit të qëndrueshëm të WAL-G.
Si ndryshojnë publikimet tona paraprake nga publikimet? Shpesh më kërkohet të lirohem herët. Dhe nëse nuk ka gabim në version për një kohë të mjaftueshme, për shembull, një muaj, atëherë unë e lëshoj atë. Këtu është ky publikim nga nëntori. Dhe kjo do të thotë që çdo muaj kemi gjetur një lloj gabimi, zakonisht në funksionalitet jo kritik, por ende nuk kemi lëshuar një version. Versioni i mëparshëm është vetëm nëntori. Nuk ka të meta të njohura për ne në të, d.m.th., gabimet u shtuan ndërsa projekti përparonte.
Pasi të keni shkarkuar WAL-G, mund të ekzekutoni një komandë të thjeshtë “backup list”, duke kaluar në variablat e mjedisit. Dhe do të lidhet me Object Storage dhe do t'ju tregojë se çfarë kopjesh rezervë keni. Në fillim, natyrisht, nuk duhet të keni kopje rezervë. Qëllimi i këtij rrëshqitje është të tregojë se gjithçka është mjaft e thjeshtë. Kjo është një komandë konsole që pranon variablat e mjedisit dhe ekzekuton nënkomandat.
Pas kësaj, mund të bëni kopjen rezervë të parë. Thoni "backup-push" në WAL-G dhe specifikoni në WAL-G vendndodhjen pgdata të grupit tuaj. Dhe ka shumë të ngjarë, PostgreSQL do t'ju tregojë, nëse nuk keni tashmë një sistem rezervë, se duhet të aktivizoni "arkivimin".
Kjo do të thotë që ju duhet të shkoni te cilësimet dhe të aktivizoni "archive_mode = on" dhe të shtoni "archive_command", e cila është gjithashtu një nënkomandë në WAL-G. Por për disa arsye njerëzit shpesh përdorin skriptet e shiritit për këtë temë dhe e mbështjellin atë rreth WAL-G. Ju lutemi mos e bëni këtë. Përdorni funksionalitetin e gjetur në WAL-G. Nëse ju mungon diçka, shkruani . WAL-G supozon se është i vetmi program që funksionon në archive_command.
Ne përdorim WAL-G kryesisht për të krijuar një grup me disponueshmëri të lartë në menaxhimin e bazës së të dhënave Yandex.
Dhe zakonisht përdoret në një topologji me një Master dhe disa përsëritje. Në të njëjtën kohë, ai bën një kopje rezervë në ruajtjen e objekteve Yandex.
Skenarët më të zakonshëm janë krijimi i kopjeve të një grupi duke përdorur Rimëkëmbjen e pikës në kohë. Por në këtë rast, performanca e sistemit rezervë nuk është aq e rëndësishme për ne. Thjesht duhet të ngarkojmë një grup të ri nga rezervimi.
Në mënyrë tipike, ne kemi nevojë për performancën e sistemit rezervë kur shtojmë një nyje të re. Pse është e rëndësishme? Zakonisht njerëzit shtojnë një nyje të re në një grup, sepse grupi ekzistues nuk mund të përballojë ngarkesën e leximit. Ata duhet të shtojnë një kopje të re. Nëse shtojmë ngarkesën nga pg_basebackup në Master, atëherë Masteri mund të shembet. Prandaj, ishte shumë e rëndësishme për ne që të mund të ngarkonim shpejt një nyje të re nga arkivi, duke krijuar ngarkesë minimale në Master.
Dhe një situatë tjetër e ngjashme. Kjo është nevoja për të rifilluar Masterin e vjetër pas ndërrimit të Cluster Master nga Qendra e të Dhënave me të cilën lidhja ka humbur.
- Si rezultat, kur formuluam kërkesat për sistemin e kopjimit, kuptuam se pg_basebackup nuk është i përshtatshëm për ne kur operojmë në re.
- Ne donim të ishim në gjendje të kompresonim të dhënat tona. Por pothuajse çdo sistem rezervë përveç atij që vjen në kuti do të sigurojë kompresim të të dhënave.
- Ne donim të paralelizonim gjithçka sepse një përdorues në cloud blen një numër të madh bërthamash procesori. Por nëse nuk kemi paralelizëm në ndonjë operacion, atëherë një numër i madh bërthamash bëhet i padobishëm.
- Ne kemi nevojë për enkriptim sepse shpesh të dhënat nuk janë tonat dhe nuk mund të ruhen në tekst të qartë. Nga rruga, kontributi ynë në WAL-G filloi me kriptim. Ne përfunduam kriptimin në WAL-G, pas së cilës na pyetën: "Ndoshta njëri prej nesh do ta zhvillojë projektin?" Dhe që atëherë unë kam punuar me WAL-G për më shumë se një vit.
- Ne gjithashtu kishim nevojë për mbytjen e burimeve, sepse me kalimin e kohës duke përdorur renë, zbuluam se ndonjëherë njerëzit kanë një ngarkesë të rëndësishme ushqimore gjatë natës dhe kjo ngarkesë nuk mund të ndërhyhet. Kjo është arsyeja pse ne shtuam frenimin e burimeve.
- Si dhe listimi dhe menaxhimi.
- Dhe verifikimi.
Ne shikuam shumë mjete të ndryshme. Për fat të mirë, ne kemi një përzgjedhje të madhe në PostgreSQL. Dhe kudo na mungonte diçka, dikujt një funksion i vogël, dikujt një veçori e vogël.
Dhe pasi kemi ekzaminuar sistemet ekzistuese, kemi arritur në përfundimin se do të zhvillojmë WAL-G. Ishte një projekt i ri atëherë. Ishte mjaft e lehtë të ndikonte në zhvillimin drejt infrastrukturës cloud të sistemit rezervë.
Ideologjia kryesore që ne i përmbahemi është se WAL-G duhet të jetë aq e thjeshtë sa një balalaika.
WAL-G ka 4 komanda. Kjo:
WAL-PUSH - arkivoni boshtin.
WAL-FETCH - merrni një bosht.
BACKUP-PUSH – bëni një kopje rezervë.
BACKUP-FETCH – merrni një kopje rezervë nga sistemi rezervë.
Në fakt, WAL-G gjithashtu ka menaxhimin e këtyre kopjeve rezervë, d.m.th. liston dhe fshin të dhënat dhe kopjet rezervë në histori që nuk janë më të nevojshme për momentin.
Një nga funksionet e rëndësishme për ne është funksioni i krijimit të kopjeve delta.
Kopjet Delta do të thotë që ne nuk krijojmë një kopje rezervë të plotë të të gjithë grupit, por vetëm faqet e ndryshuara të skedarëve të ndryshuar në grup. Duket se funksionalisht kjo është shumë e ngjashme me aftësinë për të rikuperuar duke përdorur WAL. Por ne mund të mbledhim paralelisht një kopje rezervë delta me një fije WAL. Prandaj, kur kemi një kopje rezervë bazë të bërë të Shtunën, kopje rezervë delta çdo ditë, dhe të enjten dështojmë, atëherë duhet të mbledhim 4 kopje rezervë delta dhe 10 orë WAL. Do të zgjasë pothuajse e njëjta kohë sepse kopjet rezervë delta rrotullohen paralelisht.
Deltat e bazuara në LSN - kjo do të thotë që kur krijojmë një kopje rezervë, do të na duhet të kombinojmë secilën faqe dhe të kontrollojmë LSN-në e saj me LSN-në e kopjes rezervë të mëparshme në mënyrë që të kuptojmë se ajo ka ndryshuar. Çdo faqe që mund të përmbajë potencialisht të dhëna të ndryshuara duhet të jetë e pranishme në kopjen rezervë delta.
Siç thashë, paralelizmit i është kushtuar shumë vëmendje.
Por API-ja e arkivit në PostgreSQL është e qëndrueshme. PostgreSQL arkivon një skedar WAL dhe kur e rivendos atë kërkon një skedar WAL. Por kur baza e të dhënave kërkon një skedar WAL duke përdorur komandën "WAL-FETCH", ne e quajmë komandën "WAL-PREFETCH", e cila përgatit 8 skedarët e ardhshëm për të marrë të dhëna nga dyqani i objekteve paralelisht.
Dhe kur baza e të dhënave na kërkon të arkivojmë një skedar, ne shikojmë archive_status dhe shohim nëse ka skedarë të tjerë WAL. Dhe ne po përpiqemi gjithashtu të shkarkojmë WAL paralelisht. Kjo siguron një fitim të konsiderueshëm të performancës dhe redukton ndjeshëm distancën në numrin e WAL-ve të paarkivuara. Shumë zhvillues të sistemeve rezervë besojnë se ky është një sistem kaq i rrezikshëm sepse ne mbështetemi në njohuritë tona për brendësinë e kodit që nuk është PostgreSQL API. PostgreSQL nuk garanton praninë e dosjes archive_status për ne dhe nuk garanton semantikën, praninë e sinjaleve të gatishmërisë për skedarët WAL atje. Sidoqoftë, ne po studiojmë kodin burimor, shohim që është kështu dhe po përpiqemi ta shfrytëzojmë atë. Dhe ne kontrollojmë drejtimin në të cilin po zhvillohet PostgreSQL; nëse papritmas ky mekanizëm prishet, ne do të ndalojmë përdorimin e tij.
Në formën e tij të pastër, delta WAL e bazuar në LSN kërkon leximin e çdo skedari grupi, koha e modalitetit të të cilit në sistemin e skedarëve ka ndryshuar që nga rezervimi i mëparshëm. Ne jetuam me këtë për një kohë të gjatë, gati një vit. Dhe në fund arritëm në përfundimin se kemi delta WAL.
Kjo do të thotë që sa herë që arkivojmë WAL në Master, jo vetëm që e kompresojmë, e kodojmë dhe e dërgojmë në rrjet, por edhe e lexojmë në të njëjtën kohë. Ne analizojmë dhe lexojmë të dhënat në të. Ne e kuptojmë se cilat blloqe kanë ndryshuar dhe mbledhim skedarë delta.
Një skedar delta përshkruan një gamë të caktuar skedarësh WAL, përshkruan informacione se cilat blloqe janë ndryshuar në këtë gamë të WAL. Dhe pastaj këto skedarë delta arkivohen gjithashtu.
Këtu përballemi me faktin se kemi paralelizuar gjithçka shumë shpejt, por nuk mund të lexojmë paralelisht një histori të njëpasnjëshme, sepse në një segment të caktuar mund të ndeshemi me fundin e rekordit të mëparshëm WAL, me të cilin ende nuk kemi çfarë të lidhim, sepse. leximi paralel bëri që fillimisht të analizojmë të ardhmen, e cila nuk ka ende të kaluar.
Si rezultat, ne duhej të vendosnim pjesë të pakuptueshme në skedarët _delta_partial. Si rezultat, kur të kthehemi në të kaluarën, ne do t'i ngjisim pjesët e rekordit WAL në një, pas kësaj do ta analizojmë atë dhe do të kuptojmë se çfarë ka ndryshuar në të.
Nëse në historinë e analizës së boshtit tonë ka të paktën një pikë ku nuk e kuptojmë se çfarë po ndodhte, atëherë, në përputhje me rrethanat, gjatë rezervimit të ardhshëm do të detyrohemi të lexojmë përsëri të gjithë grupimin, ashtu siç bëmë me një LSN të rregullt - delta me bazë.
Si rezultat, të gjitha vuajtjet tona çuan në faktin se ne kemi pasur burim të hapur bibliotekën analizuese WAL-G. Me sa di unë, askush nuk e përdor ende, por nëse dikush dëshiron ta shkruajë dhe ta përdorë, është në domenin publik. (Lidhja e përditësuar )
Si rezultat, të gjitha rrjedhat e informacionit duken mjaft të ndërlikuara. Masteri ynë arkivon boshtin dhe arkivon skedarët delta. Dhe kopja që bën kopjen rezervë duhet të marrë skedarë delta gjatë kohës që ka kaluar midis kopjeve rezervë. Në këtë rast, pjesë të historisë do të duhet të shtohen në masë dhe të analizohen, sepse jo e gjithë historia përshtatet në segmente të mëdha. Dhe vetëm pas kësaj kopja mund të arkivojë një kopje rezervë të plotë të delta.
Në grafikët gjithçka duket shumë më e thjeshtë. Ky është një shkarkim nga një nga grupimet tona reale. Ne kemi bazë LSN, të prodhuar në një ditë. Dhe ne shohim se rezervimi delta i bazuar në LSN po funksiononte nga tre në mëngjes deri në pesë të mëngjesit. Kjo është ngarkesa në numrin e bërthamave të procesorit. WAL-delta këtu na mori rreth 20 minuta, domethënë u bë dukshëm më i shpejtë, por në të njëjtën kohë pati një shkëmbim më intensiv në rrjet.
Meqenëse kemi informacione se cilat blloqe ndryshuan dhe në cilën kohë në historinë e bazës së të dhënave, ne shkuam më tej dhe vendosëm të integrojmë funksionalitetin - një shtesë PostgreSQL e quajtur "pg_prefaulter"
Kjo do të thotë që kur baza e gatishmërisë ekzekuton komandën e rivendosjes, i thotë WAL-G të marrë skedarin tjetër WAL. Ne e kuptojmë afërsisht se cilat blloqe të dhënash do të ketë akses procesi i rikuperimit WAL në të ardhmen e afërt dhe do të fillojë një operacion leximi në këto blloqe. Kjo është bërë për të rritur performancën e kontrollorëve SSD. Sepse lista e WAL do të arrijë në faqen që duhet ndryshuar. Kjo faqe është në disk dhe nuk është në memorien e faqes. Dhe ai do të presë në mënyrë sinkrone që kjo faqe të arrijë. Por aty pranë është WAL-G, i cili e di se në disa qindra megabajt të ardhshëm të WAL do të kemi nevojë për faqe të caktuara dhe në të njëjtën kohë fillon t'i ngrohë ato. Fillon aksese të shumta në disk në mënyrë që ato të ekzekutohen paralelisht. Kjo funksionon mirë në disqet SSD, por, për fat të keq, nuk është absolutisht e zbatueshme për një hard disk, sepse ne ndërhyjmë me të vetëm me kërkesat tona.
Kjo është ajo që është në kod tani.
Ka veçori që ne do të dëshironim të shtonim.
Kjo foto tregon se WAL-delta merr një kohë relativisht të shkurtër. Dhe ky është leximi i ndryshimeve që ndodhën në bazën e të dhënave gjatë ditës. Ne mund të bënim WAL-delta jo vetëm natën, sepse nuk është më një burim i rëndësishëm ngarkese. Ne mund të lexojmë WAL-delta çdo minutë sepse është i lirë. Në një minutë mund të skanojmë të gjitha ndryshimet që kanë ndodhur në grup. Dhe kjo mund të quhet "delta e menjëhershme WAL".
Çështja është se kur rivendosim grupin, zvogëlojmë numrin e historive që duhet të grumbullojmë në mënyrë sekuenciale. Kjo do të thotë, sasia e WAL që hedh PostgreSQL duhet të reduktohet, sepse kërkon kohë të konsiderueshme.
Por kjo nuk është e gjitha. Nëse e dimë se një pjesë e bllokut do të ndryshohet deri në pikën e konsistencës rezervë, nuk mund ta ndryshojmë atë në të kaluarën. Kjo do të thotë, tani kemi optimizimin skedar për skedar të përcjelljes WAL-delta. Kjo do të thotë që nëse, për shembull, të martën një tabelë është fshirë plotësisht ose disa skedarë janë fshirë tërësisht nga tabela, atëherë kur delta të rikthehet të hënën dhe të rikthehet pg_basebackup të së shtunës, ne as nuk do t'i krijojmë këto të dhëna.
Ne duam ta zgjerojmë këtë teknologji në nivelin e faqes. Kjo do të thotë, nëse një pjesë e skedarit ndryshon të hënën, por do të mbishkruhet të mërkurën, atëherë kur rikthehemi në një pikë të enjten, nuk kemi nevojë të shkruajmë versionet e para të faqeve në disk.
Por kjo është ende një ide që po diskutohet aktivisht brenda nesh, por ende nuk ka arritur kodin.
Ne duam të bëjmë një veçori më shumë në WAL-G. Ne duam ta bëjmë atë të zgjerueshme, sepse ne kemi nevojë të mbështesim baza të ndryshme të të dhënave dhe do të dëshironim të jemi në gjendje t'i qasemi menaxhimit të rezervave në të njëjtën mënyrë. Por problemi është se API-të e MySQL janë rrënjësisht të ndryshme. Në MySQL, PITR nuk bazohet në regjistrin fizik të WAL, por në binlog. Dhe ne nuk kemi një sistem arkivimi në MySQL që do t'i tregonte një sistemi të jashtëm se ky binlog ka përfunduar dhe duhet të arkivohet. Duhet të qëndrojmë diku në cron me bazën e të dhënave dhe të kontrollojmë nëse ka diçka gati?
Dhe në të njëjtën mënyrë, gjatë një rivendosjeje të MySQL, nuk ka asnjë komandë rivendosjeje që mund t'i tregojë sistemit se kam nevojë për skedarë të tillë. Përpara se të filloni të rindërtoni grupin tuaj, duhet të dini se cilat skedarë do t'ju nevojiten. Ju vetë duhet të merrni me mend se cilat skedarë do t'ju nevojiten. Por këto probleme mund të jenë në gjendje të anashkalohen disi. (Sqarim: MySQL është tashmë i mbështetur)
Në raport doja të flisja edhe për ato raste kur WAL-G nuk është i përshtatshëm për ju.
Nëse nuk keni një kopje sinkrone, WAL-G nuk garanton se segmenti i fundit do të ruhet. Dhe nëse arkivimi mbetet pas segmenteve të fundit të historisë, ky është një rrezik. Nëse nuk ka kopje sinkrone, nuk do të rekomandoja përdorimin e WAL-G. Megjithatë, është projektuar kryesisht për një instalim cloud, që nënkupton një zgjidhje me disponueshmëri të lartë me një kopje sinkrone, e cila është përgjegjëse për sigurinë e bajteve të fundit të kryera.
Unë shpesh shoh njerëz që përpiqen të drejtojnë WAL-G dhe WAL-E në të njëjtën kohë. Ne mbështesim pajtueshmërinë e prapambetur në kuptimin që WAL-G mund të rivendosë një skedar nga WAL-E dhe mund të rivendosë një kopje rezervë të bërë në WAL-E. Por duke qenë se të dy këto sisteme përdorin wal-push paralel, ata fillojnë të vjedhin skedarë nga njëri-tjetri. Nëse e rregullojmë në WAL-G, do të mbetet akoma në WAL-E. Në WAL-E, ai shikon statusin e arkivit, sheh skedarët e përfunduar dhe i arkivon ato, ndërsa sistemet e tjera thjesht nuk do ta dinë që ky skedar WAL ekzistonte, sepse PostgreSQL nuk do të përpiqet ta arkivojë atë për herë të dytë.
Çfarë do të rregullojmë këtu në anën WAL-G? Ne nuk do të informojmë PostgreSQL se ky skedar është transferuar paralelisht dhe kur PostgreSQL të na kërkojë ta arkivojmë, ne do të dimë tashmë se një skedar i tillë me këtë kohë-mode dhe me këtë md5 tashmë është arkivuar dhe thjesht do të themi PostgreSQL - OK, gjithçka është gati pa bërë asgjë në thelb.
Por ky problem nuk ka gjasa të zgjidhet në anën WAL-E, kështu që aktualisht është e pamundur të krijohet një komandë arkivimi që do të arkivojë skedarin si në WAL-G ashtu edhe në WAL-E.
Përveç kësaj, ka raste kur WAL-G nuk është i përshtatshëm për ju tani, por ne patjetër do ta rregullojmë atë.
Së pari, aktualisht nuk kemi verifikim rezervë të integruar. Nuk kemi verifikim as gjatë kopjimit, as gjatë rikuperimit. Sigurisht, kjo zbatohet në re. Por kjo zbatohet thjesht duke kontrolluar paraprakisht, thjesht duke rivendosur grupin. Do të doja t'ua jepja këtë funksion përdoruesve. Por me verifikim, supozoj se në WAL-G do të jetë e mundur të rivendosni grupin dhe ta nisni atë, dhe të ekzekutoni testet e tymit: pg_dumpall në /dev/null dhe verifikimin e indeksit amcheck.
Aktualisht në WAL-G nuk ka asnjë mënyrë për të shtyrë një kopje rezervë nga WAL. Kjo do të thotë, ne mbështesim një dritare. Për shembull, ruajtja e shtatë ditëve të fundit, ruajtja e dhjetë kopjeve rezervë të fundit, ruajtja e tre kopjeve rezervë të plotë të fundit. Shumë shpesh njerëzit vijnë dhe thonë: "Ne kemi nevojë për një kopje rezervë të asaj që ndodhi në Vitin e Ri dhe ne duam ta mbajmë atë përgjithmonë". WAL-G nuk mund ta bëjë këtë ende. (Shënim - Kjo tashmë është rregulluar. Lexo më shumë - Opsioni për shënimin rezervë në )
Dhe ne nuk kemi kontrolle të faqeve dhe kontrolle të integritetit për të gjitha segmentet e boshtit kur vërtetojmë PITR.
Nga e gjithë kjo kam bashkuar një projekt për Google Summer of Code. Nëse njihni studentë të zgjuar që do të dëshironin të shkruanin diçka në Go dhe të merrnin disa mijëra dollarë nga një kompani me shkronjën "G", atëherë rekomandojini atyre projektin tonë. Unë do të veproj si mentor për këtë projekt, ata mund ta bëjnë. Nëse nuk ka studentë, atëherë do ta marr dhe do ta bëj vetë në verë.
Dhe ne kemi shumë probleme të tjera të vogla për të cilat po punojmë gradualisht. Dhe ndodhin disa gjëra mjaft të çuditshme.
Për shembull, nëse i jepni WAL-G një kopje rezervë bosh, ai thjesht do të bjerë. Për shembull, nëse i thoni atij se duhet të kopjojë një dosje bosh. Skedari pg_control nuk do të jetë aty. Dhe ai do të mendojë se nuk kupton diçka. Në teori, në këtë rast ju duhet t'i shkruani një mesazh normal përdoruesit për t'i shpjeguar atij se si të përdorë mjetin. Por kjo nuk është as një veçori e programimit, por një veçori e një gjuhe të mirë e të kuptueshme.
Nuk dimë si të bëjmë kopje rezervë jashtë linje. Nëse baza e të dhënave është gënjeshtare, ne nuk mund ta kopjojmë atë. Por gjithçka është shumë e thjeshtë këtu. Ne thërrasim kopje rezervë nga LSN kur filloi. LSN-ja e bazës bazë duhet të lexohet nga skedari i kontrollit. Dhe kjo është një veçori kaq e parealizuar. Shumë sisteme rezervë mund të kopjojnë një bazë të dhënash bazë. Dhe është i përshtatshëm.
Aktualisht nuk mund ta trajtojmë siç duhet mungesën e hapësirës rezervë. Sepse ne zakonisht punojmë me kopje rezervë të mëdha në shtëpi. Dhe ata nuk iu afruan. Por nëse dikush dëshiron të programojë në Go tani, shtoni trajtimin për gabimet jashtë hapësirës në kovë. Do të shqyrtoj patjetër kërkesën për tërheqje.
Dhe gjëja kryesore që na shqetëson është se duam sa më shumë teste të integrimit të dokerit që të kontrollojnë skenarë të ndryshëm. Tani për tani ne po testojmë vetëm skenarë bazë. Në çdo commit, por ne duam të kontrollojmë commit-by-commit të gjithë funksionalitetin që ne mbështesim. Në veçanti, për shembull, do të kemi mbështetje të mjaftueshme për PostgreSQL 9.4-9.5. Ne i mbështesim ata sepse komuniteti mbështet PostgreSQL, por ne nuk kontrollojmë commit-by-commit për t'u siguruar që gjithçka nuk është prishur. Dhe më duket se ky është një rrezik mjaft serioz.
Ne kemi WAL-G që funksionon në më shumë se një mijë grupime në menaxhimin e bazës së të dhënave Yandex. Dhe rezervon disa qindra terabajt të dhëna çdo ditë.
Ne kemi shumë TODO në kodin tonë. Nëse doni të programoni, ejani, ne presim kërkesa për tërheqje, presim pyetje.
Pyetjet tuaja
Mirembrema! Faleminderit! Supozimi im është se nëse jeni duke përdorur WAL-delta, me siguri po mbështeteni shumë në shkrimet në faqe të plota. Dhe nëse po, a keni kryer teste? Ju treguat një grafik të bukur. Sa më e bukur bëhet nëse FPW fiket?
Shkrimi në faqe të plotë është i aktivizuar për ne, nuk jemi përpjekur ta çaktivizojmë. Kjo do të thotë, unë, si zhvillues, nuk jam përpjekur ta çaktivizoj. Administratorët e sistemit që kanë hulumtuar ndoshta e kanë hulumtuar këtë çështje. Por ne kemi nevojë për FPW. Pothuajse askush nuk e çaktivizon atë, sepse përndryshe është e pamundur të marrësh një kopje rezervë nga një kopje.
Faleminderit për raportin! Kam dy pyetje. Pyetja e parë është se çfarë do të ndodhë me hapësirat e tavolinës?
Ne jemi duke pritur për një kërkesë tërheqjeje. Bazat tona të të dhënave jetojnë në disqe SSD dhe NMVE dhe ne nuk kemi vërtet nevojë për këtë veçori. Nuk jam gati të kaloj kohë serioze tani për ta bërë atë mirë. Unë mbroj me gjithë zemër që ne ta mbështesim këtë. Ka njerëz që e kanë mbështetur, por e kanë përkrahur në mënyrën që u përshtatet. Ata bënë një pirun, por nuk bëjnë kërkesa për tërheqje. (Shtuar në versionin 0.2.13)
Dhe pyetja e dytë. Ju thatë që në fillim se WAL-G supozon se funksionon vetëm dhe nuk nevojiten mbështjellës. Unë vetë përdor mbështjellës. Pse nuk duhet të përdoren?
Ne duam që ajo të jetë aq e thjeshtë sa një balalaika. Kjo do të thotë që ju nuk keni nevojë për asgjë përveç një balalaika. Ne duam që sistemi të jetë i thjeshtë. Nëse keni funksionalitet që duhet të bëni në një skenar, atëherë ejani dhe na tregoni - ne do ta bëjmë atë në Go.
Mirembrema! Faleminderit për raportin! Nuk mundëm që WAL-G të punonte me deshifrimin e GPG. Ai kodon normalisht, por nuk dëshiron të deshifrojë. A është diçka që nuk na funksionoi? Situata është dëshpëruese.
Krijo një problem në GitHub dhe le ta kuptojmë.
Domethënë, nuk e keni hasur këtë?
Ekziston një veçori e raportit të gabimit që kur WAL-G nuk e kupton se çfarë lloj skedari është, ai pyet: "Ndoshta është i koduar?" Ndoshta problemi nuk është fare kriptimi. Unë dua të përmirësoj regjistrimin në këtë temë. Ai duhet ta deshifrojë atë. Aktualisht jemi duke punuar në këtë temë në kuptimin që nuk na pëlqen shumë mënyra se si është i organizuar sistemi për marrjen e çelësave publikë dhe privatë. Sepse ne e quajmë GPG të jashtme në mënyrë që të na japë çelësat e saj. Dhe më pas i marrim këta çelësa dhe i transferojmë në GPG-në e brendshme, e cila është PGP e hapur, e cila është përpiluar për ne brenda WAL-G, dhe atje e quajmë enkriptim. Në këtë drejtim, ne duam të përmirësojmë sistemin dhe duam të mbështesim enkriptimin e Libsodium (Shtuar në versionin 0.2.15). Sigurisht, deshifrimi duhet të funksionojë, le ta kuptojmë - ju duhet më shumë një simptomë sesa disa fjalë. Mund të mblidheni dikur në dhomën e folësit dhe të shikoni sistemin. (Kriptimi PGP pa GPG të jashtëm - v0.2.9)
Përshëndetje! Faleminderit për raportin! Kam dy pyetje. Unë kam një dëshirë të çuditshme për të bërë pg_basebackup dhe WAL log in dy ofrues, dmth dua të bëj një re dhe një tjetër. A ka ndonjë mënyrë për ta bërë këtë?
Kjo nuk ekziston tani, por është një ide interesante.
Unë thjesht nuk i besoj një ofruesi, dua të kem të njëjtën gjë në një tjetër, për çdo rast.
Ideja është interesante. Teknikisht, kjo nuk është aspak e vështirë për t'u zbatuar. Për të parandaluar humbjen e idesë, a mund t'ju kërkoj të bëni një problem në GitHub?
Po sigurisht.
Dhe më pas, kur studentët të vijnë në Google Summer of Code, ne do t'i shtojmë ata në projekt në mënyrë që të ketë më shumë punë për të përfituar më shumë prej tyre.
Dhe pyetja e dytë. Ka një problem në GitHub. Unë mendoj se tashmë është mbyllur. Ka një panik gjatë restaurimit. Dhe për ta mposhtur atë, ju bëtë një asamble të veçantë. Është e drejtë në çështje. Dhe ekziston një mundësi për të bërë një mjedis të ndryshueshëm në një fije. Dhe kjo është arsyeja pse funksionon shumë ngadalë. Dhe ne kemi hasur në këtë problem, dhe ai nuk është rregulluar ende.
Problemi është se për disa arsye ruajtja (CEPH) rivendos lidhjen kur ne vijmë tek ajo me njëkohshmëri të lartë. Çfarë mund të bëhet për këtë? Logjika e riprovës duket kështu. Po përpiqemi ta shkarkojmë sërish skedarin. Me një kalim, kishim një numër skedarësh të pa shkarkuar, do të bëjmë një të dytë për të gjithë ata që nuk u identifikuan. Dhe për sa kohë që të paktën një skedar ngarkohet për përsëritje, ne përsërisim dhe përsërisim dhe përsërisim. Përmirësuam logjikën e riprovimit - prapambetje eksponenciale. Por nuk është plotësisht e qartë se çfarë të bëhet me faktin se lidhja thjesht prishet në anën e sistemit të ruajtjes. Kjo do të thotë, kur ngarkojmë në një transmetim, ai nuk i prish këto lidhje. Çfarë mund të përmirësojmë këtu? Ne kemi mbytje të rrjetit, ne mund të kufizojmë çdo lidhje me numrin e bajteve që dërgon. Përndryshe, nuk di si të përballem me faktin që ruajtja e objekteve nuk na lejon të shkarkojmë ose shkarkojmë prej tij paralelisht.
Nuk ka SLA? A nuk është shkruar për ta se si e lejojnë veten të mundohen?
Çështja është se njerëzit që lindin me këtë pyetje zakonisht kanë kasafortën e tyre. Kjo do të thotë, askush nuk vjen nga Amazon ose Google Cloud ose Yandex Object Storage.
Ndoshta pyetja nuk është më për ju?
Pyetja këtu në këtë rast nuk ka rëndësi se kujt. Nëse ka ndonjë ide se si ta trajtojmë këtë, le ta bëjmë atë në WAL-G. Por deri më tani nuk kam ide të mira se si të përballem me këtë. Ka disa hapësirë ruajtëse të objekteve që mbështesin kopjet rezervë të listave ndryshe. Ju u kërkoni atyre të listojnë objektet dhe ata shtojnë dosje atje. WAL-G frikësohet nga kjo - ka një lloj gjëje këtu që nuk është skedar, nuk mund ta rivendos atë, që do të thotë se kopja rezervë nuk u rivendos. Kjo do të thotë, në fakt, ju keni një grup të restauruar plotësisht, por ai ju kthen një status të gabuar sepse Ruajtja e Objekteve ktheu disa informacione të çuditshme që nuk i kuptonte plotësisht.
Kjo është një gjë që ndodh në renë e postës.
Nëse mund të ndërtoni një riprodhim...
Riprodhohet vazhdimisht...
Nëse ka një riprodhim, atëherë mendoj se do të eksperimentojmë me strategjitë e riprovës dhe do të kuptojmë se si të riprovojmë dhe të kuptojmë se çfarë kërkon cloud nga ne. Ndoshta do të jetë e qëndrueshme për ne në tre lidhje dhe nuk do të prishë lidhjen, atëherë do të arrijmë me kujdes në tre. Sepse tani ne e heqim lidhjen shumë shpejt, d.m.th. nëse kemi nisur një rikuperim me 16 fije, atëherë pas riprovës së parë do të ketë 8 fije, 4 threads, 2 threads dhe një. Dhe pastaj do ta tërheqë skedarin në një transmetim. Nëse ka disa vlera magjike si 7,5 fijet janë më të mirat për pompim, atëherë ne do të ndalemi në to dhe do të përpiqemi të bëjmë 7,5 fije të tjera. Ja një ide.
Faleminderit për raportin! Si duket një rrjedhë e plotë e punës për të punuar me WAL-G? Për shembull, në rastin budalla kur nuk ka delta nëpër faqe. Dhe marrim dhe heqim rezervën fillestare, pastaj arkivojmë boshtin derisa të jemi blu në fytyrë. Këtu, siç e kuptoj unë, ka një avari. Në një moment ju duhet të bëni një kopje rezervë delta të faqeve, d.m.th. ndonjë proces i jashtëm po e drejton këtë apo si ndodh kjo?
API rezervë delta është mjaft i thjeshtë. Ka një numër atje - hapat max delta, kështu quhet. Parazgjedhja është zero. Kjo do të thotë që sa herë që bëni një shtytje rezervë, ai shkarkon një kopje rezervë të plotë. Nëse e ndryshoni atë në ndonjë numër pozitiv, për shembull, 3, atëherë herën tjetër që bëni një shtytje rezervë, ai shikon historinë e kopjeve rezervë të mëparshme. Ai sheh që ju nuk e kaloni zinxhirin prej 3 deltash dhe bën një deltë.
Kjo do të thotë, sa herë që ne lëshojmë WAL-G, ai përpiqet të bëjë një kopje rezervë të plotë?
Jo, ne ekzekutojmë WAL-G dhe ai përpiqet të krijojë një delta nëse politikat tuaja e lejojnë atë.
Përafërsisht, nëse e përdorni me zero çdo herë, a do të sillet si pg_basebackup?
Jo, do të vazhdojë të funksionojë më shpejt sepse përdor kompresim dhe paralelizëm. Pg_basebackup do ta vendosë boshtin pranë jush. WAL-G supozon se e keni konfiguruar arkivimin. Dhe do të lëshojë një paralajmërim nëse nuk është i konfiguruar.
Pg_basebackup mund të ekzekutohet pa boshte.
Po, atëherë ata do të sillen pothuajse njësoj. Pg_basebackup kopjon në sistemin e skedarëve. Meqë ra fjala, kemi një veçori të re që harrova ta përmend. Tani mund të bëjmë kopje rezervë në sistemin e skedarëve nga pg_basebackup. Nuk e di pse është e nevojshme kjo, por është aty.
Për shembull, në CephFS. Jo të gjithë duan të konfigurojnë Ruajtjen e Objekteve.
Po, kjo është ndoshta arsyeja pse ata bënë një pyetje në lidhje me këtë veçori në mënyrë që ne ta bëjmë atë. Dhe ne e bëmë atë.
Faleminderit për raportin! Ekziston vetëm një pyetje në lidhje me kopjimin në sistemin e skedarëve. Nga kutia, a e mbështetni tani kopjimin në ruajtje në distancë, për shembull, nëse ka ndonjë raft në qendrën e të dhënave apo diçka tjetër?
Në këtë formulim, kjo është një pyetje e vështirë. Po, ne e mbështesim, por ky funksionalitet nuk është përfshirë ende në asnjë version. Kjo do të thotë, të gjitha publikimet paraprake e mbështesin këtë, por versionet e lëshimit jo. Ky funksionalitet u shtua në versionin 0.2. Do të dalë patjetër së shpejti, sapo të rregullojmë të gjitha gabimet e njohura. Por tani për tani kjo mund të bëhet vetëm në para-lëshim. Ka dy gabime në para-lëshimin. Problem me rikuperimin e WAL-E, nuk e kemi rregulluar. Dhe në publikimin e fundit paraprak u shtua një gabim në lidhje me rezervimin e delta. Prandaj, ne rekomandojmë të gjithë të përdorin versionet e lëshimit. Sapo nuk ka më defekte në publikimin paraprak, mund të themi se mbështesim Google Cloud, gjëra të pajtueshme me S3 dhe ruajtjen e skedarëve.
Përshëndetje, faleminderit për raportin. Siç e kuptoj unë, WAL-G nuk është një lloj sistemi i centralizuar si barmenët? A planifikoni të ecni në këtë drejtim?
Problemi është se ne jemi larguar nga ky drejtim. WAL-G jeton në hostin bazë, në hostin e grupimit dhe në të gjithë hostet në grup. Kur u zhvendosëm në disa mijëra grupe, kishim shumë instalime banakieresh. Dhe sa herë që diçka prishet në to, është një problem i madh. Për shkak se ato duhet të riparohen, ju duhet të kuptoni se cilat grupime tani nuk kanë kopje rezervë. Unë nuk planifikoj të zhvilloj WAL-G në drejtim të pajisjeve fizike për sistemet rezervë. Nëse komuniteti dëshiron disa funksionalitet këtu, nuk më shqetëson fare.
Ne kemi ekipe që janë përgjegjëse për ruajtjen. Dhe ndihemi aq mirë sa nuk jemi ne, sa ka njerëz të veçantë që i vendosin skedarët tanë aty ku skedarët janë të sigurt. Ata bëjnë të gjitha llojet e kodimit të zgjuar atje për të përballuar humbjen e një numri të caktuar skedarësh. Ata janë përgjegjës për gjerësinë e brezit të rrjetit. Kur keni një banakier, mund të zbuloni papritur se bazat e të dhënave të vogla me shumë trafik janë mbledhur në të njëjtin server. Duket se keni shumë hapësirë në të, por për disa arsye gjithçka nuk përshtatet përmes rrjetit. Mund të rezultojë anasjelltas. Ka shumë rrjete atje, ka bërthama procesori, por këtu nuk ka disqe. Dhe ne u lodhëm nga kjo nevojë për të mashtruar diçka, dhe kaluam në faktin se ruajtja e të dhënave është një shërbim më vete, për të cilin janë përgjegjës njerëz të veçantë të veçantë.
P.S Një version i ri është lëshuar , në të cilin mund të përdorni skedarin e konfigurimit .walg.json, i cili si parazgjedhje ndodhet në drejtorinë kryesore të postgres. Ju mund të braktisni skriptet bash. Shembull .walg.json është në këtë numër
Video:
Burimi: www.habr.com