Vă sugerez să citiți transcrierea raportului de la începutul anului 2020 de Georgy Rylov „WAL-G: noi oportunități și extinderea comunității”
Întreținerii open-source se confruntă cu multe provocări pe măsură ce cresc. Cum să scrieți din ce în ce mai multe funcții necesare, să remediați din ce în ce mai multe probleme și să reușiți să vedeți din ce în ce mai multe solicitări de extragere? Folosind WAL-G (instrument de backup pentru PostgreSQL) ca exemplu, vă voi spune cum am rezolvat aceste probleme prin lansarea unui curs de dezvoltare open-source la universitate, ce am realizat și unde ne vom deplasa în continuare.
Salutare din nou tuturor! Sunt un dezvoltator Yandex din Ekaterinburg. Și astăzi voi vorbi despre WAL-G.
Titlul raportului nu spunea că este vorba despre copii de rezervă. Știe cineva ce este WAL-G? Sau stie toata lumea? Ridică mâna dacă nu știi. La dracu, ai venit la raport și nu știi despre ce este vorba.
Să vă spun ce se va întâmpla astăzi. Se întâmplă că echipa noastră a făcut copii de rezervă de ceva timp. Și acesta este un alt raport dintr-o serie în care vorbim despre modul în care stocăm datele în siguranță, în mod sigur, convenabil și eficient.
În seria anterioară au existat multe reportaje ale lui Andrei Borodin și Vladimir Leskov. Eram mulți dintre noi. Și despre WAL-G vorbim de mulți ani.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Acest raport va fi puțin diferit de celelalte prin faptul că a fost mai mult despre partea tehnică, dar aici voi vorbi despre cum am întâmpinat probleme asociate cu creșterea comunității. Și cum ne-a venit o idee mică care ne ajută să facem față acestui lucru.
Acum câțiva ani, WAL-G a fost un proiect destul de mic pe care l-am primit de la Citus Data. Și doar am luat-o. Și a fost dezvoltat de o singură persoană.
Și numai WAL-G nu avea:
- Backup dintr-o replică.
- Nu au existat copii de rezervă incrementale.
- Nu au existat copii de rezervă WAL-Delta.
- Și încă mai lipseau o mulțime.
În acești câțiva ani, WAL-G a crescut foarte mult.
Și până în 2020, toate cele de mai sus au apărut deja. Și la asta s-a adăugat ceea ce avem acum:
- Peste 1 de stele pe GitHub.
- 150 furculițe.
- Aproximativ 15 PR-uri deschise.
- Și mulți alți colaboratori.
- Și probleme deschise tot timpul. Și asta în ciuda faptului că mergem acolo în fiecare zi și facem ceva în acest sens.
Și am ajuns la concluzia că acest proiect necesită mai multă atenție, chiar și atunci când noi înșine nu trebuie să implementăm nimic pentru serviciul nostru de baze de date gestionate în Yandex.
Și undeva în toamna lui 2018 ne-a venit în minte o idee. De obicei, echipa are mai multe moduri de a dezvolta unele funcții sau de a remedia erori dacă nu aveți suficiente mâini. De exemplu, poți să angajezi un alt dezvoltator și să-i plătești bani. Sau poți să angajezi un stagiar pentru o perioadă și să-i plătești și un salariu. Dar există încă un grup destul de mare de oameni, dintre care unii știu deja să scrie cod. Doar că nu știi întotdeauna ce calitate este codul.
Ne-am gândit la asta și am decis să încercăm să atragem studenți. Dar studenții nu vor participa la toate cu noi. Ei vor face doar o parte din muncă. Și, de exemplu, vor scrie teste, vor repara erori, vor implementa caracteristici care nu afectează funcționalitatea principală. Funcționalitatea principală este crearea de copii de siguranță și restaurarea copiilor de rezervă. Dacă facem o greșeală în crearea unei copii de rezervă, vom experimenta pierderea datelor. Și nimeni nu vrea asta, desigur. Toată lumea vrea ca totul să fie foarte sigur. Prin urmare, desigur, nu vrem să lăsăm codul în care avem mai puțină încredere decât în al nostru. Adică, orice cod necritic este ceea ce am dori să primim de la lucrătorii noștri suplimentari.
În ce condiții este acceptată PR-ul studenților?
- Li se cere să-și acopere codul cu teste. Totul ar trebui să se petreacă în CI.
- Și trecem și prin 2 recenzii. Unul de Andrey Borodin și unul de mine.
- Și în plus, pentru a verifica că acest lucru nu va rupe nimic în serviciul nostru, încarc separat ansamblul cu acest commit. Și verificăm în teste end-to-end că nimic nu dă greș.
Curs special despre Open Source
Câteva despre de ce este nevoie de acest lucru și de ce aceasta, mi se pare, este o idee grozavă.
Pentru noi, profitul este evident:
- Primim mâini în plus.
- Și căutăm candidați pentru echipa printre studenții inteligenți care scriu cod inteligent.
Care este beneficiul pentru studenți?
Ele pot fi mai puțin evidente, deoarece studenții, cel puțin, nu primesc bani pentru codul pe care îl scriu, ci primesc doar note pentru fișele lor de studenți.
I-am întrebat despre asta. Și în cuvintele lor:
- Experiență de colaborator în Open Source.
- Obțineți o linie în CV-ul dvs.
- Dovediți-vă și treceți un interviu în Yandex.
- Deveniți membru GSoC.
- +1 curs special pentru cei care doresc să scrie cod.
Nu voi vorbi despre cum a fost structurat cursul. Voi spune doar că WAL-G a fost proiectul principal. Am inclus și proiecte precum Odyssey, PostgreSQL și ClickHouse în acest curs.
Și au dat probleme nu numai la acest curs, ci au dat și diplome și lucrări de curs.
Dar beneficiile pentru utilizatori?
Acum să trecem la partea care te interesează cel mai mult. La ce îți folosește asta? Ideea este că studenții au remediat o mulțime de erori. Și am creat funcțiile de solicitare pe care ne-ați cerut să le facem.
Și lasă-mă să-ți spun despre lucrurile pe care le-ai dorit de mult și care s-au realizat.
Suport pentru tablespaces. Spații de tabele din WAL-G au fost așteptate probabil de la lansarea lui WAL-G, deoarece WAL-G este succesorul unui alt instrument de backup WAL-E, unde au fost acceptate backup-urile bazei de date cu spații de tabele.
Permiteți-mi să vă reamintesc pe scurt ce este și de ce este necesar. De obicei, toate datele dvs. Postgres ocupă un director din sistemul de fișiere, numit bază. Și acest director conține deja toate fișierele și subdirectoarele cerute de Postgres.
Tablespace-urile sunt directoare care conțin date Postgres, dar nu se află în afara directorului de bază. Slide-ul arată că tablespac-urile sunt situate în afara directorului de bază.
Cum arată asta pentru Postgres în sine? Există un subdirector separat pg_tblspc în directorul de bază. Și conține legături simbolice către directoare care conțin de fapt date Postgres în afara directorului de bază.
Când folosești toate acestea, atunci pentru tine aceste comenzi pot arăta cam așa. Adică, creați un tabel într-un spațiu tabel specificat și vedeți unde este acum. Acestea sunt ultimele două linii, ultimele două comenzi numite. Și acolo este clar că există o cale. Dar, în realitate, aceasta nu este calea reală. Aceasta este calea prefixată de la directorul de bază la spațiul tabel. Și de acolo este asociat cu un link simbolic care duce la datele tale reale.
Nu folosim toate acestea în echipa noastră, dar au fost folosite de mulți alți utilizatori WAL-E care ne-au scris că vor să treacă la WAL-G, dar asta i-a oprit. Acest lucru este acum acceptat.
O altă caracteristică pe care ne-a adus-o cursul nostru special este catchup-ul. Oamenii care probabil au lucrat mai mult cu Oracle decât cu Postgres știu despre catchup.
Pe scurt despre ce este. Topologia clusterului din serviciul nostru poate arăta de obicei cam așa. Avem un maestru. Există o replică care transmite jurnalul de scriere anticipată din ea. Și replica îi spune masterului pe ce LSN se află în prezent. Și undeva în paralel cu aceasta, jurnalul poate fi arhivat. Și pe lângă arhivarea jurnalului, backup-urile sunt trimise și în cloud. Și sunt trimise copii de rezervă delta.
Care ar putea fi problema? Când aveți o bază de date destul de mare, se poate dovedi că replica dvs. începe să rămână cu mult în urma masterului. Și ea rămâne atât de mult în urmă încât nu-l poate ajunge niciodată din urmă. De obicei, această problemă trebuie rezolvată cumva.
Și cea mai ușoară modalitate este să eliminați replica și să o reîncărcați, pentru că nu va ajunge niciodată din urmă, iar problema trebuie rezolvată. Dar aceasta este o perioadă destul de lungă, deoarece restaurarea unei întregi copii de siguranță a bazei de date de 10 TB este o perioadă foarte, foarte lungă. Și vrem să facem toate acestea cât mai repede posibil dacă apar astfel de probleme. Și exact pentru asta este catchup-ul.
Catchup vă permite să utilizați copii de rezervă delta, care sunt stocate în cloud în acest fel. Spuneți pe ce LSN se află replica întârziată și o specificați în comanda catchup pentru a crea o copie de rezervă delta între acel LSN și LSN-ul pe care se află în prezent clusterul dvs. Și după aceea restabiliți această copie de rezervă pe replica care rămânea în urmă.
Alte baze
Studenții ne-au adus și o mulțime de funcții simultan. Deoarece la Yandex gătim nu numai Postgres, avem și MySQL, MongoDB, Redis, ClickHouse, la un moment dat trebuia să putem face copii de rezervă cu recuperare punct-in-time pentru MySQL și astfel încât să existe posibilitatea de a încărca ei la nor.
Și am vrut să o facem într-un mod similar cu ceea ce face WAL-G. Și am decis să experimentăm și să vedem cum va arăta totul.
Și la început, fără să împărtășească în vreun fel această logică, au scris codul în furcă. Au văzut că avem un fel de model de lucru și poate zbura. Apoi ne-am gândit că comunitatea noastră principală este postgresiștii, ei folosesc WAL-G. Și, prin urmare, trebuie să separăm cumva aceste părți. Adică, atunci când edităm cod pentru Postgres, nu spargem MySQL; când edităm MySQL, nu spargem Postgres.
Prima idee despre cum să se separe aceasta a fost ideea de a folosi aceeași abordare care este folosită în extensiile PostgreSQL. Și, de fapt, pentru a face o copie de rezervă MySQL a trebuit să instalați un fel de bibliotecă dinamică.
Dar aici asimetria acestei abordări este imediat vizibilă. Când faceți backup pentru Postgres, puneți o copie de rezervă normală pentru Postgres și totul este în regulă. Și pentru MySQL se dovedește că instalați o copie de rezervă pentru Postgres și, de asemenea, instalați o bibliotecă dinamică pentru MySQL pentru aceasta. Sună cam ciudat. Așa ne-am gândit și noi și am decis că aceasta nu este soluția de care aveam nevoie.
Diverse versiuni pentru Postgres, MySQL, MongoDB, Redis
Dar acest lucru ne-a permis, ni se pare, să luăm decizia corectă - să alocăm diferite ansambluri pentru diferite baze. Acest lucru a făcut posibilă izolarea logicii legate de backup-urile diferitelor baze de date care vor accesa API-ul comun pe care WAL-G îl implementează.
Aceasta este partea pe care am scris-o noi înșine - înainte de a le oferi elevilor problemele. Adică, aceasta este exact partea în care ar putea face ceva greșit, așa că am decis că ar fi bine să facem așa ceva și totul va fi bine.
După aceea am dat probleme. Au fost imediat demontate. Studenții au fost obligați să susțină trei baze.
Acesta este MySQL, pe care îl facem backup folosind WAL-G în acest fel de mai bine de un an.
Și acum MongoDB se apropie de producție, unde o termină cu un fișier. De fapt, noi am scris cadrul pentru toate acestea. Apoi, elevii au scris câteva lucruri viabile. Și apoi îi aducem într-o stare pe care o putem accepta în producție.
Aceste probleme nu păreau ca studenții aveau nevoie pentru a scrie instrumente de backup complete pentru fiecare dintre aceste baze de date. Nu am avut o astfel de problemă. Problema noastră a fost că doream o recuperare punct-in-time și am vrut să facem backup în cloud. Și le-au cerut studenților să scrie un cod care să rezolve acest lucru. Elevii au folosit instrumente de backup deja existente, care cumva preiau copii de rezervă, apoi le-au lipit pe toate împreună cu WAL-G, care le-a transmis totul în cloud. Și au adăugat, de asemenea, recuperarea punctuală la acest lucru.
Ce au mai adus elevii? Au adus suport de criptare Libsodium la WAL-G.
Avem și politici de stocare de rezervă. Acum backup-urile pot fi marcate ca permanente. Și cumva este mai convenabil pentru serviciul dvs. să automatizeze procesul de stocare a acestora.
Care a fost rezultatul acestui experiment?
Peste 100 de persoane s-au înscris inițial la curs. La început nu am spus că universitatea din Ekaterinburg este Universitatea Federală Ural. Am anunțat totul acolo. 100 de persoane s-au înscris. În realitate, mult mai puțini oameni au început să facă ceva, vreo 30 de oameni.
Și mai puține persoane au finalizat cursul, pentru că a fost necesar să se scrie teste pentru codurile deja existente. Și, de asemenea, remediați unele erori sau creați o funcție. Și unii studenți încă au închis cursul.
În prezent, pe parcursul acestui curs, studenții au rezolvat aproximativ 14 probleme și au realizat 10 caracteristici de diferite dimensiuni. Și, mi se pare, aceasta este o înlocuire cu drepturi depline a unuia sau doi dezvoltatori.
Printre altele, am eliberat diplome și cursuri. Și 12 au primit diplome. 6 dintre ei s-au apărat deja la „5”. Cei care au rămas nu au avut încă protecție, dar cred că totul va fi bine și pentru ei.
Planurile de viitor
Ce planuri avem pentru viitor?
Cel puțin acele solicitări de funcții pe care le-am auzit deja de la utilizatori și pe care dorim să le facem. Acest:
- Monitorizarea corectitudinii urmăririi cronologiei în arhiva de backup a clusterului HA. Puteți face acest lucru cu WAL-G. Și cred că vom avea studenți care se vor ocupa de această chestiune.
- Avem deja o persoană responsabilă cu transferul de copii de rezervă și WAL între nori.
- Și am publicat recent o idee că putem accelera WAL-G și mai mult prin despachetarea backup-urilor incrementale fără a rescrie pagini și prin optimizarea arhivelor pe care le trimitem acolo.
Le puteți împărtăși aici
Pentru ce a fost acest raport? Mai mult, acum, pe lângă cei 4 oameni care susțin acest proiect, mai avem mâini suplimentare, dintre care sunt destul de multe. Mai ales dacă le scrii într-un mesaj personal. Și dacă faceți o copie de rezervă a datelor și o faceți folosind WAL-G sau doriți să treceți la WAL-G, atunci vă putem satisface destul de ușor dorințele.
Acesta este un cod QR și un link. Puteți să le parcurgeți și să vă scrieți toate dorințele. De exemplu, nu remediam unele erori. Sau chiar doriți o funcție, dar din anumite motive nu este încă în nicio copie de rezervă, inclusiv în a noastră. Asigurați-vă că scrieți despre asta.
întrebări
Buna ziua! Multumesc pentru raport! Întrebare despre WAL-G, dar nu despre Postgres. WAL-G face backup pentru MySQL și apelează un backup suplimentar. Dacă luăm instalări moderne pe CentOS și dacă instalați yum MySQL, MariDB va fi instalat. Din versiunea 10.3, backupul suplimentar nu este acceptat, backup MariDB este acceptat. Cum te descurci cu asta?
Momentan nu am încercat să facem backup pentru MariDB. Am avut cereri pentru suport FoundationDB, dar, în general, dacă există o astfel de solicitare, atunci putem găsi oameni care o vor face. Nu este atât de lung sau atât de dificil pe cât cred.
Bună ziua Multumesc pentru raport! Întrebare despre potențialele funcții noi. Sunteți gata să faceți WAL-G să funcționeze cu benzi, astfel încât să puteți face backup pe benzi?
Backup pe bandă de stocare se pare că înseamnă?
Da.
Există Andrei Borodin, care poate răspunde la această întrebare mai bine decât mine.
(Andrey) Da, mulțumesc pentru întrebare! Am primit o solicitare de a transfera o copie de rezervă pe bandă din stocarea în cloud. Si pentru asta transfer între nori. Deoarece transferul cloud-to-cloud este o versiune generalizată a transferului pe bandă. În plus, avem o arhitectură extensibilă în ceea ce privește Stocarele. Apropo, multe Storoge au fost scrise de studenți. Și dacă scrieți Stocare pentru bandă, atunci, desigur, va fi acceptat. Suntem pregătiți să luăm în considerare cererile de retragere. Acolo trebuie să scrieți un fișier, să citiți un fișier. Dacă faci aceste lucruri în Go, ajungi de obicei cu 50 de linii de cod. Și apoi banda va fi acceptată în WAL-G.
Multumesc pentru raport! Interesant proces de dezvoltare. Backup-ul este o funcționalitate serioasă care ar trebui să fie bine acoperită de teste. Când ați implementat funcționalități pentru baze de date noi, elevii au scris și testele sau ați scris singur testele și apoi ați dat implementarea studenților?
Elevii au scris și teste. Dar studenții au scris mai mult pentru caracteristici precum noile baze de date. Au scris teste de integrare. Și au scris teste unitare. Dacă integrarea trece, adică în momentul de față, acesta este un script pe care îl executați manual sau aveți cron care îl face, de exemplu. Adică scenariul de acolo este foarte clar.
Elevii nu au prea multă experiență. Examinarea durează mult?
Da, recenziile durează destul de mult. Adică, de obicei, când mai mulți comisari vin deodată și spun că am făcut asta, am făcut asta, atunci trebuie să te gândești și să-ți aloci aproximativ o jumătate de zi pentru a-ți da seama ce au scris acolo. Pentru că codul trebuie citit cu atenție. Nu au avut un interviu. Nu le cunoaștem prea bine, așa că este nevoie de o perioadă semnificativă de timp.
Multumesc pentru raport! Anterior, Andrey Borodin a declarat că archive_command în WAL-G ar trebui apelat direct. Dar în cazul unui tip de cartuș cluster, avem nevoie de o logică suplimentară pentru a determina nodul de la care să trimitem arbori. Cum rezolvi singur această problemă?
Care este problema ta aici? Să presupunem că aveți o replică sincronă cu care faceți o copie de rezervă? Sau ce?
(Andrey) Faptul este că într-adevăr WAL-G este destinat să fie folosit fără scripturi shell. Dacă ceva lipsește, atunci să adăugăm logica care ar trebui să fie în interiorul WAL-G. În ceea ce privește de unde ar trebui să provină arhivarea, credem că arhivarea ar trebui să fie de la masterul actual din cluster. Arhivarea dintr-o replică este o idee proastă. Există diferite scenarii posibile cu probleme. În special, problemele legate de arhivarea termenelor și orice informații suplimentare. Multumesc pentru intrebare!
(Clarificare: Am scăpat de scripturile shell )
Bună seara! Multumesc pentru raport! Sunt interesat de funcția de recuperare despre care ați vorbit. Ne-am confruntat cu o situație în care o replică era în urmă și nu putea ajunge din urmă. Și nu am găsit o descriere a acestei caracteristici în documentele WAL-G.
Catchup a apărut literalmente pe 20 ianuarie 2020. Documentația ar putea avea nevoie de ceva mai multă muncă. O scriem noi înșine și nu o scriem foarte bine. Și poate că ar trebui să începem să cerem studenților să o scrie.
Este deja lansat?
Solicitarea de extragere este deja moartă, adică am verificat-o. Am încercat asta pe un cluster de testare. Până acum nu am avut o situație în care să putem testa acest lucru într-un exemplu de luptă.
Când să te aștepți?
Nu știu. Așteptați o lună, vom verifica cu siguranță.
Sursa: www.habr.com