Vi invito a consultare la trascrizione della presentazione di inizio 2020 di Georgij Ryžov "WAL-G: nuove opportunità e l'espansione della comunità"
I maintainer open-source affrontano molteplici sfide man mano che crescono. Come scrivere sempre più funzionalità richieste, risolvere sempre più problemi e gestire un numero crescente di pull request? Utilizzando l'esempio di WAL-G (strumento di backup per PostgreSQL), parlerò di come abbiamo affrontato questi problemi, avviando un corso di sviluppo Open-source all'università, cosa abbiamo ottenuto e quali saranno i nostri prossimi passi.
Ciao a tutti di nuovo! Sono uno sviluppatore di Yandex e provengo da Ekaterinburg. Oggi parlerò di WAL-G.
Nel titolo della presentazione non era specificato che si trattava di backup. Qualcuno non sa cos'è WAL-G? O lo sanno tutti? Alzate la mano se non lo sapete. Wow, siete venuti alla presentazione senza sapere di cosa si tratta.
Lasciate che vi spieghi cosa accadrà oggi. È successo che il nostro team si occupa di backup da un po' di tempo. E questa è un'altra presentazione della serie in cui parliamo di come conserviamo i dati in modo sicuro, affidabile, conveniente ed efficace.
Nelle puntate precedenti ci sono stati molti interventi di Andrey Borodin e Vladimir Leskov. Eravamo in molti. E tutti noi abbiamo parlato di WAL-G per molti anni.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Questa presentazione si differenzierà leggermente dalle altre, poiché si concentrerà maggiormente sugli aspetti tecnici, mentre qui parlerò di come abbiamo affrontato le sfide legate alla crescita della comunità. E di come abbiamo ideato una piccola soluzione che ci aiuta a gestire tutto ciò.
Qualche anno fa, WAL-G era un progetto piuttosto piccolo, che abbiamo ereditato da Citus Data. E noi lo abbiamo appena preso. Era sviluppato da una sola persona.
E in WAL-G non c'era:
- Backup da replica.
- Non c'erano backup incrementali.
- Non c'erano backup WAL-Delta.
- E ancora molte altre funzionalità mancavano.
Negli ultimi anni, WAL-G è cresciuto notevolmente.
Entro il 2020, tutte le precedenti funzionalità erano già disponibili. E a questo si aggiunge:
- Oltre 1.000 stelle su GitHub.
- 150 fork.
- Circa 15 PR aperti.
- E ancora molti contributori.
- E ci sono sempre issue aperte. Considerando che ci entriamo letteralmente ogni giorno per fare qualcosa a riguardo.
Abbiamo capito che questo progetto richiede maggiore attenzione da parte nostra, anche quando 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 il team ha diversi modi per implementare nuove funzionalità o risolvere bug quando le risorse scarseggiano. Ad esempio, puoi assumere un altro sviluppatore e pagarlo. Oppure puoi prendere uno stagista per un certo periodo e anche pagarlo. Ma c'è anche un gruppo piuttosto ampio di persone, alcune delle quali sanno già scrivere codice. Semplicemente, non sai sempre che tipo di qualità avrà quel codice.
Abbiamo pensato di provare ad attirare studenti. Ma gli studenti non parteciperanno a tutto. Faranno solo una parte del lavoro. Per esempio, scriveranno test, correggeranno bug e implementeranno funzionalità che non intaccano la funzionalità principale. La funzionalità principale è la creazione e il ripristino dei backup. Se si verifica un bug nella creazione di un backup, rischiamo di perdere dati. E nessuno lo vuole, ovviamente. Tutti desiderano che tutto sia estremamente affidabile. Pertanto, non vogliamo certamente permettere a codice di cui ci fidiamo meno che del nostro di entrare. Cioè, qualsiasi codice non critico è ciò che ci piacerebbe ricevere dalle nostre risorse aggiuntive.
In quali condizioni viene accettato un PR da uno studente?
- Devono coprire il loro codice con test. Tutto deve passare nel CI.
- E inoltre, dobbiamo passare attraverso 2 revisioni. Una di Andrei Borodin e una mia.
- E per verificare che non rompa nulla nel nostro servizio, carico separatamente una build con questo commit. E controlliamo nei test end-to-end che non ci siano problemi.
Corso speciale su Open Source
Un po' su perché è utile e perché mi sembra un'ottima idea.
Il profitto è ovvio per noi:
- Otteniamo mani in più.
- E cerchiamo candidati nella nostra squadra tra studenti brillanti che scrivono codice di qualità.
Qual è il vantaggio per gli studenti?
Potrebbero non essere così evidenti, perché gli studenti, almeno, non ricevono soldi per il codice che scrivono, ma solo voti nel libretto.
Ho chiesto loro al riguardo. E secondo loro:
- Esperienza come collaboratori in Open Source.
- Aggiungere una voce al CV.
- Mettersi in evidenza e superare il colloquio in Yandex.
- Diventare partecipanti a GSoC.
- +1 corso speciale per chi vuole scrivere codice.
Non parlerò di come è stato strutturato il corso. Dirò solo che WAL-G era il progetto principale. Inoltre, abbiamo incluso progetti come Odyssey, PostgreSQL e ClickHouse in questo corso.
E non abbiamo dato solo compiti in questo corso, ma abbiamo anche rilasciato diplomi e tesi.
E quali sono i vantaggi per gli utenti?
Passiamo alla parte che interessa, piuttosto, a voi. Qual è il vantaggio per voi? Il vantaggio è che gli studenti hanno risolto molti bug. E hanno fatto richieste di funzionalità che ci avete chiesto di implementare.
E ora lasciate che vi parli delle cose che desideravate da tempo e che sono state realizzate.
Supporto per i tablespace. I tablespace in WAL-G erano attesi fin dal rilascio di WAL-G, poiché WAL-G è il successore di un altro strumento di backup, WAL-E, che supportava i backup di database con tablespace.
In breve, ricordiamo di cosa si tratta e a cosa serve. Di solito, tutti i dati di Postgres occupano una singola directory nel file system, che è chiamata base. Questa directory contiene già tutti i file e le sottodirectory necessari a Postgres.
I tablespace sono directory in cui sono archiviati i dati di Postgres, ma non si trovano al di fuori della directory base. Nella slide è evidente che i tablespace si trovano al di fuori della directory base.
Come appare questo per Postgres stesso? Nella directory base c'è una sottodirectory chiamata pg_tblspc. Al suo interno ci sono dei collegamenti simbolici (symlink) alle directory in cui sono realmente archiviati i dati di Postgres al di fuori della directory base.
Quando usate tutto ciò, questi comandi possono apparire in questo modo. Cioè, create una tabella in uno spazio di tabelle specificato e vedete dove si trova attualmente. Queste ultime due righe, gli ultimi comandi richiamati. E lì è visibile un percorso. Ma in realtà, non è un vero percorso. È un percorso con un prefisso dalla directory di base allo spazio delle tabelle. E da lì è abbinato a un symlink che porta ai vostri dati reali.
Noi non utilizziamo tutto questo nel nostro team, ma molti altri utenti di WAL-E ci hanno detto che volevano passare a WAL-G, ma questo era un ostacolo. Ora è supportato.
Un'altra funzione che ci ha portato il nostro corso speciale è il catchup. Di catchup ne sanno quelli che probabilmente hanno lavorato di più con Oracle che con Postgres.
In breve, che cos'è. Una topologia tipica di un cluster nel nostro servizio può apparire in questo modo. Abbiamo un master. C'è una replica che si sincronizza con lui attraverso il write-ahead log. La replica informa il master su quale LSN si trova attualmente. Contemporaneamente, il log può essere archiviato. Inoltre, vengono inviati backup nel cloud, e anche backup incrementali.
Qual è il problema potenziale? Quando avete un database di notevoli dimensioni, può succedere che la replica inizi a distaccarsi significativamente dal master. E si distacca così tanto che non può più recuperare il ritardo. Questo problema di solito deve essere affrontato in qualche modo.
Il modo più semplice è rimuovere la replica e reinstallarla, poiché non potrà mai recuperare il ritardo, e bisogna risolvere il problema. Tuttavia, questo è piuttosto lungo, perché ripristinare un intero backup di un database da 10 TB richiede un tempo molto lungo. Vogliamo farlo il più rapidamente possibile quando si verificano tali problemi. È proprio per questo che esiste il catchup.
Catchup consente di utilizzare i delta backup, che vengono salvati nel cloud in questo modo. Indicate a quale LSN si trova attualmente la replica in ritardo e specificatelo nel comando catchup per creare un delta backup tra quel LSN e l’LSN su cui si trova attualmente il vostro cluster. Successivamente, ripristinate questo backup sulla replica che era in ritardo.
Altre basi
Inoltre, gli studenti ci hanno portato subito molte funzionalità. Poiché noi di Yandex lavoriamo non solo con Postgres, ma abbiamo anche MySQL, MongoDB, Redis, ClickHouse, a un certo punto abbiamo avuto bisogno della possibilità di effettuare backup con il ripristino point-in-time per MySQL e di caricarli nel cloud.
Volevamo farlo in un modo simile a quello di WAL-G. Così abbiamo deciso di sperimentare e vedere come sarebbe stato.
Inizialmente non separando questa logica, abbiamo scritto il codice in un fork. Abbiamo visto che avevamo una sorta di modello funzionante e che poteva decollare. Poi abbiamo pensato che la nostra comunità principale è composta da postgresisti, che usano WAL-G. Pertanto, dovevamo in qualche modo separare queste parti. Cioè, quando si modifica il codice per Postgres, non rompiamo MySQL, e quando modifichiamo MySQL, non rompiamo Postgres.
La prima idea su come separare il tutto è stata quella di utilizzare lo stesso approccio usato nelle estensioni di PostgreSQL. In effetti, per fare un backup di MySQL, è necessario installare una libreria dinamica.
Ma qui è evidente l'asimmetria di questo approccio. Quando esegui un backup di Postgres, installi un normale strumento di backup per Postgres e funziona perfettamente. Per MySQL, invece, finisci per installare uno strumento di backup per Postgres e poi anche una libreria dinamica per MySQL. Sembra un po' strano. Anche noi abbiamo pensato che non fosse la soluzione di cui avevamo bisogno.
Diverse versioni per Postgres, MySQL, MongoDB, Redis
Ma questo ci ha permesso, a nostro avviso, di arrivare alla soluzione corretta: isolare diverse versioni per diversi database. Questo ci permette di isolare la logica legata ai backup di vari database, che si interfacciano con una comune API fornita da WAL-G.
Questa è la parte che abbiamo scritto noi stessi, prima di assegnare i compiti agli studenti. Cioè, è proprio la parte in cui potrebbero fare qualcosa di sbagliato, quindi abbiamo deciso che sarebbe stato meglio fare noi qualcosa di corretto e tutto andrà bene.
Dopo di che abbiamo assegnato dei compiti. Sono stati subito presi. Agli studenti è stato richiesto di supportare tre database.
Si tratta di MySQL, che stiamo eseguendo il backup utilizzando WAL-G in questo modo da oltre un anno.
E ora anche MongoDB si sta avvicinando alla produzione, dove lo stanno rifinendo. In sostanza, abbiamo scritto la struttura per tutto questo. Poi gli studenti hanno sviluppato alcune cose funzionanti. Infine, le portiamo a uno stato che possiamo accettare nella nostra 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 ripristino a un determinato momento e volevamo eseguire il backup nel cloud. Abbiamo quindi chiesto agli studenti di scrivere un codice che risolvesse questo. Gli studenti hanno utilizzato strumenti di backup già esistenti, che in qualche modo creano i backup, e poi hanno unito tutto ciò con WAL-G, che trasferiva il tutto nel cloud. A questo si è aggiunto anche il ripristino a un determinato momento.
Cosa hanno portato anche gli studenti? Hanno aggiunto a WAL-G il supporto per la crittografia Libsodium.
Abbiamo anche introdotto politiche di conservazione dei backup. Ora i backup possono essere contrassegnati come permanenti. Questo rende più facile automatizzare il processo di conservazione per il vostro servizio.
Quali sono i risultati di questo esperimento?
All'inizio, più di 100 persone si erano registrate al corso. Non ho detto inizialmente che l'università di Ekaterinburg è l'Università Federale Uralica. Lì abbiamo fatto tutti gli annunci. 100 persone si sono registrate. In realtà, solo circa 30 hanno iniziato a lavorare seriamente.
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à. E alcuni studenti hanno comunque completato il corso.
Attualmente, per questo corso, gli studenti hanno risolto circa 14 problemi e implementato 10 funzionalità di diversa grandezza. E, a mio avviso, questo è un valido sostituto di uno o due sviluppatori.
Oltre a tutto ciò, abbiamo rilasciato diplomi e lavori di corso. 12 hanno ricevuto diplomi. 6 di loro si sono già laureati con un punteggio di '5'. Gli altri non hanno ancora sostenuto la laurea, ma penso che andrà bene anche per loro.
Piani per il futuro
Quali sono i nostri piani per il futuro?
Almeno quelle richieste di funzionalità che abbiamo già sentito dagli utenti e che vogliamo implementare. Questo include:
- Monitorare l'accuratezza del tracciamento della timeline nell'archivio dei backup del cluster HA. Con WAL-G è possibile farlo. E, penso che avremo studenti pronti ad occuparsene.
- Abbiamo già una persona responsabile per il trasferimento dei backup e del WAL tra le nuvole.
- Recentemente abbiamo pubblicato un'idea su come possiamo ulteriormente accelerare WAL-G attraverso l'estrazione dei backup incrementali senza sovrascrivere le pagine e ottimizzando gli archivi che inviamo.
Puoi condividerli qui
Qual era lo scopo di questa presentazione? Volevamo dire che ora, oltre a noi quattro che supportano il progetto, abbiamo a disposizione molte altre mani. In particolare, se scrivete loro in privato. E se state eseguendo il backup dei vostri dati tramite WAL-G o desiderate migrare a WAL-G, possiamo considerare facilmente le vostre esigenze.
Questo è un codice QR e un link. Puoi usare entrambi per scrivere tutte le tue richieste. Ad esempio, se abbiamo un bug che non stiamo risolvendo. Oppure se c'è una funzione che desideri molto, ma per qualche motivo non è ancora presente in alcun backup, incluso il nostro. Assicurati di scriverlo.
Domande
Ciao! Grazie per la presentazione! Ho una domanda su WAL-G, ma non su Postgres. WAL-G effettua il backup di MySQL e chiama l'extra-backup. Se consideri le installazioni moderne su CentOS e se esegui yum install MySQL, si installerà MariaDB. Dalla versione 10.3, l'extra-backup non è supportato, ma è supportato il backup di MariaDB. Come siete messi a riguardo?
Attualmente non abbiamo tentato di effettuare il backup di MariaDB. Abbiamo ricevuto richieste per il supporto di FoundationDB, ma in generale, se c'è una richiesta del genere, possiamo trovare persone che lo faranno. Non è così lungo e complesso 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, in modo da poter effettuare il backup su nastro?
Si riferisce a un backup su uno storage a nastro, giusto?
Sì.
C'è Andrey Borodin, che può rispondere a questa domanda meglio di me.
(Andrej) Sì, grazie per la domanda! Abbiamo ricevuto una richiesta per il trasferimento di un backup su nastro da un'archiviazione cloud. E per questo la migrazione tra cloud. Perché la migrazione tra cloud è una sorta di versione generalizzata del trasferimento su nastro. Inoltre, abbiamo un'architettura scalabile per quanto riguarda gli Storage. A proposito, molti Storage sono stati scritti da studenti. E se scrivete uno Storage per il nastro, sarà sicuramente supportato. Siamo pronti a considerare pull request. È necessario scrivere un file, leggere un file. Se queste cose vengono fatte in Go, generalmente si traducono in 50 righe di codice. E allora nel WAL-G sarà supportato il nastro.
Grazie per la presentazione! Un processo di sviluppo interessante. Il backup è una parte seria della funzionalità, che deve essere ben coperta da test. Quando avete implementato la funzionalità per i nuovi database, i test sono stati scritti anche da studenti o li avete scritti voi stessi e poi avete dato l'implementazione agli studenti?
I test scritti anche da studenti. Ma gli studenti scrivevano di più per funzionalità come nuove basi. Scrivevano test di integrazione. E scrivevano test unitari. Se i test di integrazione passano, cioè al momento, è uno scenario che esegui a mano o che gestisce cron, ad esempio. Cioè, è uno scenario abbastanza comprensibile.
Gli studenti non hanno molta esperienza. Quanto tempo ci vuole per la revisione?
Sì, la revisione richiede abbastanza tempo. Di solito, quando arrivano diversi autori di commit e dicono, 'Ho fatto questo, ho fatto quello', è necessario riflettere e dedicare almeno mezza giornata per capire ciò che hanno scritto. Perché il codice deve essere letto attentamente. Non hanno superato un colloquio. Non li conosciamo molto bene, quindi ci vuole tempo prezioso.
Grazie per la relazione! In precedenza, Andrey Borodin affermava che archive_command in WAL-G dovrebbe essere chiamato direttamente. Ma nel caso di un cluster patron, abbiamo bisogno di logica aggiuntiva per determinare il nodo da cui inviare i WAL. Come risolvete questo problema da voi?
Qual è il problema che hai qui? Diciamo che hai una replica sincrona da cui stai effettuando un backup? O cos'altro?
(Andrei) Il fatto è che WAL-G è progettato per essere utilizzato senza script shell. Se manca qualcosa, scriviamo la logica che deve essere all'interno di WAL-G. Per quanto riguarda da dove deve avvenire l'archiviazione, riteniamo che debba provenire dal master corrente nel cluster. L'archiviazione dalla replica è una cattiva idea. Ci possono essere vari scenari con problemi, in particolare problemi nell'archiviazione delle timeline e di ulteriori informazioni. Grazie per la domanda!
(Chiarimento: Abbiamo eliminato l'uso di script shell )
Buonasera! Grazie per la presentazione! Sono stato colpito dalla funzionalità catchup di cui hai parlato. Abbiamo riscontrato situazioni in cui la replica rimaneva indietro e non riusciva a recuperare. E non ho trovato una descrizione di questa funzionalità nei documenti di WAL-G.
La funzionalità catchup è apparsa letteralmente verso la fine di gennaio 2020. Potrebbe essere utile lavorare meglio sulla documentazione. La stiamo scrivendo noi stessi e non è che sia scritta in modo superlativo. E forse dovremmo iniziare a chiedere 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 situazioni in cui potessimo verificarlo in un caso reale.
Quando aspettarsi?
Non lo so. Aspettate un mese, lo verificheremo di sicuro.
Fonte: habr.com
