Vi propongo di dare un'occhiata alla trascrizione della relazione di inizio 2020 di Georgy Rylov "WAL-G: nuove opportunità e allargamento della comunità"
I manutentori dell'open-source affrontano numerosi problemi man mano che crescono. Come scrivere sempre più funzionalità richieste, risolvere un numero sempre maggiore di problemi e riuscire a guardare un numero crescente di pull request? Usando l'esempio di WAL-G (tool di backup per PostgreSQL) vi racconterò come abbiamo risolto questi problemi avviando un corso di sviluppo Open-source all'università, cosa abbiamo raggiunto e quale sarà il nostro prossimo passo.
Ciao a tutti ancora una volta! Sono un sviluppatore in Yandex di Ekaterinburg. E oggi vi parlerò di WAL-G.
Nel titolo della relazione non era specificato che si trattasse di backup. Qualcuno non sa cosa sia WAL-G? O lo sanno tutti? Alzate la mano se non lo sapete. Wow, siete venuti alla relazione e non sapete di cosa si parla.
Parliamo di cosa ci sarà oggi. La nostra squadra si occupa di backup da un bel po' di tempo. E questa è un'altra relazione in una serie dove raccontiamo come memorizziamo i dati in modo sicuro, affidabile, comodo ed efficiente.
Nelle serie precedenti ci sono state molte relazioni di Andrey Borodin e Vladimir Leskov. Eravamo in molti. E negli ultimi anni abbiamo parlato di WAL-G per molto tempo.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Questa relazione sarà leggermente diversa dalle altre, poiché quelle si concentravano in gran parte sulla parte tecnica, mentre qui parlerò di come ci siamo confrontati con i problemi legati alla crescita della comunità. E di come abbiamo pensato a una piccola idea che ci aiuta a gestirlo.
Qualche anno fa WAL-G era un progetto piuttosto piccolo, che ci è stato dato da Citus Data. Abbiamo appena iniziato a lavorarci sopra. Era sviluppato da una sola persona.
E solo in WAL-G non c'era:
- Backup da replica.
- Non c'erano backup incrementali.
- Non c'erano backup WAL-Delta.
- E c'erano molte altre cose che mancavano.
Negli ultimi anni WAL-G è cresciuto notevolmente.
E entro il 2020 tutto ciò menzionato era già disponibile. E a questo si aggiunse anche il fatto che ora abbiamo:
- Oltre 1.000 stelle su GitHub.
- 150 fork.
- Circa 15 PR aperti.
- E anche molti contributori.
- E sempre nuovi issues aperti. E questo nonostante ci entriamo praticamente ogni giorno per gestirli.
E siamo giunti alla conclusione che questo progetto richiede più della nostra attenzione, anche quando noi stessi non abbiamo bisogno di implementare nulla per il nostro servizio Managed Databases in Yandex.
E da qualche parte nell'autunno del 2018 ci è venuta un'idea. Di solito un team ha diversi modi per sviluppare nuove funzionalità o risolvere bug quando mancano le risorse. Ad esempio, si può assumere un altro sviluppatore e pagarlo. Oppure si può prendere uno stagista per un certo periodo e pagargli uno stipendio. Ma c'è anche un gran numero di persone, parte delle quali sa davvero scrivere codice. Semplicemente, non sai sempre quale sia la qualità di questo codice.
Abbiamo pensato di provare ad attrarre studenti. Ma gli studenti non parteciperanno a tutto. Faranno solo una parte del lavoro. Ad esempio, scriveranno test, risolveranno bug, realizzeranno funzionalità che non influenzano la funzionalità principale. La funzionalità principale è la creazione di backup e il ripristino dei backup. Se si verifica un bug nella creazione di un backup, potremmo perdere dati. E nessuno lo desidera, ovviamente. Tutti vogliono che tutto sia molto affidabile. Pertanto, non vogliamo rischiare codice di cui non ci fidiamo meno rispetto al nostro. Cioè, qualsiasi codice non critico è ciò che speriamo di ricevere dalle nostre risorse aggiuntive.
In quali condizioni viene accettato un PR da uno studente
- Devono coprire il proprio codice con test. Tutto deve passare in CI.
- E facciamo anche 2 revisioni. Una da Andrej Borodin e una mia.
- Inoltre, per verificare che non rompa nulla nel nostro servizio, carico separatamente la build con questo commit. E controlliamo nei test end-to-end che non ci siano problemi.
Corso specialistico su Open Source
Un po' su perché è necessario e perché questa mi sembra una grande idea.
Per noi il profitto è ovvio:
- Otteniamo risorse aggiuntive.
- E cerchiamo candidati per il team tra studenti capaci che scrivono codice valido.
Qual è il profitto per gli studenti?
Possono essere meno evidenti, perché gli studenti, almeno, non ricevono denaro per il codice che scrivono, ma ricevono solo voti.
Ho chiesto loro a riguardo. E secondo le loro parole:
- Esperienza da contributore in Open Source.
- Avere una riga nel CV.
- Dare prova di sé e superare un colloquio con Yandex.
- Diventare partecipante di GSoC.
- +1 corso specialistico per chi vuole scrivere codice.
Non parlerò di come fosse strutturato il corso. Dico solo che WAL-G era il progetto principale. Inoltre, abbiamo incluso nel corso progetti come Odyssey, PostgreSQL e ClickHouse.
E non abbiamo dato incarichi solo in questo corso, ma abbiamo anche rilasciato diplomi e tesi.
E il beneficio per gli utenti?
Ora passiamo alla parte che vi interessa di più. Qual è il vantaggio per voi? Il vantaggio è che gli studenti hanno risolto molti bug. E hanno creato richieste di funzionalità che ci avete chiesto di realizzare.
E lasciate che vi parli delle cose che desideravate da tempo e che sono state implementate.
Supporto per tablespaces. Il supporto per i tablespaces in WAL-G era atteso fin dal rilascio di WAL-G, poiché WAL-G è il successore di un altro strumento di backup, WAL-E, che supportava il backup dei database con tablespaces.
In breve, ricordo cos'è e a cosa serve. Di solito, tutti i vostri dati Postgres occupano una directory nel file system chiamata directory base. E questa directory contiene già tutti i file e le sottodirectory necessari per Postgres.
I tablespaces sono directory in cui si trovano i dati di Postgres, ma non si trovano al di fuori della directory base. Nella diapositiva è evidente che i tablespace sono situati al di fuori della directory base.
Come appare per Postgres stesso? Nella directory base c'è una sottodirectory chiamata pg_tblspc. E vi si trovano collegamenti simbolici alle directory in cui si trovano effettivamente i dati di Postgres al di fuori della directory base.
Quando utilizzate tutto ciò, per voi questi comandi possono apparire in questo modo. Cioè, create una tabella in un tablespace specificato e controllate dove si trova ora. Queste due ultime righe, due ultime chiamate a comandi. E si vede che c'è un certo percorso. Ma in realtà, non è un percorso vero. È un percorso con un prefisso dalla directory base al tablespace. E da lì è legato a un collegamento simbolico che porta ai vostri dati reali.
Noi non utilizziamo tutto questo nel nostro team, ma è stato utilizzato da molti altri utenti di WAL-E, che ci hanno scritto dicendo che volevano migrare a WAL-G, ma questo era un ostacolo. Ora è supportato.
Un'altra funzionalità che ci ha portato il nostro corso specialistico è il catchup. La catchup è conosciuta da persone che probabilmente hanno lavorato di più con Oracle che con Postgres.
In breve, cos'è. Una topologia tipica di un cluster nel nostro servizio può apparire in questo modo. Abbiamo un master. C'è una replica che trasmette da lui il write-ahead log. E la replica informa il master su quale LSN si trova attualmente. E parallelamente a questo, il log può essere archiviato. Inoltre, vengono inviati backup nel cloud. E vengono inviati delta-backup.
Qual è il problema? Quando hai un database abbastanza grande, può succedere che la replica inizi a rallentare notevolmente rispetto al master. E rallenta così tanto che non può più raggiungerlo. Questo problema di solito deve essere affrontato in qualche modo.
Il modo più semplice è rimuovere la replica e reinstallarla da zero, perché non la recupererà mai più, e dobbiamo risolvere il problema. Ma questo richiede molto tempo, perché ripristinare un intero backup di un database da 10 TB richiede un tempo estremamente lungo. E vogliamo fare tutto il più rapidamente possibile, se si verificano questi problemi. Ed è proprio a questo scopo che è stato progettato catchup.
Catchup consente di utilizzare delta-backup, che vengono salvati nel cloud in questo modo. Indicate a quale LSN si trova attualmente la replica in ritardo e lo specificate nel comando catchup per creare un delta-backup tra quel LSN e l’LSN su cui si trova attualmente il vostro cluster. E dopo ricostruite questo backup sulla replica che era in ritardo.
Altri database
Inoltre, gli studenti ci hanno portato subito molte funzionalità. Poiché in Yandex ci occupiamo non solo di Postgres, ma anche di MySQL, MongoDB, Redis, ClickHouse, a un certo punto è stato necessario poter fare backup con point-in-time recovery per MySQL, e avere la possibilità di caricarli nel cloud.
Volevamo farlo in un modo simile a quello in cui fa WAL-G. E abbiamo deciso di sperimentare per vedere come sarebbe stato.
Inizialmente, senza separare questa logica, abbiamo scritto il codice in un fork. Abbiamo visto che avevamo un modello funzionante e questo poteva decollare. Poi abbiamo pensato che la nostra comunità principale sono i postgresisti, che utilizzano WAL-G. Perciò era necessario separare queste parti. Cioè, quando modifichiamo il codice per Postgres non rompiamo MySQL, e quando modifichiamo MySQL non rompiamo Postgres.
La prima idea su come separarlo è stata quella di utilizzare lo stesso approccio usato nelle estensioni di PostgreSQL. E, in sostanza, per fare un backup di MySQL dovevi installare qualche libreria dinamica.
Ma qui si vede subito l'asimmetria di questo approccio. Quando esegui il backup di Postgres, installi un normale strumento di backup per Postgres e tutto va bene. E per MySQL risulta che installi uno strumento di backup per Postgres e poi installi anche una libreria dinamica per MySQL. Sembra un po' strano. Anche noi abbiamo pensato questo e abbiamo deciso che non era la soluzione di cui avevamo bisogno.
Diverse build per Postgres, MySQL, MongoDB, Redis
Ma questo ci ha permesso, a nostro avviso, di arrivare alla soluzione giusta: separare diverse build per diversi database. Questo consentiva di isolare la logica relativa ai backup delle varie basi di dati, che si sarebbero collegate a un'API comune fornita da WAL-G.
Questa è la parte che abbiamo scritto noi stessi, prima di dare compiti agli studenti. Cioè, questa è proprio la parte in cui potevano fare qualcosa di sbagliato, quindi abbiamo deciso che era meglio fare noi qualcosa di corretto e andava tutto benissimo.
Dopo di ciò abbiamo assegnato i compiti. Sono stati subito presi. Agli studenti era richiesto di supportare tre database.
Questo è MySQL, che stiamo backupando con WAL-G in questo modo da oltre un anno.
E ora MongoDB si sta avvicinando alla produzione, dove lo stanno limando con attenzione. In sostanza, abbiamo scritto il framework per tutto ciò. Poi gli studenti hanno scritto alcune cose funzionanti. E dopo le ottimizziamo fino a raggiungere uno stato che possiamo accettare in produzione.
Questi compiti non sembravano richiedere agli studenti di scrivere strumenti di backup completi per ciascuno di questi database. Non avevamo questo problema. Il nostro problema era che volevamo il recovery point-in-time e volevamo eseguire il backup nel cloud. E abbiamo chiesto agli studenti di scrivere del codice che risolvesse questo. Gli studenti hanno utilizzato strumenti di backup già esistenti, che in qualche modo eseguono i backup, e poi hanno combinato il tutto con WAL-G, che inviava tutto nel cloud. E hanno anche aggiunto il recovery point-in-time.
Cosa altro hanno portato gli studenti? Hanno portato in WAL-G il supporto per la crittografia Libsodium.
Abbiamo anche introdotto politiche di retention per i backup. Ora i backup possono essere contrassegnati come permanenti. E risulta più comodo per il vostro servizio automatizzare il processo di loro conservazione.
Quali sono stati i risultati di questo esperimento?
Inizialmente si erano registrate più di 100 persone al corso. All'inizio non ho detto che l'università di Ekaterinburg è l'Università Federale degli Urali. Lì abbiamo fatto tutti gli annunci. Si sono registrate 100 persone. In realtà, solo circa 30 hanno iniziato veramente a lavorare.
Ancora meno persone hanno completato il corso, perché era necessario scrivere test per i codici già esistenti. Inoltre, dovevano risolvere un bug o implementare una funzionalità. Parte degli studenti ha comunque completato il corso.
Attualmente, gli studenti hanno risolto circa 14 problemi e realizzato 10 funzionalità di varie dimensioni per questo corso. E, come mi sembra, è una sostituzione completa di uno o due sviluppatori.
In aggiunta, abbiamo consegnato diplomi e lavori di corso. E 12 hanno ricevuto i diplomi. 6 di loro si sono già laureati con un "5". Gli altri non hanno ancora sostenuto la difesa, ma credo che andrà bene anche per loro.
Piani futuri
Quali sono i nostri piani per il futuro?
Almeno, le richieste di funzionalità che abbiamo già sentito dagli utenti e vogliamo realizzare. Queste sono:
- Monitoraggio della correttezza del tracciamento della timeline nell'archivio dei backup del cluster HA. Con WAL-G è possibile farlo. E penso che troveremo studenti che si occuperanno di questo.
- Abbiamo già una persona responsabile per il trasferimento dei backup e del WAL tra i cloud.
- E recentemente abbiamo pubblicato l'idea che possiamo velocizzare ulteriormente WAL-G grazie all'estrazione dei backup incrementali senza riscrivere le pagine e ottimizzando gli archivi che inviamo.
Puoi condividerli qui
A cosa serviva questa relazione? Al fatto che ora, oltre a noi 4 che sosteniamo questo progetto, abbiamo anche molte mani aggiuntive. Soprattutto se contattati in privato. E se stai facendo il backup dei tuoi dati e lo stai facendo con WAL-G o desideri passare a WAL-G, possiamo tenere facilmente in considerazione le tue richieste.
Questo è un codice qr e un link. Puoi usarli per andare e scrivere tutte le tue richieste. Per esempio, se non risolviamo un bug o c'è una funzionalità che desideri molto, ma per qualche motivo non è ancora presente in nessun backup, compreso il nostro. Assicurati di farcelo sapere.
Domande
Ciao! Grazie per la presentazione! Ho una domanda su WAL-G, ma non riguardo a Postgres. WAL-G esegue il backup di MySQL e attiva il backup extra. Se consideri le installazioni moderne su CentOS e se esegui 'yum install MySQL', viene installato MariaDB. Dalla versione 10.3, il backup extra non è supportato, mentre il backup di MariaDB è supportato. Come state messi con questo?
Al momento non abbiamo provato a eseguire il backup di MariaDB. Abbiamo ricevuto richieste per il supporto di FoundationDB, ma in generale, se arriva una richiesta, possiamo trovare persone che lo faranno. Non ci vuole molto e non è così complicato, come mi sembra.
Buongiorno! Grazie per la presentazione! Ho una domanda su potenziali nuove funzionalità. Siete pronti a far funzionare WAL-G con i nastri, così da poter eseguire backup su nastro?
Si riferisce a un backup su archiviazione a nastro, giusto?
Sì.
C'è Andrey Borodin, che può rispondere meglio di me a questa domanda.
(Andrey) Sì, grazie per la domanda! Abbiamo ricevuto una richiesta per trasferire il backup su nastro da un'archiviazione cloud. E per questo su un trasferimento tra i cloud. Perché il trasferimento tra i cloud è una sorta di versione generica del trasferimento su nastro. Inoltre, abbiamo un'architettura estensibile per quanto riguarda gli Storage. A proposito, molti Storage sono stati scritti da studenti. E se scrivete uno Storage per i nastri, sarà sicuramente supportato. Siamo pronti a considerare la pull request. È necessario scrivere un file e leggerlo. Se queste cose vengono fatte in Go, in genere richiedono 50 righe di codice. E allora il nastro sarà supportato in WAL-G.
Grazie per la presentazione! Un processo di sviluppo interessante. Il backup è una parte seria della funzionalità, che deve essere ben coperta dai test. Quando implementavate funzionalità per nuovi database, i test sono stati scritti anche dagli studenti, o li avete scritti voi e poi li avete dati in implementazione agli studenti?
I test sono stati scritti anche dagli studenti. Ma gli studenti scrivevano di più per funzionalità come i nuovi database. Scrivevano test di integrazione. E scrivevano test unitari. Se i test di integrazione passano, nel senso che attualmente - è uno scenario che eseguite manualmente o che viene eseguito da cron, ad esempio. Cioè, è uno scenario molto chiaro.
Gli studenti non hanno molta esperienza. Quanto tempo ci vuole per le revisioni?
Sì, le revisioni richiedono abbastanza tempo. Cioè, di solito, quando arrivano diversi committers e dicono che ho fatto questo, ho fatto quello, è necessario riflettere e dedicare un mezzo giorno a capire ciò che hanno scritto. Perché il codice deve essere letto attentamente. Non hanno mai sostenuto un colloquio. Non li conosciamo molto bene, quindi questo richiede tempo considerevole.
Grazie per la presentazione! In precedenza, Andrey Borodin ha dichiarato che archive_command in WAL-G dovrebbe essere chiamato direttamente. Ma nel caso di un cluster patron, abbiamo bisogno di una logica aggiuntiva per determinare il nodo da cui inviare i segnali. Come risolvete voi questo problema?
Qual è il problema che avete qui? Supponiamo che abbiate una replica sincronizzata da cui prendete il backup? O cosa?
(Andrey) Il fatto è che WAL-G prevede l'uso senza script shell. Se manca qualcosa, aggiungiamo la logica che deve essere all'interno di WAL-G. Per quanto riguarda da dove dovrebbe avvenire l'archiviazione, riteniamo che l'archiviazione debba avvenire dall'attuale master nel cluster. L'archiviazione da una replica è una cattiva idea. Ci sono vari scenari con problemi. In particolare, ci sono problemi con l'archiviazione delle timeline e di altre informazioni aggiuntive. Grazie per la domanda!
(Chiarimento: Ci siamo liberati dagli script shell) )
Buonasera! Grazie per la presentazione! Sono rimasto colpito dalla funzione catchup di cui avete parlato. Ho avuto situazioni in cui una replica arrancava e non riusciva a recuperare. E in WAL-G non ho trovato una descrizione di questa funzione nella documentazione.
Catchup è apparso letteralmente nei primi giorni di gennaio 2020. Potrebbe valere la pena lavorare meglio sulla documentazione. La stiamo redigendo noi stessi e non è che la stiamo facendo in modo superlativo. E potrebbe essere giusto iniziare a richiedere agli studenti di scriverla.
È già in rilascio?
La pull request è già stata unita, cioè l'ho controllata. L'ho provato su un cluster di test. Finora non abbiamo avuto una situazione in cui potessimo testarlo in un caso reale.
Quando possiamo aspettarci?
Non lo so. Aspettate un mese, lo testeremo di sicuro.
Fonte: habr.com
