Ti suggerisco di leggere la trascrizione del rapporto di inizio 2020 di Georgy Rylov “WAL-G: nuove opportunità ed espansione della comunità”
I manutentori open source affrontano molte sfide man mano che crescono. Come scrivere sempre più funzionalità richieste, risolvere sempre più problemi e riuscire a visualizzare sempre più richieste pull? Usando WAL-G (strumento di backup per PostgreSQL) come esempio, ti racconterò come abbiamo risolto questi problemi lanciando un corso sullo sviluppo open source all'università, cosa abbiamo ottenuto e dove ci muoveremo dopo.
Ciao di nuovo a tutti! Sono uno sviluppatore Yandex di Ekaterinburg. E oggi parlerò di WAL-G.
Il titolo del rapporto non diceva che si trattava di backup. Qualcuno sa cos'è WAL-G? Oppure lo sanno tutti? Alzi la mano chi non lo sa. Santo cielo, sei arrivato al rapporto e non sai di cosa si tratta.
Lascia che ti dica cosa accadrà oggi. Si dà il caso che il nostro team esegua backup da un bel po' di tempo. E questo è un altro rapporto di una serie in cui parliamo di come archiviamo i dati in modo sicuro, protetto, conveniente ed efficiente.
Nelle serie precedenti c'erano molti resoconti di Andrei Borodin e Vladimir Leskov. Eravamo in molti. E di WAL-G parliamo da molti anni.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Questo rapporto sarà un po' diverso dagli altri in quanto riguardava più la parte tecnica, ma qui parlerò di come abbiamo riscontrato problemi associati alla crescita della comunità. E come ci è venuta una piccola idea che ci aiuta ad affrontare tutto questo.
Alcuni anni fa, WAL-G era un progetto abbastanza piccolo che abbiamo ricevuto da Citus Data. E l'abbiamo appena preso. Ed è stato sviluppato da una persona.
E solo WAL-G non aveva:
- Backup da una replica.
- Non erano presenti backup incrementali.
- Non c'erano backup WAL-Delta.
- E mancava ancora molto.
In questi anni WAL-G è cresciuta molto.
E nel 2020 tutto quanto sopra è già apparso. E a questo si aggiunge ciò che ora abbiamo:
- Più di 1 stelle su GitHub.
- 150 forchette.
- Circa 15 PR aperti.
- E molti altri contributori.
- E questioni aperte tutto il tempo. E questo nonostante il fatto che andiamo lì letteralmente ogni giorno e facciamo qualcosa al riguardo.
E siamo giunti alla conclusione che questo progetto richiede maggiore attenzione, anche quando noi stessi non abbiamo bisogno di implementare nulla per il nostro servizio di database gestiti in Yandex.
E da qualche parte nell'autunno del 2018 ci è venuta in mente un'idea. Di solito il team ha diversi modi per sviluppare alcune funzionalità o correggere bug se non hai abbastanza mani. Ad esempio, puoi assumere un altro sviluppatore e pagarlo. Oppure puoi assumere uno stagista per un po' e pagargli anche un po' di stipendio. Ma c’è ancora un gruppo piuttosto numeroso di persone, alcune delle quali sanno già davvero come scrivere codice. Semplicemente non sempre sai quale sia la qualità del codice.
Ci abbiamo pensato e abbiamo deciso di provare ad attirare gli studenti. Ma gli studenti non parteciperanno a tutto con noi. Faranno solo una parte del lavoro. E, ad esempio, scriveranno test, correggeranno bug, implementeranno funzionalità che non influiscono sulla funzionalità principale. La funzionalità principale è la creazione di backup e il ripristino dei backup. Se commettiamo un errore nella creazione del backup, subiremo una perdita di dati. E nessuno lo vuole, ovviamente. Tutti vogliono che tutto sia molto sicuro. Pertanto, ovviamente, non vogliamo lasciare che il codice di cui ci fidiamo meno del nostro. Cioè, qualsiasi codice non critico è ciò che vorremmo ricevere dai nostri lavoratori aggiuntivi.
A quali condizioni sono accettate le PR degli studenti?
- Sono tenuti a coprire il loro codice con test. Tutto dovrebbe svolgersi in CI.
- E esaminiamo anche 2 recensioni. Uno di Andrey Borodin e uno mio.
- Inoltre, per verificare che ciò non interrompa nulla nel nostro servizio, carico separatamente l'assembly con questo commit. E controlliamo nei test end-to-end che nulla fallisca.
Corso speciale sull'Open Source
Un po 'del motivo per cui è necessario e perché, mi sembra, sia un'idea interessante.
Per noi il profitto è evidente:
- Abbiamo mani extra.
- E stiamo cercando candidati per il team tra studenti intelligenti che scrivono codice intelligente.
Qual è il vantaggio per gli studenti?
Potrebbero essere meno ovvi, perché gli studenti, come minimo, non ricevono denaro per il codice che scrivono, ma ricevono solo voti per i loro risultati studenteschi.
Ho chiesto loro questo. E nelle loro parole:
- Esperienza del contributore in Open Source.
- Ottieni una riga nel tuo CV.
- Mettiti alla prova e supera un colloquio in Yandex.
- Diventa un membro del 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. In questo corso abbiamo incluso anche progetti come Odyssey, PostgreSQL e ClickHouse.
E hanno dato problemi non solo in questo corso, ma hanno anche distribuito diplomi e corsi.
E i vantaggi per gli utenti?
Ora passiamo alla parte che ti interessa di più. A cosa ti serve questo? Il punto è che gli studenti hanno corretto molti bug. E abbiamo realizzato le funzionalità richieste che ci hai chiesto di fare.
E lascia che ti parli delle cose che desideravi da tempo e che sono state realizzate.
Supporto per tablespace. Probabilmente i tablespace in WAL-G erano previsti sin dal rilascio di WAL-G, perché WAL-G è il successore di un altro strumento di backup WAL-E, in cui erano supportati i backup del database con tablespace.
Lascia che ti ricordi brevemente di cosa si tratta e perché è tutto necessario. In genere, tutti i dati Postgres occupano una directory sul file system, chiamata base. E questa directory contiene già tutti i file e le sottodirectory richieste da Postgres.
I tablespace sono directory che contengono dati Postgres, ma non si trovano all'esterno della directory di base. La diapositiva mostra che i tablepac si trovano all'esterno della directory di base.
Che aspetto ha questo per Postgres stesso? C'è una sottodirectory separata pg_tblspc nella directory di base. E contiene collegamenti simbolici a directory che in realtà contengono dati Postgres al di fuori della directory di base.
Quando usi tutto questo, per te questi comandi potrebbero assomigliare a questo. Cioè, crei una tabella in un tablespace specificato e vedi dove si trova ora. Queste sono le ultime due righe, gli ultimi due comandi chiamati. E lì è chiaro che c'è un modo. Ma in realtà, questo non è il vero modo. Questo è il percorso prefissato dalla directory di base al tablespace. E da lì viene abbinato a un collegamento simbolico che porta ai tuoi dati reali.
Non usiamo tutto questo nel nostro team, ma è stato utilizzato da molti altri utenti WAL-E che ci hanno scritto che volevano passare a WAL-G, ma questo li stava fermando. Questo è ora supportato.
Un'altra caratteristica che il nostro corso speciale ci ha portato è il recupero. Le persone che probabilmente hanno lavorato più con Oracle che con Postgres conoscono il recupero.
Brevemente di cosa si tratta. La topologia del cluster nel nostro servizio può solitamente assomigliare a questa. Abbiamo un maestro. Esiste una replica da cui viene trasmesso il registro write-ahead. E la replica dice al master su quale LSN è attualmente attivo. E da qualche parte parallelamente a questo, il registro può essere archiviato. E oltre all'archiviazione del registro, vengono inviati anche i backup nel cloud. E vengono inviati i backup delta.
Quale potrebbe essere il problema? Quando si dispone di un database abbastanza grande, è possibile che la replica inizi a rimanere molto indietro rispetto al master. E lei è così indietro che non riesce mai a raggiungerlo. Di solito questo problema deve essere risolto in qualche modo.
E il modo più semplice è rimuovere la replica e ricaricarla, perché non riuscirà mai a recuperare il ritardo e il problema deve essere risolto. Ma si tratta di un tempo piuttosto lungo, perché il ripristino di un intero backup di database da 10 TB è un tempo molto, molto lungo. E vogliamo fare tutto questo il più rapidamente possibile se dovessero sorgere problemi di questo tipo. Ed è proprio a questo che serve il recupero.
Catchup ti consente di utilizzare i backup delta, che vengono archiviati in questo modo nel cloud. Dici su quale LSN si trova attualmente la replica in ritardo e lo specifichi nel comando catchup per creare un backup delta tra quell'LSN e l'LSN su cui si trova attualmente il tuo cluster. E successivamente ripristini questo backup sulla replica che era in ritardo.
Altre basi
Gli studenti ci hanno anche portato molte funzionalità contemporaneamente. Dato che in Yandex cuciniamo non solo Postgres, abbiamo anche MySQL, MongoDB, Redis, ClickHouse, ad un certo punto dovevamo essere in grado di eseguire backup con ripristino point-in-time per MySQL e in modo che ci fosse l'opportunità di caricare li alla nuvola.
E volevamo farlo in un modo simile a quello che fa WAL-G. E abbiamo deciso di sperimentare e vedere come sarebbe stato il tutto.
E all’inizio, senza condividere in alcun modo questa logica, hanno scritto il codice nel fork. Hanno visto che abbiamo una sorta di modello funzionante e che può volare. Quindi abbiamo pensato che la nostra comunità principale fosse quella dei postgresisti, che usano WAL-G. E quindi dobbiamo in qualche modo separare queste parti. Cioè, quando modifichiamo il codice per Postgres, non rompiamo MySQL; quando modifichiamo MySQL, non rompiamo Postgres.
La prima idea su come separarli è stata l'idea di utilizzare lo stesso approccio utilizzato nelle estensioni PostgreSQL. E, infatti, per fare un backup MySQL dovevi installare una sorta di libreria dinamica.
Ma qui l’asimmetria di questo approccio è immediatamente visibile. Quando esegui il backup di Postgres, ci inserisci un normale backup per Postgres e tutto va bene. E per MySQL risulta che installi un backup per Postgres e installi anche una libreria dinamica per MySQL per esso. Sembra un po' strano. Lo abbiamo pensato anche noi e abbiamo deciso che questa non era la soluzione di cui avevamo bisogno.
Varie build per Postgres, MySQL, MongoDB, Redis
Ma questo ci ha permesso, a nostro avviso, di prendere la decisione giusta: assegnare assemblee diverse per basi diverse. Ciò ha permesso di isolare la logica legata ai backup di diversi database che accederanno all'API comune implementata da WAL-G.
Questa è la parte che abbiamo scritto noi stessi, prima di dare i problemi agli studenti. Cioè, questa è esattamente la parte in cui potrebbero fare qualcosa di sbagliato, quindi abbiamo deciso che sarebbe stato meglio fare qualcosa del genere e tutto andrà bene.
Successivamente abbiamo riscontrato problemi. Sono stati immediatamente smantellati. Gli studenti dovevano supportare tre basi.
Questo è MySQL, di cui eseguiamo il backup in questo modo utilizzando WAL-G da più di un anno.
E ora MongoDB si sta avvicinando alla produzione, dove lo stanno completando con un file. In effetti, abbiamo scritto la struttura per tutto questo. Poi gli studenti hanno scritto alcune cose realizzabili. E poi li portiamo a uno stato che possiamo accettare nella produzione.
Questi problemi non sembravano necessari per gli studenti per scrivere strumenti di backup completi per ciascuno di questi database. Non abbiamo avuto questo problema. Il nostro problema era che volevamo un ripristino point-in-time e volevamo eseguire il backup sul cloud. E hanno chiesto agli studenti di scrivere un codice che risolvesse questo problema. Gli studenti hanno utilizzato strumenti di backup già esistenti, che in qualche modo eseguono i backup, e poi hanno unito il tutto con WAL-G, che ha inoltrato tutto al cloud. E a questo hanno anche aggiunto il recupero puntuale.
Cos’altro hanno portato gli studenti? Hanno portato il supporto della crittografia Libsodium a WAL-G.
Disponiamo anche di politiche di archiviazione di backup. Ora i backup possono essere contrassegnati come permanenti. E in qualche modo è più conveniente per il tuo servizio automatizzare il processo di archiviazione.
Qual è stato il risultato di questo esperimento?
Inizialmente si sono iscritte al corso più di 100 persone. All'inizio non ho detto che l'università di Ekaterinburg è l'Università Federale degli Urali. Abbiamo annunciato tutto lì. 100 persone iscritte. In realtà molte meno persone hanno iniziato a fare qualcosa, circa 30 persone.
Ancora meno persone hanno completato il corso, perché era necessario scrivere dei test per i codici già esistenti. E correggi anche qualche bug o crea qualche funzionalità. E alcuni studenti hanno comunque chiuso il corso.
Attualmente, durante questo corso, gli studenti hanno risolto circa 14 problemi e realizzato 10 funzionalità di varie dimensioni. E, mi sembra, questa è una sostituzione a tutti gli effetti di uno o due sviluppatori.
Tra le altre cose, abbiamo rilasciato diplomi e corsi. E 12 hanno ricevuto diplomi. 6 di loro si sono già difesi al “5”. Quelli che sono rimasti non hanno ancora avuto protezione, ma penso che anche per loro andrà tutto bene.
Progetti per il futuro
Che progetti abbiamo per il futuro?
Almeno quelle richieste di funzionalità che abbiamo già sentito dagli utenti e che vogliamo soddisfare. Questo:
- Monitoraggio della correttezza del monitoraggio della sequenza temporale nell'archivio di backup del cluster HA. Puoi farlo con WAL-G. E penso che avremo studenti che si occuperanno di questa questione.
- Abbiamo già una persona responsabile del trasferimento dei backup e dei WAL tra i cloud.
- E recentemente abbiamo pubblicato l'idea che possiamo velocizzare ulteriormente WAL-G decomprimendo i backup incrementali senza riscrivere le pagine e ottimizzando gli archivi che inviamo lì.
Puoi condividerli qui
A cosa serviva questo rapporto? Inoltre, ora, oltre alle 4 persone che sostengono questo progetto, abbiamo altre mani, e ce ne sono parecchie. Soprattutto se scrivi loro in un messaggio personale. E se esegui il backup dei tuoi dati e lo fai utilizzando WAL-G o desideri passare a WAL-G, allora possiamo soddisfare abbastanza facilmente i tuoi desideri.
Questo è un codice QR e un collegamento. Puoi esaminarli e scrivere tutti i tuoi desideri. Ad esempio, non stiamo risolvendo alcuni bug. Oppure vuoi davvero qualche funzionalità, ma per qualche motivo non è ancora presente in nessun backup, incluso il nostro. Assicurati di scrivere a riguardo.
domande
Ciao! Grazie per la segnalazione! Domanda su WAL-G, ma non su Postgres. WAL-G esegue il backup di MySQL e richiama un backup aggiuntivo. Se prendiamo installazioni moderne su CentOS e se esegui yum install MySQL, verrà installato MariDB. Dalla versione 10.3 il backup aggiuntivo non è supportato, è supportato il backup MariDB. Come va con questo?
Al momento non abbiamo provato a eseguire il backup di MariDB. Abbiamo ricevuto richieste di supporto per FoundationDB, ma in generale, se c'è una richiesta del genere, possiamo trovare persone disposte a farlo. Non è così lungo o difficile come penso.
Buon pomeriggio Grazie per la segnalazione! Domanda su potenziali nuove funzionalità. Sei pronto a far funzionare WAL-G con i nastri in modo da poter eseguire il backup su nastri?
Apparentemente significa backup su storage su nastro?
Sì.
C'è Andrei Borodin, che può rispondere a questa domanda meglio di me.
(Andrey) Sì, grazie per la domanda! Abbiamo ricevuto una richiesta per trasferire un backup su nastro dall'archivio cloud. E per questo trasferimento tra le nuvole. Perché il trasferimento da cloud a cloud è una versione generalizzata del trasferimento su nastro. Inoltre, disponiamo di un'architettura estensibile in termini di storage. A proposito, molti Storoges sono stati scritti da studenti. E se scrivi Archiviazione per nastro, ovviamente sarà supportato. Siamo pronti a considerare le richieste pull. Lì devi scrivere un file, leggere un file. Se fai queste cose in Go, di solito ti ritroverai con 50 righe di codice. E poi il nastro sarà supportato in WAL-G.
Grazie per la segnalazione! Interessante processo di sviluppo. Il backup è una funzionalità seria che dovrebbe essere ben coperta dai test. Quando avete implementato le funzionalità per i nuovi database, anche gli studenti hanno scritto i test oppure siete stati voi a scrivere i test e poi a fornire l'implementazione agli studenti?
Gli studenti hanno anche scritto dei test. Ma gli studenti hanno scritto di più per funzionalità come i nuovi database. Hanno scritto test di integrazione. E hanno scritto test unitari. Se l'integrazione passa, cioè al momento, si tratta di uno script che esegui manualmente o lo fai fare a cron, ad esempio. Cioè, la sceneggiatura è molto chiara.
Gli studenti non hanno molta esperienza. La revisione richiede molto tempo?
Sì, le revisioni richiedono molto tempo. Cioè, di solito, quando diversi committer vengono contemporaneamente e dicono che ho fatto questo, ho fatto quello, allora devi pensare e dedicare circa mezza giornata per capire cosa hanno scritto lì. Perché il codice va letto attentamente. Non hanno avuto un colloquio. Non li conosciamo molto bene, quindi ci vuole molto tempo.
Grazie per la segnalazione! In precedenza, Andrey Borodin aveva affermato che archive_command in WAL-G dovrebbe essere chiamato direttamente. Ma nel caso di una sorta di cartuccia a grappolo, abbiamo bisogno di una logica aggiuntiva per determinare il nodo da cui inviare gli alberi. Come risolvi questo problema da solo?
Qual è il tuo problema qui? Diciamo che hai una replica sincrona con cui stai effettuando il backup? O cosa?
(Andrey) Il fatto è che in effetti WAL-G è pensato per essere utilizzato senza script di shell. Se manca qualcosa, aggiungiamo la logica che dovrebbe essere all'interno di WAL-G. Per quanto riguarda la provenienza dell'archiviazione, riteniamo che l'archiviazione dovrebbe provenire dall'attuale master nel cluster. Archiviare da una replica è una cattiva idea. Esistono vari scenari possibili con problemi. In particolare, problemi con le tempistiche di archiviazione ed eventuali informazioni aggiuntive. Grazie per la domanda!
(Chiarimento: ci siamo sbarazzati degli script di shell )
Buonasera! Grazie per la segnalazione! Mi interessa la funzione di recupero di cui hai parlato. Ci siamo trovati di fronte a una situazione in cui una replica era indietro e non riusciva a raggiungerla. E non ho trovato una descrizione di questa funzionalità nei documenti WAL-G.
Catchup è apparso letteralmente il 20 gennaio 2020. La documentazione potrebbe richiedere ulteriore lavoro. Lo scriviamo noi stessi e non lo scriviamo molto bene. E forse dovremmo iniziare a chiedere agli studenti di scriverlo.
È già stato rilasciato?
La richiesta pull è già morta, cioè l'ho controllata. L'ho provato su un cluster di test. Finora non abbiamo avuto una situazione in cui potessimo testarlo in un esempio di combattimento.
Quando aspettarsi?
Non lo so. Aspetta un mese, controlleremo di sicuro.
Fonte: habr.com