Ik stel foar dat jo it transkripsje fan it rapport fan it begjin fan 2019 lêze troch Andrey Borodin "Backups mei WAL-G. Wat is der yn 2019?"
Hoi allegearre! Myn namme is Andrey Borodin. Ik bin in ûntwikkelder by Yandex. Ik bin ynteressearre yn PostgreSQL sûnt 2016, nei't ik mei de ûntwikkelders praat en se seine dat alles ienfâldich is - jo nimme de boarnekoade en bouwe it, en alles sil wurkje. En sûnt kin ik net ophâlde - ik skriuw allerhanne ferskillende dingen.
Ien fan 'e dingen wêr't ik oan wurkje is in reservekopysysteem. . Yn 't algemien hawwe wy by Yandex in heule lange tiid wurke oan backupsystemen yn PostgreSQL. En jo kinne op it ynternet in searje fan seis rapporten fine oer hoe't wy backupsystemen meitsje. En elk jier ûntwikkelje se in bytsje, ûntwikkelje in bytsje en wurde betrouberer.
Mar hjoed giet it rapport net allinnich oer wat wy dien hawwe, mar ek oer hoe ienfâldich it is en wat is. Hoefolle fan jimme hawwe myn rapporten oer WAL-G al sjoen? It is goed dat hiel wat minsken net seagen, want ik sil begjinne mei it ienfâldichste.
As jo ynienen in PostgreSQL-kluster hawwe, en ik tink dat elkenien in pear fan har mei har hat, en ynienen is d'r noch gjin reservekopysysteem, dan moatte jo elke S3-opslach of Google Cloud-kompatibele opslach krije.
Jo kinne bygelyks nei ús stand komme en in promoasjekoade nimme foar Yandex Object Storage, dy't kompatibel is mei S3.
Dan meitsje in Bucket. It is gewoan in kontener foar ynformaasje.
Meitsje in tsjinst brûker.
Meitsje in tagongskaai foar de tsjinst brûker: aws-s3-key.
Download de lêste stabile release fan WAL-G.
Hoe binne ús pre-releases oars fan releases? Ik wurd faak frege om betiid frij te litten. En as d'r gjin brek is yn 'e ferzje foar in foldwaande tiid, bygelyks in moanne, dan lit ik it frij. Hjir is dizze release fan novimber. En dit betsjut dat wy elke moanne in soarte fan brek fûnen, meastentiids yn net-krityske funksjonaliteit, mar wy hawwe noch gjin release frijlitten. De foarige ferzje is allinich novimber. D'r binne gjin bugs bekend by ús yn it, dat wol sizze bugs waarden tafoege as it projekt foarútgong.
Sadree't jo hawwe ynladen WAL-G, kinne jo rinne in ienfâldige "reservekopy list" kommando, trochjaan yn de omjouwing fariabelen. En it sil ferbine mei Object Storage en jo fertelle hokker backups jo hawwe. Earst moatte jo fansels gjin backups hawwe. It punt fan dizze slide is om sjen te litten dat alles frij simpel is. Dit is in konsole-kommando dat omjouwingsfariabelen akseptearret en subkommando's útfiert.
Hjirnei kinne jo jo earste reservekopy meitsje. Sis "backup-push" yn WAL-G en spesifisearje yn WAL-G de pgdata-lokaasje fan jo kluster. En nei alle gedachten sil PostgreSQL jo fertelle, as jo net al in reservekopysysteem hawwe, dat jo "argyfmodus" moatte ynskeakelje.
Dit betsjut dat jo nei ynstellings moatte gean en "archive_mode = on" ynskeakelje en "archive_command" tafoegje, wat ek in subkommando is yn WAL-G. Mar om ien of oare reden brûke minsken faak barskripten oer dit ûnderwerp en wikkelje it om WAL-G. Doch dit asjebleaft net. Brûk de funksjonaliteit fûn yn WAL-G. As jo wat misse, skriuw dan nei . WAL-G giet derfan út dat it it ienige programma is dat rint yn archive_command.
Wy brûke WAL-G benammen om in kluster mei hege beskikberens te meitsjen yn Yandex-databasebehear.
En it wurdt normaal brûkt yn in topology fan ien Master en ferskate replikaasjes. Tagelyk makket it in reservekopy yn Yandex Object Storage.
De meast foarkommende senario's meitsje kopyen fan in kluster mei Point in time recovery. Mar yn dit gefal is de prestaasjes fan it reservekopysysteem net sa wichtich foar ús. Wy moatte gewoan in nij kluster uploade fan 'e reservekopy.
Typysk hawwe wy backupsysteemprestaasjes nedich by it tafoegjen fan in nije knooppunt. Wêrom is it wichtich? Typysk foegje minsken in nij knooppunt ta oan in kluster, om't it besteande kluster de lêslading net kin omgean. Se moatte in nije replika tafoegje. As wy de lading fan pg_basebackup tafoegje oan de Master, dan kin de Master ynstoarte. Dêrom wie it heul wichtich foar ús dat wy fluch in nije knooppunt út it argyf uploade koenen, wêrtroch minimale lading op 'e Master ûntstiet.
En in oare ferlykbere situaasje. Dit is de needsaak om de âlde Master opnij te begjinnen nei it wikseljen fan de Cluster Master fan it Data Center wêrmei't de ferbining ferlern gie.
- As gefolch hawwe wy by it formulearjen fan de easken foar it kopysysteem realisearre dat pg_basebackup net geskikt is foar ús by it operearjen yn 'e wolk.
- Wy woene ús gegevens kinne komprimearje. Mar hast alle reservekopy systeem oars dan wat komt yn it fak sil foarsjen gegevens kompresje.
- Wy woenen alles parallelisearje om't in brûker yn 'e wolk in grut oantal prosessorkearnen keapet. Mar as wy gjin parallellisme hawwe yn guon operaasjes, dan wurdt in grut oantal kearnen nutteloos.
- Wy hawwe fersifering nedich, om't de gegevens faaks net fan ús binne en net yn dúdlike tekst kinne wurde opslein. Trouwens, ús bydrage oan WAL-G begon mei fersifering. Wy foltôge de fersifering yn WAL-G, wêrnei't wy waarden frege: "Miskien sil ien fan ús it projekt ûntwikkelje?" En sûnt doe wurke ik mear as in jier mei WAL-G.
- Wy hawwe ek helpboarnen throttling nedich, om't wy yn 'e rin fan' e tiid mei help fan 'e wolk fûnen dat soms minsken nachts in wichtige boadskiplike lading hawwe en dizze lading kin net bemuoie. Dêrom hawwe wy resource throttling tafoege.
- Lykas list en behear.
- En ferifikaasje.
Wy seagen in protte ferskillende ark. Gelokkich hawwe wy in enoarme seleksje yn PostgreSQL. En oeral misten wy wat, wat ien lytse funksje, wat ien lyts funksje.
En nei't de besteande systemen ûndersocht hawwe, kamen wy ta de konklúzje dat wy WAL-G sille ûntwikkelje. It wie doe in nij projekt. It wie frij maklik om de ûntwikkeling nei de wolkynfrastruktuer fan it backupsysteem te beynfloedzjen.
De wichtichste ideology dêr't wy oan hâlde is dat WAL-G sa ienfâldich wêze moat as in balalaika.
WAL-G hat 4 kommando's. Dit:
WAL-PUSH - argyf de skacht.
WAL-FETCH - krije in skacht.
BACKUP-PUSH - meitsje in reservekopy.
BACKUP-FETCH - krije in reservekopy fan it backupsysteem.
Yn feite hat WAL-G ek behear fan dizze backups, d.w.s. records en backups yn 'e skiednis listje en wiskje dy't op it stuit net mear nedich binne.
Ien fan 'e wichtige funksjes foar ús is de funksje fan it meitsjen fan deltakopyen.
Delta-kopyen betsjutte dat wy gjin folsleine reservekopy meitsje fan it hiele kluster, mar allinich de feroare siden fan 'e feroare triemmen yn it kluster. It soe lykje dat dit funksjoneel hiel ferlykber is mei de mooglikheid om te herstellen mei WAL. Mar wy kinne parallel rôlje in WAL single-threaded delta backup. As wy dêrom in basis-backup hawwe makke op sneon, delta-backups deistich, en tongersdei mislearje wy, dan moatte wy 4 delta-backups en 10 oeren WAL oprolje. It sil sawat deselde tiid duorje om't de delta-backups parallel rôlje.
LSN-basearre delta's - dit betsjut dat by it meitsjen fan in reservekopy, wy elke side moatte kombinearje en syn LSN kontrolearje mei de LSN fan 'e foarige reservekopy om te begripen dat it is feroare. Elke side dy't mooglik feroare gegevens kin befetsje moat oanwêzich wêze yn 'e delta-backup.
Sa't ik al sei, der waard in soad omtinken jûn oan parallelisme.
Mar de argyf API yn PostgreSQL is konsekwint. PostgreSQL argivearret ien WAL-bestân en freget by it weromsetten ien WAL-bestân oan. Mar as de databank ien WAL-bestân freget mei it kommando "WAL-FETCH", neame wy it kommando "WAL-PREFETCH", dat de folgjende 8 bestannen taret om parallel gegevens fan 'e objektwinkel op te heljen.
En as de databank ús freget om ien bestân te argivearjen, sjogge wy nei archive_status en sjogge oft d'r oare WAL-bestannen binne. En wy besykje ek WAL parallel te downloaden. Dit soarget foar in signifikante prestaasjeswinst en ferminderet de ôfstân yn it oantal net-argivearre WAL's signifikant. In protte ûntwikkelders fan backupsysteem leauwe dat dit sa'n risikofolle systeem is, om't wy fertrouwe op ús kennis fan 'e ynterne koade dy't net de PostgreSQL API is. PostgreSQL garandearret de oanwêzigens fan 'e map archive_status foar ús net en garandearret de semantyk net, de oanwêzigens fan reewilligenssinjalen foar WAL-bestannen dêr. Dochs studearje wy de boarnekoade, wy sjogge dat dit sa is en wy besykje it te eksploitearjen. En wy kontrolearje de rjochting wêryn PostgreSQL ûntwikkelet; as dit meganisme ynienen brutsen is, sille wy ophâlde mei it brûken.
Yn syn suvere foarm fereasket LSN-basearre WAL delta it lêzen fan elk klusterbestân wêrfan de modustiid yn it bestânsysteem is feroare sûnt de foarige reservekopy. Dêr ha wy lang mei libbe, hast in jier. En op it lêst kamen wy ta de konklúzje dat wy WAL-deltas hawwe.
Dit betsjut dat elke kear as wy WAL op 'e Master argivearje, wy it net allinich komprimearje, fersiferje en stjoere nei it netwurk, mar wy lêze it ek tagelyk. Wy analysearje en lêze de records dêryn. Wy begripe hokker blokken binne feroare en sammelje delta triemmen.
In delta triem beskriuwt in bepaald berik fan WAL triemmen, beskriuwt ynformaasje oer hokker blokken waarden feroare yn dit berik fan WAL. En dan wurde dizze delta-bestannen ek argivearre.
Hjir steane wy foar it feit dat wy alles frij fluch parallelisearre hawwe, mar wy kinne in sekwinsjele skiednis net parallel lêze, om't wy yn in bepaald segmint it ein fan 'e foarige WAL-record kinne tsjinkomme, wêrmei't wy noch neat hawwe om te ferbinen, om't parallellêzen late ta dat wy earst de takomst analysearje, dy't noch gjin ferline hat.
As gefolch, wy moasten sette ûnbegryplike stikken yn _delta_partial triemmen. As gefolch, as wy weromkomme nei it ferline, sille wy de stikken fan it WAL-record yn ien plakke, dêrnei sille wy it analysearje en begripe wat der yn feroare is.
As d'r yn 'e skiednis fan ús skachtparsing op syn minst ien punt is wêr't wy net begripe wat der barde, dan sille wy by de folgjende reservekopy twongen wurde om it heule kluster opnij te lêzen, krekt lykas wy diene mei in gewoane LSN -basearre delta.
As resultaat late al ús lijen ta it feit dat wy de WAL-G-parsingbibleteek iepen boarnen. Foar safier't ik wit is der noch gjinien dy't it brûkt, mar as immen it wol, skriuwe en brûke wol, is it yn it publike domein. (Bywurke keppeling )
As resultaat sjogge alle ynformaasjestreamen frij yngewikkeld. Us Master argivearret de skacht en argivearret delta-bestannen. En de replika dy't de reservekopy makket, moat delta-bestannen ûntfange yn 'e tiid dy't tusken de reservekopyen ferrûn is. Yn dit gefal sille dielen fan 'e skiednis moatte wurde tafoege yn bulk en parsed, omdat net de hiele skiednis past yn grutte segminten. En pas nei dit kin de replika in folsleine delta-backup argivearje.
Op de grafiken liket alles folle ienfâldiger. Dit is in download fan ien fan ús echte klusters. Wy hawwe LSN-basearre, makke yn ien dei. En wy sjogge dat de LSN-basearre delta-backup rûn fan trije moarns oant fiif moarns. Dit is de lading yn it oantal prosessor kearnen. WAL-delta naam ús hjir sa'n 20 minuten, dat is, it waard flink flugger, mar tagelyk wie der in mear yntinsive útwikseling oer it netwurk.
Om't wy ynformaasje hawwe oer hokker blokken feroare binne en op hokker tiid yn 'e skiednis fan' e database, gongen wy fierder en besletten om funksjonaliteit te yntegrearjen - in PostgreSQL-útwreiding neamd "pg_prefaulter"
Dit betsjut dat as de stand-by-basis it kommando weromsette útfiert, it WAL-G fertelt om it folgjende WAL-bestân op te heljen. Wy begripe sawat hokker gegevensblokken it WAL-herstelproses tagong sil yn 'e heine takomst en inisjearje in lêsoperaasje op dizze blokken. Dit waard dien om de prestaasjes fan SSD-controllers te ferheegjen. Om't de WAL-rol de side sil berikke dy't feroare wurde moat. Dizze side stiet op skiif en is net yn it sidecache. En hy sil syngroan wachtsje oant dizze side komt. Mar tichtby is WAL-G, dy't wit dat wy yn 'e kommende pear hûndert megabytes fan WAL bepaalde siden nedich binne en tagelyk begjint se op te waarmjen. Inisjearret meardere skiiftagongen sadat se parallel wurde útfierd. Dit wurket goed op SSD-skiven, mar, spitigernôch, is it perfoarst net fan tapassing foar in hurde skiif, om't wy ús allinich bemuoie mei ús prompts.
Dit is wat no yn 'e koade stiet.
D'r binne funksjes dy't wy wolle tafoegje.
Dizze foto lit sjen dat WAL-delta nimt in relatyf koarte tiid. En dit is it lêzen fan de feroarings dy't barde yn 'e databank oerdeis. Wy koenen WAL-delta net allinich nachts dwaan, om't it net langer in wichtige boarne fan lading is. Wy kinne elke minút WAL-delta lêze, om't it goedkeap is. Yn ien minút kinne wy alle wizigingen scannen dy't hawwe bard oan it kluster. En dit soe "instant WAL-delta" wurde kinne.
It punt is dat as wy it kluster weromsette, wy it oantal ferhalen ferminderje dat wy sequentieel moatte oprolje. Dat is, it bedrach fan WAL dat PostgreSQL rôlet moat wurde fermindere, om't it signifikant tiid nimt.
Mar dat is net alles. As wy witte dat guon blok wurdt feroare nei it punt fan reservekopy gearhing, wy kinne net feroarje it yn it ferline. Dat is, no hawwe wy triem-by-bestân optimisaasje fan WAL-delta trochstjoere. Dit betsjut dat as, bygelyks, op tiisdei in tabel folslein wiske is of guon bestannen folslein fan 'e tabel wiske binne, dan as delta op moandei rôlet en de pg_basebackup fan sneon wurdt hersteld, sille wy dizze gegevens net iens oanmeitsje.
Wy wolle dizze technology útwreidzje nei it sidenivo. Dat is, as in diel fan it bestân op moandei feroaret, mar op woansdei oerskreaun wurdt, dan hoege wy by it weromsette nei in punt op tongersdei de earste pear ferzjes fan siden net op skiif te skriuwen.
Mar dit is noch altyd in idee dat wurdt aktyf besprutsen binnen ús, mar it hat noch net berikt de koade.
Wy wolle noch ien funksje meitsje yn WAL-G. Wy wolle it útbreidber meitsje, om't wy ferskate databases stypje moatte en it backupbehear op deselde wize benaderje wolle. Mar it probleem is dat de MySQL API's radikaal oars binne. Yn MySQL is PITR net basearre op it fysike WAL-log, mar op it binlog. En wy hawwe gjin argivearjen systeem yn MySQL dat soe fertelle wat ekstern systeem dat dit binlog is klear en moat wurde argivearre. Wy moatte earne yn cron mei de databank stean en kontrolearje oft der wat klear is?
En op deselde manier is d'r by in MySQL-herstel gjin herstelkommando dat it systeem kin fertelle dat ik sokke en sokke bestannen nedich is. Foardat jo begjinne mei it werbouwen fan jo kluster, moatte jo witte hokker bestannen jo nedich binne. Jo moatte sels riede hokker bestannen jo nedich binne. Mar dizze problemen kinne op ien of oare manier omseame wurde. (Opheldering: MySQL wurdt al stipe)
Yn it rapport woe ik it ek hawwe oer dy gefallen dat WAL-G net geskikt is foar jo.
As jo gjin syngroane replika, garandearret WAL-G net dat de lêste segmint wurdt bewarre bleaun. En as it argivearjen efter de lêste pear segminten fan 'e skiednis bliuwt, is dat in risiko. As d'r gjin syngroane replika is, soe ik net oanrikkemandearje om WAL-G te brûken. Noch altyd is it benammen ûntworpen foar in wolkynstallaasje, wat in oplossing mei hege beskikberens ymplisearret mei in syngroane replika, dy't ferantwurdlik is foar de feiligens fan 'e lêste bytes dy't ynset binne.
Ik sjoch faak minsken besykje te rinnen sawol WAL-G en WAL-E tagelyk. Wy stypje efterútkompatibiliteit yn 't sin dat WAL-G in bestân kin weromsette fan WAL-E en in reservekopy kin weromsette makke yn WAL-E. Mar om't dizze beide systemen parallelle wal-push brûke, begjinne se bestannen fan elkoar te stellen. As wy it reparearje yn WAL-G, bliuwt it noch yn WAL-E. Yn WAL-E sjocht it nei argyfstatus, sjocht de klear bestannen en argivearret se, wylst oare systemen gewoan net witte dat dit WAL-bestân bestie, om't PostgreSQL net besykje it in twadde kear te argivearjen.
Wat sille wy hjir reparearje oan 'e WAL-G-kant? Wy sille PostgreSQL net ynformearje dat dit bestân parallel is oerdroegen, en as PostgreSQL ús freget it te argivearjen, sille wy al witte dat sa'n bestân mei dizze modustiid en mei dizze md5 al argivearre is en wy sille gewoan PostgreSQL sizze - OK, alles is klear sûnder yn wêzen neat te dwaan.
Mar dit probleem is nei alle gedachten net fêst te stellen oan de WAL-E kant, dus it is op it stuit ûnmooglik om te meitsjen in argyf kommando dat sil argivearje de triem yn sawol WAL-G en WAL-E.
Derneist binne d'r gefallen wêr't WAL-G no net geskikt is foar jo, mar wy sille it grif reparearje.
As earste hawwe wy op it stuit gjin ynboude backupferifikaasje. Wy hawwe gjin ferifikaasje ek by reservekopy of herstel. Fansels wurdt dit ymplementearre yn 'e wolk. Mar dit wurdt ymplementearre gewoan troch pre-kontrôle, gewoan troch it werstellen fan it kluster. Ik wol dizze funksjonaliteit oan brûkers jaan. Mar troch ferifikaasje, Ik nim oan dat yn WAL-G sil wêze mooglik om te herstellen it kluster en begjinne it, en rinne reek tests: pg_dumpall to /dev/null en amcheck index ferifikaasje.
Op it stuit yn WAL-G is d'r gjin manier om ien reservekopy fan WAL út te stellen. Dat is, wy stypje wat finster. Bygelyks, de lêste sân dagen opslaan, de lêste tsien backups opslaan, de lêste trije folsleine backups opslaan. Hiel faak komme minsken en sizze: "Wy hawwe in reservekopy nedich fan wat der op nijjier barde en wy wolle it foar altyd hâlde." WAL-G kin dit noch net dwaan. (Opmerking - Dit is al reparearre. Lês mear - Reservekopy-mark opsje yn )
En wy hawwe gjin sidekontrôlesummen en yntegriteitskontrôles foar alle skachtegminten by it falidearjen fan PITR.
Fan dit alles haw ik in projekt gearstald foar Google Summer of Code. As jo tûke studinten kenne dy't wat wolle skriuwe yn Go en ferskate tûzenen dollars krije fan ien bedriuw mei de letter "G", advisearje har dan ús projekt. Ik sil fungearje as mentor foar dit projekt, se kinne it dwaan. As der gjin learlingen binne, dan nim ik it en doch it sels yn de simmer.
En wy hawwe in protte oare lytse problemen dêr't wy stadichoan wurkje oan. En der barre nochal wat nuvere dingen.
Bygelyks, as jo WAL-G in lege reservekopy jouwe, sil it gewoan falle. Bygelyks, as jo him fertelle dat hy in lege map reservekopy moat. It pg_control-bestân sil der net wêze. En hy sil tinke dat er wat net begrypt. Yn teory, yn dit gefal moatte jo in normaal berjocht oan 'e brûker skriuwe om him út te lizzen hoe't jo it ark brûke. Mar dit is net iens in skaaimerk fan programmearring, mar in eigenskip fan in goede, fersteane taal.
Wy witte net hoe't jo offline backup kinne dwaan. As de databank leit, kinne wy it net reservekopy. Mar alles is hjir hiel ienfâldich. Wy neame backups troch LSN doe't it begûn. De LSN fan 'e ûnderlizzende basis moat lêzen wurde út it kontrôletriem. En dit is sa'n unrealisearre funksje. In protte reservekopysystemen kinne in ûnderlizzende databank meitsje. En it is handich.
Wy kinne it gebrek oan reservekopyromte op it stuit net goed omgean. Want wy wurkje meastentiids mei grutte backups thús. En se kamen der net by. Mar as immen no direkt yn Go programmearje wol, foegje dan ôfhanneling ta foar flaters bûten de romte oan de bak. Ik sil perfoarst it pull-fersyk besjen.
En it wichtichste ding dat ús soargen is dat wy safolle mooglik docker-yntegraasjetests wolle dy't ferskate senario's kontrolearje. Op it stuit testen wy allinich basissenario's. Op elke commit, mar wy wolle commit-by-commit kontrolearje alle funksjonaliteit dy't wy stypje. Yn it bysûnder sille wy bygelyks genôch stipe hawwe foar PostgreSQL 9.4-9.5. Wy stypje se om't de mienskip PostgreSQL stipet, mar wy kontrolearje commit-by-commit net om te soargjen dat alles net brutsen is. En it liket my ta dat dit in nochal serieus risiko is.
Wy hawwe WAL-G op mear as tûzen klusters yn Yandex-databasebehear. En it makket elke dei in reservekopy fan ferskate hûnderten terabytes oan gegevens.
Wy hawwe in protte TODO yn ús koade. As jo wolle programmearje, kom, wy wachtsje op pull-oanfragen, wy wachtsje op fragen.
Jo fragen
Goejûn! Dankewol! Myn miening is dat as jo WAL-delta brûke, jo wierskynlik sterk fertrouwe op skriuwt op folsleine side. En as dat sa is, hawwe jo tests útfierd? Jo lieten in prachtige grafyk sjen. Hoefolle moaier wurdt it as FPW útskeakele wurdt?
Skriuw op folsleine side is foar ús ynskeakele, wy hawwe net besocht it út te skeakeljen. Dat is, ik, as ûntwikkelder, haw net besocht it út te skeakeljen. Systeembehearders dy't ûndersocht hawwe, hawwe dit probleem wierskynlik ûndersocht. Mar wy hawwe FPW nedich. Hast gjinien skeakelt it út, want oars is it ûnmooglik om in reservekopy fan in replika te nimmen.
Tank foar it ferslach! Ik haw twa fragen. De earste fraach is wat sil barre mei tablespaces?
Wy wachtsje op in pull fersyk. Us databases libje op SSD- en NMVE-skiven en wy hawwe dizze funksje net echt nedich. Ik bin net ree om no serieuze tiid te besteegjen oan it goed te dwaan. Ik pleite der fan herte foar dat wy dit stypje. D'r binne minsken dy't it stipe hawwe, mar it stipe hawwe op in manier dy't by harren past. Se makken in foarke, mar se dogge gjin pull-oanfragen. (Tafoege yn ferzje 0.2.13)
En de twadde fraach. Jo seine oan it begjin dat WAL-G derfan útgiet dat it allinich wurket en gjin wrappers binne nedich. Ik brûk sels wrappers. Wêrom soene se net brûkt wurde?
Wy wolle dat it sa ienfâldich is as in balalaika. Dit betsjut dat jo hielendal neat nedich hawwe, útsein in balalaika. Wy wolle dat it systeem ienfâldich is. As jo funksjonaliteit hawwe dy't jo moatte dwaan yn in skript, kom dan en fertel ús - wy sille it dwaan yn Go.
Goejûn! Tank foar it ferslach! Wy koenen WAL-G net krije om te wurkjen mei GPG-ûntsifering. It fersiferet normaal, mar wol net ûntsiferje. Is it wat dat ús net slagge? De situaasje is deprimearjend.
Meitsje in probleem op GitHub en litte wy it útfine.
Dat is, jo hawwe dit net tsjinkaam?
D'r is in eigenskip fan it flaterrapport dat as WAL-G net begrypt hokker soarte bestân it is, freget it: "Miskien is it fersifere?" Miskien is it probleem hielendal gjin fersifering. Ik wol it oanmelden oer dit ûnderwerp ferbetterje. Hy moat it ûntsiferje. Wy wurkje op it stuit oan dit ûnderwerp yn 'e sin dat wy net echt leuk fine hoe't it systeem foar it krijen fan iepenbiere en partikuliere kaaien is organisearre. Om't wy eksterne GPG neame sadat it ús syn kaaien jout. En dan nimme wy dizze kaaien en ferpleatse se nei de ynterne GPG, dy't iepen PGP is, dy't foar ús yn WAL-G kompilearre is, en dêr neame wy fersifering. Yn dit ferbân wolle wy it systeem ferbetterje en wolle Libsodium-fersifering stypje (tafoege yn ferzje 0.2.15). Fansels moat dekodearring wurkje, litte wy it útfine - jo hawwe mear in symptoom nedich as in pear wurden. Jo kinne soms sammelje yn 'e keamer fan' e sprekker en sjogge nei it systeem. (PGP-fersifering sûnder eksterne GPG - v0.2.9)
Hallo! Tank foar it ferslach! Ik haw twa fragen. Ik haw in nuvere winsk om te dwaan pg_basebackup en WAL log yn twa providers, i.e. Ik wol dwaan ien wolk en in oar. Is der in manier om dit te dwaan?
Dit bestiet no net, mar it is in nijsgjirrich idee.
Ik fertrou gewoan net ien provider, ik wol itselde hawwe yn in oare, foar it gefal.
It idee is nijsgjirrich. Technysk is dit hielendal net dreech om te realisearjen. Om foar te kommen dat it idee ferlern giet, kin ik jo freegje om in probleem te meitsjen op GitHub?
Ja fansels.
En dan, as studinten nei Google Summer of Code komme, sille wy se tafoegje oan it projekt, sadat der mear wurk is om mear út har te heljen.
En de twadde fraach. D'r is in probleem op GitHub. Ik tink dat it al ticht is. Der is panyk by restauraasje. En om it te ferslaan, hawwe jo in aparte gearkomste makke. It is rjocht yn saken. En d'r is in opsje om in fariabele omjouwing te dwaan yn ien tried. En dêrom wurket it hiel stadich. En wy tsjinkaam dit probleem, en it is noch net fêst.
It probleem is dat om ien of oare reden de opslach (CEPH) de ferbining weromsette as wy der mei in hege concurrency komme. Wat kin der oan dien wurde? De logika foar opnij besykjen sjocht der sa út. Wy besykje it bestân opnij te downloaden. Yn ien pas hienen wy in oantal bestannen net ynladen, wy sille in twadde meitsje foar al dyjingen dy't net oanmelde. En sa lang as op syn minst ien triem wurdt laden per iteraasje, wy werhelje en werhelje en werhelje. Wy hawwe de logika fan opnij besykjen ferbettere - eksponinsjele backoff. Mar it is net hielendal dúdlik wat te dwaan mei it feit dat de ferbining gewoan brekt oan 'e kant fan it opslachsysteem. Dat is, as wy uploade nei ien stream, brekt it dizze ferbiningen net. Wat kinne wy hjir ferbetterje? Wy hawwe netwurk throttling, wy kinne elke ferbining beheine troch it oantal bytes dat it ferstjoert. Oars, ik wit net hoe't ik moat omgean mei it feit dat opslach fan objekten ús net tagelyk kinne downloade of downloade.
Gjin SLA? Is it net foar har skreaun hoe't se har martelje litte?
It punt is dat minsken dy't mei dizze fraach komme meastentiids har eigen ferwulft. Dat is, gjinien komt fan Amazon of Google Cloud of Yandex Object Storage.
Miskien is de fraach net mear foar jo?
De fraach hjir yn dit gefal makket net út foar wa. As d'r ideeën binne oer hoe't jo mei dit moatte omgean, litte wy it dwaan yn WAL-G. Mar oant no ta haw ik gjin goede ideeën oer hoe't ik hjirmei omgean moat. D'r binne wat Object Storage dy't backups op ferskillende wizen stypje. Jo freegje se in list objekten, en se tafoegje map dêr. WAL-G wurdt hjir bang foar - d'r is hjir wat soarte ding dat gjin bestân is, ik kin it net weromsette, wat betsjut dat de reservekopy net wersteld is. Dat is, yn feite, jo hawwe in folslein restaurearre kluster, mar it jout jo in ferkearde status omdat Object Storage werom wat nuvere ynformaasje dat it net folslein begripe.
Dit is in ding dat bart yn 'e Mail-wolk.
As jo in reprodusearje kinne bouwe ...
It wurdt konsekwint reprodusearre ...
As d'r in reprodusearje is, dan tink ik dat wy sille eksperimintearje mei opnij probearje strategyen en útfine hoe't jo opnij besykje en begripe wat de wolk fan ús fereasket. Miskien sil it foar ús stabyl wêze op trije ferbiningen en sil de ferbining net ferbrekke, dan sille wy foarsichtich trije berikke. Om't wy no de ferbining heul fluch falle, d.w.s. as wy in herstel hawwe lansearre mei 16 threads, dan sille nei de earste opnij besykjen 8 threads, 4 threads, 2 threads en ien wêze. En dan sil it de triem yn ien stream lûke. As d'r wat magyske wearden binne, lykas 7,5-threads binne it bêste om te pompen, dan sille wy der by stilstean en besykje noch 7,5-threads te meitsjen. Hjir is in idee.
Tank foar it ferslach! Hoe sjocht in folsleine workflow foar wurkjen mei WAL-G der út? Bygelyks, yn it domme gefal as der gjin delta oer siden is. En wy nimme en fuortsmite de earste reservekopy, dan argyf de skacht oant wy binne blau yn it gesicht. Hjir, sa't ik it begryp, is der in ôfbraak. Op in stuit moatte jo in delta-backup fan siden meitsje, d.w.s. in eksterne proses driuwt dit of hoe bart dit?
De delta backup API is frij simpel. Der is in oantal dêr - max delta stappen, dat is wat it hjit. It is standert op nul. Dit betsjut dat elke kear as jo in backup-push dogge, it in folsleine backup downloade. As jo it feroarje nei in posityf nûmer, bygelyks 3, dan sjocht it de folgjende kear as jo in backup-push dogge, nei de skiednis fan eardere backups. Hy sjocht dat jo net boppe de keatling fan 3 deltas en makket in delta.
Dat is, elke kear as wy WAL-G starte, besiket it in folsleine reservekopy te meitsjen?
Nee, wy rinne WAL-G, en it besiket in delta te meitsjen as jo belied it tastean.
Rûchwei, as jo it elke kear mei nul útfiere, sil it dan gedrage as pg_basebackup?
Nee, it sil noch hurder rinne, om't it kompresje en parallelisme brûkt. Pg_basebackup sil sette de skacht neist dy. WAL-G giet derfan út dat jo argivearring ynsteld hawwe. En it sil in warskôging útjaan as it net is ynsteld.
Pg_basebackup kin wurde útfierd sûnder shafts.
Ja, dan gedrage se har hast gelyk. Pg_basebackup kopiearret nei it bestânsysteem. Trouwens, wy hawwe in nije funksje dy't ik fergeat te neamen. Wy kinne no reservekopy nei it bestânsysteem fan pg_basebackup. Ik wit net wêrom dit nedich is, mar it is der.
Bygelyks op CephFS. Net elkenien wol Object Storage konfigurearje.
Ja, dat is wierskynlik wêrom't se in fraach stelden oer dizze funksje, sadat wy it koene dwaan. En wy diene it.
Tank foar it ferslach! D'r is gewoan in fraach oer kopiearjen nei it bestânsysteem. Stypje jo no út 'e doaze kopiearje nei opslach op ôfstân, bygelyks as d'r wat planke yn it datasintrum is of wat oars?
Yn dizze formulearring is dit in drege fraach. Ja, wy stypje, mar dizze funksjonaliteit is noch net opnommen yn in release. Dat is, alle pre-releases stypje dit, mar de release ferzjes net. Dizze funksjonaliteit waard tafoege yn ferzje 0.2. It sil grif gau frijlitten wurde, sa gau as wy alle bekende bugs reparearje. Mar op dit stuit kin dit allinnich dien wurde yn pre-release. D'r binne twa bugs yn 'e pre-release. Probleem mei WAL-E-herstel, wy hawwe it net reparearre. En yn 'e lêste pre-release waard in brek oer delta-backup tafoege. Dêrom riede wy elkenien oan om de releaseferzjes te brûken. Sadree't d'r gjin bugs mear binne yn 'e pre-release, kinne wy sizze dat wy Google Cloud, S3-kompatible dingen en triem opslach stypje.
Hallo, tank foar it rapport. As ik it begryp, is WAL-G net in soarte fan sintralisearre systeem lykas barmen? Binne jo fan plan om yn dizze rjochting te bewegen?
It probleem is dat wy fan dizze rjochting fuort binne. WAL-G libbet op 'e basishost, op' e klusterhost, en op alle hosts yn it kluster. Doe't wy ferhuze nei ferskate tûzen klusters, wy hiene in protte bartender ynstallaasjes. En elke kear as der wat yn har falt, is it in grut probleem. Om't se reparearre wurde moatte, moatte jo begripe hokker klusters no gjin backups hawwe. Ik bin net fan plan om WAL-G te ûntwikkeljen yn 'e rjochting fan fysike hardware foar backupsystemen. As de mienskip hjir wat funksjonaliteit wol, dan kin ik der hielendal gjin sin oan ha.
Wy hawwe teams dy't ferantwurdlik binne foar opslach. En wy fiele ús sa goed dat it ús net binne, dat d'r spesjale minsken binne dy't ús bestannen pleatse wêr't de bestannen feilich binne. Se dogge dêr allerhanne tûke kodearring om it ferlies fan in bepaald oantal bestannen tsjin te hâlden. Se binne ferantwurdlik foar netwurk bânbreedte. As jo in bartender hawwe, kinne jo ynienen útfine dat lytse databases mei in protte ferkear op deselde server sammele binne. Jo lykje te hawwen in soad romte op it, mar foar guon reden alles past net troch it netwurk. It kin oarsom útpakke. Der binne in protte netwurken dêr, der binne prosessor kearnen, mar der binne gjin skiven hjir. En wy waarden wurch fan dizze needsaak om wat te jongleren, en wy ferhuze nei it feit dat gegevensopslach in aparte tsjinst is, wêrfoar aparte spesjale minsken ferantwurdlik binne.
P.S In nije ferzje is útbrocht , wêryn jo it .walg.json-konfiguraasjetriem brûke kinne, dat standert yn 'e postgres thúsmap stiet. Jo kinne bash-skripts ferlitte. Foarbyld .walg.json is yn dizze útjefte
Video:
Boarne: www.habr.com