Us suggereixo que llegiu la transcripció de l'informe de principis de 2020 de Georgy Rylov "WAL-G: noves oportunitats i expansió de la comunitat"
Els mantenedors de codi obert s'enfronten a molts reptes a mesura que creixen. Com escriure cada cop més funcions necessàries, solucionar cada cop més problemes i aconseguir veure més i més sol·licituds d'extracció? Utilitzant WAL-G (eina de còpia de seguretat per a PostgreSQL) com a exemple, us explicaré com hem resolt aquests problemes llançant un curs sobre Desenvolupament de codi obert a la universitat, què hem aconseguit i cap a on ens avançarem.
Hola de nou a tothom! Sóc un desenvolupador Yandex de Iekaterinburg. I avui us parlaré de WAL-G.
El títol de l'informe no deia que es tractés de còpies de seguretat. Algú sap què és WAL-G? O ho sap tothom? Aixeca la mà si no ho saps. Merda, has vingut al reportatge i no saps de què va.
Deixa'm dir-te què passarà avui. Succeeix que el nostre equip fa una bona estona fent còpies de seguretat. I aquest és un altre informe d'una sèrie on parlem de com emmagatzemem les dades de manera segura, còmoda i eficient.
En sèries anteriors hi havia molts informes d'Andrei Borodin i Vladimir Leskov. Érem molts. I fa molts anys que parlem de WAL-G.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Aquest informe serà una mica diferent dels altres perquè tractava més de la part tècnica, però aquí parlaré de com ens hem trobat amb problemes associats al creixement de la comunitat. I com ens va ocórrer una petita idea que ens ajuda a afrontar-ho.
Fa uns anys, WAL-G era un projecte bastant petit que vam obtenir de Citus Data. I només l'hem agafat. I va ser desenvolupat per una sola persona.
I només WAL-G no tenia:
- Còpia de seguretat d'una rèplica.
- No hi va haver còpies de seguretat incrementals.
- No hi havia còpies de seguretat de WAL-Delta.
- I encara faltava molt.
Durant aquests pocs anys, WAL-G ha crescut molt.
I el 2020, ja ha aparegut tot l'anterior. I a això s'hi va afegir el que ara tenim:
- Més de 1 estrelles a GitHub.
- 150 forquilles.
- Uns 15 PR oberts.
- I molts més col·laboradors.
- I temes oberts tot el temps. I això malgrat que literalment hi anem cada dia i fem alguna cosa al respecte.
I vam arribar a la conclusió que aquest projecte requereix més atenció, fins i tot quan nosaltres mateixos no necessitem implementar res per al nostre servei de bases de dades gestionades a Yandex.
I en algun moment de la tardor del 2018, ens va venir una idea al cap. En general, l'equip té diverses maneres de desenvolupar algunes funcions o corregir errors si no teniu prou mans. Per exemple, podeu contractar un altre desenvolupador i pagar-li diners. O pots contractar un becari durant un temps i també pagar-li un sou. Però encara hi ha un grup bastant important de persones, algunes de les quals ja saben com escriure codi. Simplement no sempre saps quina qualitat té el codi.
Ho vam pensar i vam decidir intentar atraure alumnes. Però els alumnes no participaran de tot amb nosaltres. Només faran una part de la feina. I, per exemple, escriuran proves, corregeix errors, implementarà funcions que no afecten la funcionalitat principal. La funcionalitat principal és crear còpies de seguretat i restaurar còpies de seguretat. Si cometem un error en crear una còpia de seguretat, experimentarem una pèrdua de dades. I això ningú vol, és clar. Tothom vol que tot sigui molt segur. Per tant, per descomptat, no volem deixar codi en què confiem menys que el nostre. És a dir, qualsevol codi no crític és el que ens agradaria rebre dels nostres treballadors addicionals.
En quines condicions s'accepten les relacions públiques dels estudiants?
- Han de cobrir el seu codi amb proves. Tot hauria de passar a CI.
- I també passem per 2 ressenyes. Un d'Andrey Borodin i un altre de mi.
- I a més, per comprovar que això no trencarà res al nostre servei, carrego el muntatge per separat amb aquest commit. I comprovem en proves d'extrem a extrem que res falla.
Curs especial de codi obert
Una mica sobre per què això és necessari i per què això, em sembla, és una idea genial.
Per a nosaltres, el benefici és evident:
- Tenim mans addicionals.
- I busquem candidats per a l'equip entre estudiants intel·ligents que escriuen codi intel·ligent.
Quin és el benefici per als estudiants?
Poden ser menys evidents, perquè els estudiants, com a mínim, no reben diners pel codi que escriuen, sinó que només reben qualificacions dels seus expedients d'estudiants.
Els vaig preguntar sobre això. I en les seves paraules:
- Experiència de col·laborador en codi obert.
- Aconsegueix una línia al teu currículum.
- Demostra't i passa una entrevista a Yandex.
- Fes-te membre de GSoC.
- +1 curs especial per a aquells que vulguin escriure codi.
No parlaré de com s'ha estructurat el curs. Només diré que WAL-G va ser el projecte principal. També hem inclòs projectes com Odyssey, PostgreSQL i ClickHouse en aquest curs.
I van donar problemes no només en aquest curs, sinó que també van lliurar diplomes i treballs.
Què passa amb el benefici per als usuaris?
Ara passem a la part que més t'interessa. De què et serveix això? La qüestió és que els alumnes van solucionar molts errors. I vam fer les funcions de sol·licitud que ens vau demanar.
I deixa'm que t'expliqui les coses que fa temps que volies i que s'han realitzat.
Suport de tablespaces. S'han esperat espais de taula a WAL-G probablement des del llançament de WAL-G, perquè WAL-G és el successor d'una altra eina de còpia de seguretat WAL-E, on es suportaven còpies de seguretat de bases de dades amb espais de taula.
Permeteu-me que us recordi breument què és i per què és necessari. Normalment, totes les vostres dades de Postgres ocupen un directori del sistema de fitxers, anomenat base. I aquest directori ja conté tots els fitxers i subdirectoris requerits per Postgres.
Els espais de taula són directoris que contenen dades de Postgres, però no es troben fora del directori base. La diapositiva mostra que els tablespacs es troben fora del directori base.
Què sembla això per a Postgres? Hi ha un subdirectori separat pg_tblspc al directori base. I conté enllaços simbòlics a directoris que en realitat contenen dades de Postgres fora del directori base.
Quan utilitzeu tot això, per a vosaltres aquestes ordres poden semblar així. És a dir, creeu una taula en un espai de taula especificat i veieu on és ara. Aquestes són les dues últimes línies, les dues últimes ordres anomenades. I allà està clar que hi ha alguna manera. Però, en realitat, aquest no és el camí real. Aquest és el camí prefixat del directori base a l'espai de taula. I a partir d'aquí es combina amb un enllaç simbòlic que condueix a les vostres dades reals.
No fem servir tot això al nostre equip, però ho van fer servir molts altres usuaris de WAL-E que ens van escriure que volien passar a WAL-G, però això els impedia. Això ara és compatible.
Una altra característica que ens va aportar el nostre curs especial és posar-nos al dia. Les persones que probablement han treballat més amb Oracle que amb Postgres coneixen el catchup.
Breument sobre què és. La topologia del clúster del nostre servei normalment pot semblar així. Tenim un mestre. Hi ha una rèplica que transmet el registre d'escriptura anticipada des d'ella. I la rèplica indica al mestre en quin LSN es troba actualment. I en algun lloc paral·lel a això, el registre es pot arxivar. I a més d'arxivar el registre, també s'envien còpies de seguretat al núvol. I s'envien còpies de seguretat delta.
Quin podria ser el problema? Quan teniu una base de dades bastant gran, pot resultar que la vostra rèplica comenci a quedar molt enrere del mestre. I ella es queda tan enrere que mai no el podrà posar al dia. Normalment, aquest problema s'ha de resoldre d'alguna manera.
I la manera més senzilla és eliminar la rèplica i tornar-la a carregar, perquè mai no s'aconseguirà i s'ha de resoldre el problema. Però això és un temps força llarg, perquè restaurar una còpia de seguretat sencera de la base de dades de 10 TB és molt, molt llarg. I volem fer tot això el més aviat possible si sorgeixen aquests problemes. I això és exactament el que serveix per recuperar-se.
Catchup us permet utilitzar còpies de seguretat delta, que s'emmagatzemen al núvol d'aquesta manera. Digueu en quin LSN es troba actualment la rèplica retardada i l'especifiqueu a l'ordre catchup per crear una còpia de seguretat delta entre aquest LSN i el LSN on es troba actualment el vostre clúster. I després d'això, restaureu aquesta còpia de seguretat a la rèplica que estava enrere.
Altres bases
Els alumnes també ens van aportar moltes característiques alhora. Com que a Yandex no només cuinem Postgres, també tenim MySQL, MongoDB, Redis, ClickHouse, en algun moment havíem de poder fer còpies de seguretat amb recuperació puntual per a MySQL, i perquè hi hagués l'oportunitat de pujar. els al núvol.
I volíem fer-ho d'una manera semblant al que fa WAL-G. I vam decidir experimentar i veure com quedaria tot.
I al principi, sense compartir aquesta lògica de cap manera, van escriure el codi a la bifurcació. Van veure que tenim algun tipus de model de treball i que pot volar. Aleshores vam pensar que la nostra comunitat principal són els postgresistes, ells utilitzen WAL-G. I, per tant, hem de separar d'alguna manera aquestes parts. És a dir, quan editem codi per a Postgres, no trenquem MySQL; quan editem MySQL, no trenquem Postgres.
La primera idea sobre com separar això va ser la idea d'utilitzar el mateix enfocament que s'utilitza a les extensions de PostgreSQL. I, de fet, per fer una còpia de seguretat de MySQL calia instal·lar algun tipus de biblioteca dinàmica.
Però aquí l'asimetria d'aquest enfocament és immediatament visible. Quan feu una còpia de seguretat de Postgres, hi poseu una còpia de seguretat normal de Postgres i tot està bé. I per a MySQL resulta que instal·leu una còpia de seguretat per a Postgres i també instal·leu una biblioteca dinàmica per a MySQL. Sona una mica estrany. Nosaltres també ho vam pensar i vam decidir que aquesta no era la solució que necessitàvem.
Diverses compilacions per a Postgres, MySQL, MongoDB, Redis
Però això ens va permetre, ens sembla, prendre la decisió correcta: destinar diferents assemblees per diferents bases. Això va permetre aïllar la lògica vinculada a còpies de seguretat de diverses bases de dades que accediran a l'API comuna que implementa WAL-G.
Aquesta és la part que vam escriure nosaltres mateixos, abans de donar els problemes als alumnes. És a dir, aquesta és exactament la part on podrien fer alguna cosa malament, així que vam decidir que seria millor fer una cosa així i tot anirà bé.
Després d'això vam donar problemes. Immediatament es van desmuntar. Els estudiants havien de donar suport a tres bases.
Es tracta de MySQL, del qual fem una còpia de seguretat utilitzant WAL-G d'aquesta manera durant més d'un any.
I ara MongoDB s'acosta a la producció, on l'estan acabant amb un fitxer. De fet, vam escriure el marc de tot això. Llavors els alumnes van escriure algunes coses útils. I després els portem a un estat que podem acceptar en la producció.
Aquests problemes no semblaven que els estudiants necessitessin escriure eines de còpia de seguretat completes per a cadascuna d'aquestes bases de dades. No teníem aquest problema. El nostre problema era que volíem una recuperació puntual i volíem fer una còpia de seguretat al núvol. I van demanar als estudiants que escrivissin algun codi que resolgués això. Els estudiants van utilitzar eines de còpia de seguretat ja existents, que d'alguna manera prenen còpies de seguretat, i després ho van enganxar tot amb WAL-G, que ho va reenviar tot al núvol. I també van afegir una recuperació puntual a això.
Què més van portar els alumnes? Van portar suport de xifratge Libsodium a WAL-G.
També tenim polítiques d'emmagatzematge de seguretat. Ara les còpies de seguretat es poden marcar com a permanents. I d'alguna manera és més convenient per al vostre servei automatitzar el procés d'emmagatzematge.
Quin va ser el resultat d'aquest experiment?
Més de 100 persones es van inscriure inicialment al curs. Al principi no vaig dir que la universitat de Iekaterinburg sigui la Universitat Federal dels Urals. Allà ho vam anunciar tot. 100 persones inscrites. En realitat, molta menys gent va començar a fer alguna cosa, unes 30 persones.
Encara menys persones van completar el curs, perquè calia fer proves per als codis que ja existeixen. I també corregeix algun error o crea alguna funció. I alguns alumnes encara van tancar el curs.
Actualment, durant aquest curs, els alumnes han solucionat uns 14 problemes i han fet 10 funcions de diferents mides. I, em sembla, aquest és un reemplaçament complet d'un o dos desenvolupadors.
Entre altres coses, vam lliurar diplomes i cursos. I 12 van rebre diplomes. 6 d'ells ja s'han defensat a “5”. Els que es van quedar encara no tenien protecció, però crec que també els anirà tot bé.
Plans per al futur
Quins plans tenim de futur?
Almenys aquelles sol·licituds de funcions que ja hem escoltat dels usuaris i que volem fer. Això:
- Supervisió de la correcció del seguiment de la línia de temps a l'arxiu de còpia de seguretat del clúster HA. Podeu fer-ho amb WAL-G. I crec que tindrem estudiants que s'ocupen d'aquest tema.
- Ja tenim un responsable de transferir còpies de seguretat i WAL entre núvols.
- I recentment hem publicat una idea que podem accelerar encara més WAL-G descomprimint còpies de seguretat incrementals sense reescriure pàgines i optimitzar els arxius que hi enviem.
Podeu compartir-los aquí
Per a què va ser aquest informe? A més, ara, a més de les 4 persones que donen suport a aquest projecte, tenim mans addicionals, de les quals n'hi ha força. Sobretot si els escrius en un missatge personal. I si feu una còpia de seguretat de les vostres dades i ho feu amb WAL-G o voleu passar a WAL-G, podrem satisfer els vostres desitjos fàcilment.
Aquest és un codi QR i un enllaç. Pots repassar-los i escriure tots els teus desitjos. Per exemple, no estem arreglant cap error. O realment voleu alguna funció, però per algun motiu encara no es troba a cap còpia de seguretat, inclosa la nostra. Assegureu-vos d'escriure sobre això.
Les vostres preguntes
Hola! Gràcies pel reportatge! Pregunta sobre WAL-G, però no sobre Postgres. WAL-G fa una còpia de seguretat de MySQL i fa una còpia de seguretat addicional. Si fem instal·lacions modernes a CentOS i si instal·leu MySQL, s'instal·larà MariDB. A partir de la versió 10.3, la còpia de seguretat addicional no és compatible, la còpia de seguretat MariDB és compatible. Com estàs amb això?
De moment no hem intentat fer una còpia de seguretat de MariDB. Hem tingut sol·licituds de suport de FoundationDB, però en general, si hi ha una sol·licitud d'aquest tipus, podem trobar gent que la faci. No és tan llarg ni tan difícil com crec.
Bona tarda Gràcies pel reportatge! Pregunta sobre noves funcions potencials. Esteu preparat per fer que WAL-G funcioni amb cintes perquè pugueu fer còpies de seguretat a les cintes?
Còpia de seguretat a l'emmagatzematge en cinta aparentment vol dir?
Sí
Hi ha Andrei Borodin, que pot respondre aquesta pregunta millor que jo.
(Andrey) Sí, gràcies per la pregunta! Vam tenir una sol·licitud per transferir una còpia de seguretat a una cinta des de l'emmagatzematge al núvol. I per això transferència entre núvols. Perquè la transferència de núvol a núvol és una versió generalitzada de la transferència de cinta. A més, disposem d'una arquitectura extensible pel que fa als magatzems. Per cert, molts Storoges van ser escrits per estudiants. I si escriviu Emmagatzematge per a cinta, llavors, per descomptat, serà compatible. Estem preparats per considerar les sol·licituds d'extracció. Allà cal escriure un fitxer, llegir un fitxer. Si feu aquestes coses a Go, normalment acabeu amb 50 línies de codi. I després la cinta serà compatible amb WAL-G.
Gràcies pel reportatge! Interessant procés de desenvolupament. La còpia de seguretat és una funcionalitat seriosa que hauria de ser ben coberta per proves. Quan vau implementar la funcionalitat per a bases de dades noves, els estudiants també van escriure les proves, o vau escriure les proves vosaltres mateixos i després vau donar la implementació als estudiants?
Els estudiants també feien proves. Però els estudiants van escriure més per a funcions com ara bases de dades noves. Van escriure proves d'integració. I van escriure proves unitàries. Si la integració passa, és a dir, de moment, aquest és un script que executeu manualment o teniu cron fent-ho, per exemple. És a dir, el guió allà és molt clar.
Els alumnes no tenen molta experiència. La revisió requereix molt de temps?
Sí, les ressenyes triguen molt de temps. És a dir, normalment, quan diversos committers vénen alhora i diuen que jo vaig fer això, jo vaig fer allò, llavors cal pensar i reservar aproximadament mig dia per esbrinar què hi van escriure. Perquè el codi s'ha de llegir amb atenció. No van tenir una entrevista. No els coneixem gaire bé, per la qual cosa requereixen molt de temps.
Gràcies pel reportatge! Anteriorment, Andrey Borodin va dir que archive_command a WAL-G s'hauria de cridar directament. Però en el cas d'algun tipus de cartutx de clúster, necessitem una lògica addicional per determinar el node des del qual enviar els eixos. Com resoleu aquest problema vosaltres mateixos?
Quin és el teu problema aquí? Suposem que teniu una rèplica síncrona amb la qual feu una còpia de seguretat? O què?
(Andrey) El fet és que, efectivament, WAL-G està pensat per ser utilitzat sense scripts de shell. Si falta alguna cosa, afegim la lògica que hauria d'haver dins de WAL-G. Pel que fa a la procedència de l'arxivament, creiem que l'arxivar hauria de ser del mestre actual del clúster. Arxivar d'una rèplica és una mala idea. Hi ha diversos escenaris possibles amb problemes. En particular, problemes amb l'arxivament de cronologies i qualsevol informació addicional. Gràcies per la pregunta!
(Aclariment: ens vam desfer dels scripts de shell )
Bona nit! Gràcies pel reportatge! M'interessa la funció de recuperació de la qual vas parlar. Ens vam trobar davant d'una situació en què una rèplica estava enrere i no podia posar-se al dia. I no he trobat una descripció d'aquesta característica als documents WAL-G.
Catchup va aparèixer literalment el 20 de gener de 2020. La documentació pot necessitar més feina. Ho escrivim nosaltres mateixos i no ho escrivim molt bé. I potser hauríem de començar a demanar als estudiants que l'escriguin.
Ja està estrenat?
La sol·licitud d'extracció ja està morta, és a dir, la vaig comprovar. Ho vaig provar en un clúster de prova. Fins ara no hem tingut una situació en què poguéssim provar això en un exemple de combat.
Quan esperar?
No ho sé. Espereu un mes, ho comprovarem segur.
Font: www.habr.com