Ik stel foar dat jo it transkripsje lêze fan it iere 2020-rapport fan Georgy Rylov "WAL-G: nije kânsen en útwreiding fan 'e mienskip"
Underhâlders fan iepen boarne stean foar in protte útdagings as se groeie. Hoe mear en mear fereaske funksjes skriuwe, mear en mear problemen reparearje en beheare om mear en mear pull-oanfragen te besjen? Mei help fan WAL-G (reservekopy-ark foar PostgreSQL) as foarbyld, sil ik jo fertelle hoe't wy dizze problemen hawwe oplost troch in kursus te lansearjen oer Open-source-ûntwikkeling oan 'e universiteit, wat wy hawwe berikt en wêr't wy neist sille ferhúzje.
Hallo wer allegear! Ik bin in Yandex-ûntwikkelder út Jekaterinburg. En hjoed sil ik prate oer WAL-G.
De titel fan it rapport sei net dat it wat oer backups gie. Wit immen wat WAL-G is? Of wit elkenien it? Stek dyn hân op as jo it net witte. Holy shit, jo kamen by it rapport en witte net wêr't it oer giet.
Lit my jo fertelle wat der hjoed barre sil. It bart sa dat ús team al in skoft backups dien hat. En dit is in oar rapport yn in searje wêr't wy prate oer hoe't wy gegevens feilich, feilich, handich en effisjint opslaan.
Yn foarige searjes wiene der in protte rapporten fan Andrei Borodin en Vladimir Leskov. D'r wiene in protte fan ús. En wy hawwe it in protte jierren oer WAL-G.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Dit rapport sil in bytsje oars wêze as de oaren yn dat it mear oer it technyske diel gie, mar hjir sil ik prate oer hoe't wy problemen tsjinkamen yn ferbân mei de groei fan 'e mienskip. En hoe't wy op in lyts idee kamen dat ús helpt om hjirmei om te gaan.
In pear jier lyn wie WAL-G in frij lyts projekt dat wy krigen fan Citus Data. En wy namen it gewoan. En it waard ûntwikkele troch ien persoan.
En allinnich WAL-G hie net:
- Reservekopy fan in replika.
- D'r wiene gjin ynkrementele backups.
- D'r wiene gjin WAL-Delta-backups.
- En der mist noch in hiel soad.
Yn dizze pear jier is WAL-G in protte groeid.
En yn 2020 is al it boppesteande al ferskynd. En dêrby waard tafoege wat wy no hawwe:
- Mear dan 1 stjerren op GitHub.
- 150 foarke.
- Sawat 15 iepen PR's.
- En noch folle mear meiwurkers.
- En iepen saken hieltyd. En dit nettsjinsteande it feit dat wy der letterlik alle dagen hinne geane en der wat oan dogge.
En wy kamen ta de konklúzje dat dit projekt mear fan ús oandacht fereasket, sels as wy sels neat hoege te ymplementearjen foar ús tsjinst Managed Databases yn Yandex.
En earne yn de hjerst fan 2018 kaam in idee yn ús holle. Normaal hat it team ferskate manieren om guon funksjes te ûntwikkeljen of bugs te reparearjen as jo net genôch hannen hawwe. Jo kinne bygelyks in oare ûntwikkelder hiere en him jild betelje. Of jo kinne efkes in stazjêre oannimme en him ek wat salaris betelje. Mar der is noch wol in grutte groep minsken, wêrfan guon al echt koade skriuwe kinne. Jo witte gewoan net altyd hokker kwaliteit de koade is.
Wy hawwe der oer neitocht en besletten om te besykjen studinten oan te lûken. Mar studinten sille by ús net oan alles meidwaan. Se sille mar in part fan it wurk dwaan. En se sille bygelyks tests skriuwe, bugs reparearje, funksjes ymplementearje dy't de haadfunksjonaliteit net beynfloedzje. De wichtichste funksjonaliteit is it meitsjen fan backups en it herstellen fan backups. As wy in flater meitsje by it meitsjen fan in reservekopy, sille wy gegevensferlies ûnderfine. En gjinien wol dit, fansels. Elkenien wol dat alles tige feilich is. Dêrom wolle wy fansels gjin koade litte litte dy't wy minder fertrouwe as ús eigen. Dat is, elke net-krityske koade is wat wy wolle ûntfange fan ús ekstra arbeiders.
Under hokker betingsten wurdt studint PR akseptearre?
- Se binne ferplichte om har koade te dekken mei tests. Alles moat plakfine yn CI.
- En wy geane ek troch 2 resinsjes. Ien fan Andrey Borodin en ien fan my.
- En boppedat, om te kontrolearjen dat dit neat sil brekke yn ús tsjinst, upload ik de gearkomste apart mei dizze commit. En wy kontrolearje yn end-to-end tests dat neat mislearret.
Spesjale kursus oer Open Source
In bytsje oer wêrom't dit nedich is en wêrom dit, liket my, in cool idee is.
Foar ús is de winst fanselssprekkend:
- Wy krije ekstra hannen.
- En wy sykje kandidaten foar it team ûnder tûke studinten dy't tûke koade skriuwe.
Wat is it foardiel foar studinten?
Se kinne minder fanselssprekkend wêze, om't studinten op syn minst gjin jild krije foar de koade dy't se skriuwe, mar allinich sifers krije foar har studintrekords.
Ik frege harren oer dit. En yn har wurden:
- Meiwurker ûnderfining yn Open Source.
- Krij in rigel yn jo CV.
- Bewize dysels en trochjaan in ynterview yn Yandex.
- Wês lid fan GSoC.
- +1 spesjale kursus foar dyjingen dy't koade wolle skriuwe.
Ik sil net prate oer hoe't de kursus strukturearre wie. Ik sil gewoan sizze dat WAL-G it haadprojekt wie. Wy hawwe ek projekten lykas Odyssey, PostgreSQL en ClickHouse yn dizze kursus opnommen.
En se joegen problemen net allinich yn dizze kursus, mar joegen ek diploma's en kursussen út.
Wat oer it foardiel foar brûkers?
Litte wy no trochgean nei it diel dat jo it meast ynteresseart. Wat docht dit jo goed? It punt is dat de studinten in protte bugs reparearren. En wy makken de fersykfunksjes dy't jo ús fregen te dwaan.
En lit my jo fertelle oer de dingen dy't jo lang woenen hawwe en dy't realisearre binne.
Tablespaces stipe. Tabelromten yn WAL-G binne wierskynlik ferwachte sûnt de frijlitting fan WAL-G, om't WAL-G de opfolger is fan in oar reservekopy-ark WAL-E, wêr't database-backups mei tabelromten stipe waarden.
Lit my jo koart herinnerje wat it is en wêrom it allegear nedich is. Typysk besette al jo Postgres-gegevens ien map op it bestânsysteem, de basis neamd. En dizze map befettet al alle bestannen en submappen dy't nedich binne troch Postgres.
Tabelromten binne mappen dy't Postgres-gegevens befetsje, mar se lizze net bûten de basismap. De slide lit sjen dat de tablespaces bûten de basismap lizze.
Hoe sjocht dit der út foar Postgres sels? D'r is in aparte submap pg_tblspc yn 'e basismap. En it befettet symlinks nei mappen dy't eins Postgres-gegevens befetsje bûten de basismap.
As jo dit alles brûke, dan kinne dizze kommando's foar jo der sa útsjen. Dat is, jo meitsje in tabel yn in bepaalde tabelromte en sjoch wêr't it no is. Dit binne de lêste twa rigels, de lêste twa kommando's neamd. En dêr is it dúdlik dat der in manier is. Mar yn werklikheid is dit net de echte manier. Dit is it foarôfgeande paad fan 'e basismap nei tabelromte. En dêrwei wurdt it matched mei in symlink dy't liedt nei jo echte gegevens.
Wy brûke dit alles net yn ús team, mar it waard brûkt troch in protte oare WAL-E-brûkers dy't ús skreaunen dat se nei WAL-G woene, mar dit stoppe har. Dit wurdt no stipe.
In oare eigenskip dy't ús spesjale kursus brocht ús is catchup. Minsken dy't wierskynlik mear mei Oracle hawwe wurke as mei Postgres witte oer catchup.
Koart oer wat it is. De klustertopology yn ús tsjinst kin gewoanlik sa útsjen. Wy hawwe in master. D'r is in replika dy't it skriuw-foarút-logboek streamt. En de replika fertelt de master op hokker LSN it op it stuit is. En earne parallel mei dit kin it log wurde argivearre. En neist it argivearjen fan it log, wurde backups ek nei de wolk stjoerd. En delta backups wurde ferstjoerd.
Wat kin it probleem wêze? As jo in frij grutte databank hawwe, kin it blike dat jo replika fier efter de master begjint te lizzen. En se leit sa fier efter dat se him noait ynhelje kin. Dit probleem moat normaal op ien of oare manier oplost wurde.
En de maklikste manier is om de replika te ferwiderjen en it opnij te uploaden, om't it noait sil ynhelje, en it probleem moat wurde behannele. Mar dit is nochal in lange tiid, om't it werstellen fan in folsleine 10 TB-database-backup in heul, heul lange tiid is. En dit alles wolle wy sa gau mooglik dwaan as sokke problemen ûntsteane. En dat is krekt wêr't catchup foar is.
Catchup lit jo delta-backups brûke, dy't op dizze manier yn 'e wolk wurde opslein. Jo sizze hokker LSN de efterlizzende replika op it stuit is en spesifisearje it yn it catchup-kommando om in delta-backup te meitsjen tusken dat LSN en de LSN wêrop jo kluster op it stuit leit. En dêrnei weromsette jo dizze reservekopy nei de replika dy't efter bleau.
Oare bases
De learlingen brochten ús ek in protte funksjes tagelyk. Sûnt by Yandex kokje wy net allinich Postgres, wy hawwe ek MySQL, MongoDB, Redis, ClickHouse, op in stuit moasten wy backups meitsje kinne mei punt-yn-tiid herstel foar MySQL, en sadat d'r in kâns wie om te uploaden se nei de wolk.
En wy woenen it dwaan op ien of oare ferlykbere manier as wat WAL-G docht. En wy besletten om te eksperimintearjen en te sjen hoe't it der allegear útsjen soe.
En earst, sûnder dizze logika op ien of oare manier te dielen, skreaunen se de koade yn 'e gabel. Se seagen dat wy in soarte fan wurkjend model hawwe en it kin fleane. Doe tochten wy dat ús haadmienskip postgresisten is, se brûke WAL-G. En dêrom moatte wy dizze dielen op ien of oare manier skiede. Dat is, as wy koade foar Postgres bewurkje, brekke wy MySQL net; as wy MySQL bewurkje, brekke wy Postgres net.
It earste idee oer hoe dit te skieden wie it idee om deselde oanpak te brûken dy't wurdt brûkt yn PostgreSQL-útwreidingen. En, yn feite, om in MySQL-backup te meitsjen, moasten jo in soarte fan dynamyske bibleteek ynstallearje.
Mar hjir is de asymmetry fan dizze oanpak fuortendaliks sichtber. As jo Postgres reservekopy meitsje, sette jo in normale reservekopy foar Postgres derop en alles is goed. En foar MySQL docht bliken dat jo in reservekopy foar Postgres ynstallearje en ek in dynamyske bibleteek foar MySQL foar ynstallearje. It klinkt wat frjemd. Dat tochten wy ek en besletten dat dit net de oplossing wie dy't wy nedich wiene.
Ferskate builds foar Postgres, MySQL, MongoDB, Redis
Mar dit liet ús, liket it ús, ta it juste beslút komme - ferskate gearkomsten foar ferskate basisen tawize. Dit makke it mooglik om de logika te isolearjen ferbûn oan backups fan ferskate databases dy't tagong krije ta de mienskiplike API dy't WAL-G ymplementearret.
Dit is it diel dat wy sels skreaun hawwe - foardat jo de studinten de problemen jouwe. Dat is, dit is krekt it diel wêr't se wat ferkeard kinne dwaan, dus wy besletten dat wy better soks dwaan kinne en alles sil goed komme.
Dêrnei joegen wy problemen út. Se waarden fuortendaliks ôfbrutsen. Studinten waarden ferplichte om trije bases te stypjen.
Dit is MySQL, dy't wy al mear dan in jier op dizze manier hawwe reservekopy makke mei WAL-G.
En no komt MongoDB produksje oan, wêr't se it ôfmeitsje mei in bestân. Yn feite hawwe wy it ramt foar dit alles skreaun. Doe skreaunen de learlingen wat wurkbere dingen. En dan bringe wy se yn in steat dy't wy yn produksje akseptearje kinne.
Dizze problemen liken net as studinten nedich wiene om folsleine reservekopy-ark te skriuwen foar elk fan dizze databases. Wy hiene net sa'n probleem. Us probleem wie dat wy punt-yn-tiid herstel woene en wy woene reservekopy meitsje nei de wolk. En se fregen de learlingen om wat koade te skriuwen dy't dit soe oplosse. De studinten brûkten al besteande reservekopy-ark, dy't op ien of oare manier backups nimme, en dan alles oaninoar lijm mei WAL-G, dy't it allegear trochstjoerde nei de wolk. En se tafoege ek punt-yn-tiid herstel oan dit.
Wat hawwe de learlingen noch meibrocht? Se brochten Libsodium-fersiferingsstipe nei WAL-G.
Wy hawwe ek backup opslach belied. No kinne backups wurde markearre as permanint. En op ien of oare manier is it handiger foar jo tsjinst om it proses fan it opslaan fan se te automatisearjen.
Wat wie it resultaat fan dit eksperimint?
Mear as 100 minsken hawwe har yn earste ynstânsje registrearre foar de kursus. Earst haw ik net sein dat de universiteit yn Jekaterinburg de Ural Federal University is. Wy hawwe dêr alles bekend makke. 100 minsken registrearre. Yn werklikheid begûnen folle minder minsken wat te dwaan, sa'n 30 minsken.
Noch minder minsken foltôgen de kursus, om't it nedich wie om toetsen te skriuwen foar de koades dy't der al binne. En reparearje ek wat bug of meitsje wat funksje. En guon studinten sluten de kursus noch.
Op it stuit hawwe studinten tidens dizze kursus sawat 14 problemen repareare en 10 funksjes makke fan ferskate grutte. En, it liket my, dit is in folweardige ferfanging fan ien of twa ûntwikkelders.
Wy hawwe ûnder oare diploma's en kursuswurk útjûn. En 12 krigen diploma's. 6 fan harren hawwe har al ferdigenje op "5". Dejingen dy't oerbleaune hiene noch gjin beskerming, mar ik tink dat alles foar harren ek goed komt.
Plannen foar de takomst
Hokker plannen hawwe wy foar de takomst?
Teminsten dy funksje-oanfragen dy't wy al fan brûkers hawwe heard en wolle dwaan. Dit:
- Tafersjoch op de krektens fan it folgjen fan tiidline yn it HA-kluster-backup-argyf. Jo kinne dit dwaan mei WAL-G. En ik tink dat wy studinten sille hawwe dy't dizze saak opnimme.
- Wy hawwe al in persoan ferantwurdlik foar it oerdragen fan backups en WAL tusken wolken.
- En wy hawwe koartlyn in idee publisearre dat wy WAL-G noch mear kinne fersnelle troch inkrementele backups út te pakken sûnder siden te herskriuwen en de argiven dy't wy dêr stjoere te optimalisearjen.
Jo kinne se hjir diele
Wêr wie dit rapport foar? Boppedat hawwe wy no, neist de 4 minsken dy't dit projekt stypje, ekstra hannen, dêr't der nochal in soad fan binne. Benammen as jo se skriuwe yn in persoanlik berjocht. En as jo in reservekopy meitsje fan jo gegevens en dogge it mei WAL-G of wolle jo ferhúzje nei WAL-G, dan kinne wy jo winsken frij maklik foldwaan.
Dit is in QR-koade en in keppeling. Jo kinne troch har gean en al jo winsken skriuwe. Wy reparearje bygelyks gjin bug. Of jo wolle echt wat funksje, mar om ien of oare reden is it noch net yn in reservekopy, ynklusyf ús. Wês wis te skriuwen oer dit.
Jo fragen
Hallo! Tank foar it ferslach! Fraach oer WAL-G, mar net oer Postgres. WAL-G makket in reservekopy fan MySQL en ropt in ekstra reservekopy. As wy moderne ynstallaasjes nimme op CentOS en as jo MySQL ynstallearje, sil MariDB ynstalleare wurde. Fan ferzje 10.3 wurdt ekstra backup net stipe, MariDB backup wurdt stipe. Hoe giet it mei dizze?
Op it stuit hawwe wy net besocht om MariDB te backupjen. Wy hawwe oanfragen hân foar FoundationDB-stipe, mar oer it algemien, as der sa'n fersyk is, dan kinne wy minsken fine dy't it dwaan sille. It is net sa lang of sa dreech as ik tink.
Goeiemiddei Tank foar it ferslach! Fraach oer mooglike nije funksjes. Binne jo ree om WAL-G te meitsjen mei tapes, sadat jo backup kinne op tapes?
Reservekopy op tape opslach blykber betsjut?
Ja.
D'r is Andrei Borodin, dy't dizze fraach better beäntwurdzje kin as ik.
(Andrey) Ja, tank foar de fraach! Wy hiene in fersyk om in reservekopy oer te bringen nei tape fan wolk opslach. En foar dit oerdracht tusken wolken. Omdat wolk-to-wolk oerdracht is in generalisearre ferzje fan tape oerdracht. Dêrneist hawwe wy in útbreidbere arsjitektuer yn termen fan Storages. Trouwens, in protte Storoges waarden skreaun troch studinten. En as jo Storage foar tape skriuwe, dan sil it fansels wurde stipe. Wy binne ree om pull-oanfragen te beskôgjen. Dêr moatte jo in bestân skriuwe, in bestân lêze. As jo dizze dingen dogge yn Go, einigje jo meastentiids mei 50 rigels koade. En dan sil tape wurde stipe yn WAL-G.
Tank foar it ferslach! Ynteressant ûntwikkelingsproses. Reservekopy is in serieus stik funksjonaliteit dat goed moat wurde dekt troch tests. Doe't jo funksjonaliteit ymplementearre foar nije databases, hawwe de studinten dan ek de toetsen skreaun, of hawwe jo de toetsen sels skreaun en dan de ymplemintaasje oan 'e studinten jûn?
Studinten skreau ek tests. Mar studinten skreaunen mear foar funksjes lykas nije databases. Se hawwe yntegraasjetests skreaun. En se skreau ienheidstests. As de yntegraasje trochgiet, dat is op it stuit, dit is in skript dat jo manuell útfiere of jo hawwe bygelyks cron dwaande. Dat is, it skript dêr is hiel dúdlik.
De learlingen hawwe net folle ûnderfining. Kin beoardieling in protte tiid nimme?
Ja, resinsjes nimme in soad tiid. Dat is, meastentiids, as der ferskate kommissarissen tagelyk komme en sizze dat ik dit dien haw, dan ha ik dat dien, dan moatte jo tinke en sa'n heale dei ôfsette om út te finen wat se dêr skreaun hawwe. Omdat de koade moat wurde lêzen soarchfâldich. Se hiene gjin ynterview. Wy kenne se net sa goed, dus it nimt in soad tiid.
Tank foar it ferslach! Earder stelde Andrey Borodin dat archive_command yn WAL-G direkt moat wurde neamd. Mar yn it gefal fan in soarte fan cluster cartridge, wy moatte ekstra logika te bepalen it knooppunt út dêr't te stjoeren de shafts. Hoe kinne jo dit probleem sels oplosse?
Wat is dyn probleem hjir? Litte wy sizze dat jo in syngroane replika hawwe wêrmei jo in reservekopy meitsje? Of wat?
(Andrey) It feit is dat WAL-G yndie bedoeld is om te brûken sûnder shell-skripts. As der wat mist, litte wy de logika tafoegje dy't yn WAL-G moat wêze. Oangeande wêr't argivearring wei komme moat, tinke wy dat argivearjen fan de hjoeddeiske master yn it kluster komme moat. Argivearjen fan in replika is in min idee. D'r binne ferskate mooglike senario's mei problemen. Benammen problemen mei it argivearjen fan tiidlinen en alle ekstra ynformaasje. Tank foar de fraach!
(Dúdlikaasje: Wy hawwe shell-skripts kwyt rekke )
Goejûn! Tank foar it ferslach! Ik bin ynteressearre yn 'e catchup-funksje wêr't jo it oer hawwe. Wy waarden konfrontearre mei in situaasje dêr't in replika wie efter en koe net fange. En ik fûn gjin beskriuwing fan dizze funksje yn WAL-G-dokuminten.
Catchup ferskynde letterlik op 20 jannewaris 2020. De dokumintaasje kin wat mear wurk nedich wêze. Wy skriuwe it sels en wy skriuwe it net super goed. En miskien moatte wy begjinne te freegjen fan studinten om it te skriuwen.
Is it al útbrocht?
It pull-fersyk is al dea, dus ik haw it kontrolearre. Ik besocht dit op in test kluster. Oant no hawwe wy noch gjin situaasje hân wêr't wy dit yn in gefjochtsfoarbyld kinne testen.
Wannear te ferwachtsjen?
Ik wit it net. Wachtsje in moanne, wy sille it wis kontrolearje.
Boarne: www.habr.com