Suosittelen, että luet Georgy Rylovin alkuvuoden 2020 raportin "WAL-G: uudet mahdollisuudet ja yhteisön laajentuminen"
Avoimen lähdekoodin ylläpitäjät kohtaavat monia haasteita kasvaessaan. Kuinka kirjoittaa yhä enemmän vaadittuja ominaisuuksia, korjata yhä enemmän ongelmia ja onnistua katsomaan yhä enemmän vetopyyntöjä? Käytän esimerkkinä WAL-G:tä (PostgreSQL:n varmuuskopiointityökalu) ja kerron kuinka ratkaisimme nämä ongelmat käynnistämällä yliopistossa avoimen lähdekoodin kehityskurssin, mitä saavutimme ja minne siirrymme seuraavaksi.
Hei taas kaikille! Olen Yandex-kehittäjä Jekaterinburgista. Ja tänään puhun WAL-G:stä.
Raportin otsikossa ei sanottu, että se koskisi varmuuskopioita. Tietääkö kukaan mikä on WAL-G? Vai tietääkö kaikki? Nosta kätesi, jos et tiedä. Paska, tulit raporttiin etkä tiedä mistä on kyse.
Kerron teille, mitä tänään tapahtuu. Sattuu niin, että tiimimme on tehnyt varmuuskopioita jo jonkin aikaa. Ja tämä on toinen raportti sarjasta, jossa puhumme siitä, kuinka tallennamme tietoja turvallisesti, turvallisesti, kätevästi ja tehokkaasti.
Edellisessä sarjassa oli monia Andrei Borodinin ja Vladimir Leskovin raportteja. Meitä oli monia. Ja olemme puhuneet WAL-G:stä monta vuotta.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Tämä raportti tulee olemaan hieman erilainen kuin muut siinä mielessä, että se koski enemmän teknistä osaa, mutta tässä puhun siitä, kuinka kohtasimme yhteisön kasvuun liittyviä ongelmia. Ja kuinka saimme pienen idean, joka auttaa meitä selviytymään tästä.
Muutama vuosi sitten WAL-G oli melko pieni projekti, jonka saimme Citus Datalta. Ja me vain otimme sen. Ja sen on kehittänyt yksi henkilö.
Ja vain WAL-G:llä ei ollut:
- Varmuuskopio kopiosta.
- Lisävarmuuskopioita ei ollut.
- WAL-Delta-varmuuskopioita ei ollut.
- Ja vielä puuttui paljon.
Näiden muutaman vuoden aikana WAL-G on kasvanut paljon.
Ja vuoteen 2020 mennessä kaikki edellä mainitut ovat jo ilmestyneet. Ja tähän lisättiin se, mitä meillä nyt on:
- Yli 1 000 tähteä GitHubissa.
- 150 haarukkaa.
- Noin 15 avointa PR:ää.
- Ja monia muita avustajia.
- Ja avoimia asioita koko ajan. Ja tämä huolimatta siitä, että menemme sinne kirjaimellisesti joka päivä ja teemme asialle jotain.
Ja tulimme siihen tulokseen, että tämä projekti vaatii enemmän huomiotamme, vaikka meidän ei itse tarvitsekaan toteuttaa mitään Yandexin Managed Databases -palvelussamme.
Ja jossain syksyllä 2018 mieleemme tuli idea. Yleensä tiimillä on useita tapoja kehittää joitain ominaisuuksia tai korjata vikoja, jos kädet eivät riitä. Voit esimerkiksi palkata toisen kehittäjän ja maksaa hänelle rahaa. Tai voit ottaa jonkin aikaa harjoittelijan ja maksaa hänelle myös palkkaa. Mutta silti on melko suuri joukko ihmisiä, joista osa jo todella osaa kirjoittaa koodia. Et vain aina tiedä, minkä laatuinen koodi on.
Mietimme sitä ja päätimme yrittää houkutella opiskelijoita. Opiskelijat eivät kuitenkaan osallistu kaikkeen kanssamme. He tekevät vain osan työstä. Ja he esimerkiksi kirjoittavat testejä, korjaavat bugeja, toteuttavat ominaisuuksia, jotka eivät vaikuta päätoimintoihin. Päätoiminto on varmuuskopioiden luominen ja varmuuskopioiden palauttaminen. Jos teemme virheen varmuuskopion luomisessa, menetämme tietoja. Ja tätä ei tietenkään kukaan halua. Kaikki haluavat kaiken olevan erittäin turvallista. Siksi emme tietenkään halua antaa koodia, johon luotamme vähemmän kuin omaamme. Toisin sanoen kaikki ei-kriittiset koodit ovat sitä, mitä haluamme saada lisätyöntekijöiltämme.
Millä ehdoilla opiskelija PR hyväksytään?
- Heidän tulee peittää koodinsa testeillä. Kaiken pitäisi tapahtua CI:ssä.
- Käymme myös läpi 2 arvostelua. Yksi Andrei Borodinilta ja toinen minulta.
- Ja lisäksi varmistaakseni, ettei tämä riko mitään palvelussamme, lataan erikseen kokoonpanon tämän sitoumuksen kanssa. Ja tarkistamme päästä päähän -testeissä, ettei mikään epäonnistu.
Avoimen lähdekoodin erikoiskurssi
Hieman siitä, miksi tätä tarvitaan ja miksi tämä on minusta hieno idea.
Meille voitto on ilmeinen:
- Saamme ylimääräisiä käsiä.
- Ja etsimme tiimiin ehdokkaita älykästä koodia kirjoittavien älykkäiden opiskelijoiden joukosta.
Mitä hyötyä siitä on opiskelijoille?
Ne voivat olla vähemmän ilmeisiä, koska opiskelijat eivät ainakaan saa rahaa kirjoittamastaan koodista, vaan saavat vain arvosanoja opiskelijatietueistaan.
Kysyin heiltä tästä. Ja heidän sanoin:
- Avoimen lähdekoodin avustajakokemus.
- Hanki rivi CV:hen.
- Todista itsesi ja läpäise haastattelu Yandexissa.
- Liity GSoC:n jäseneksi.
- +1 erikoiskurssi niille, jotka haluavat kirjoittaa koodia.
En kerro kurssin rakenteesta. Sanon vain, että WAL-G oli pääprojekti. Otimme kurssille mukaan myös sellaisia projekteja kuin Odyssey, PostgreSQL ja ClickHouse.
Ja he antoivat ongelmia paitsi tällä kurssilla, myös antoivat tutkintotodistukset ja kurssitöitä.
Entä käyttäjien hyöty?
Siirrytään nyt siihen osaan, joka kiinnostaa sinua eniten. Mitä hyötyä tästä on sinulle? Pointti on, että opiskelijat korjasivat paljon bugeja. Ja teimme pyyntöominaisuudet, jotka pyysit meitä tekemään.
Ja kerron sinulle asioista, joita olet pitkään halunnut ja jotka on toteutunut.
Pöytätilojen tuki. WAL-G:n taulukkotiloja on odotettu luultavasti WAL-G:n julkaisusta lähtien, koska WAL-G on toisen varmuuskopiointityökalun WAL-E:n seuraaja, jossa tuettiin tietokannan varmuuskopioita taulukkotiloineen.
Muistutan lyhyesti, mitä se on ja miksi sitä kaikkea tarvitaan. Tyypillisesti kaikki Postgres-tietosi ovat tiedostojärjestelmässä yhdessä hakemistossa, jota kutsutaan pohjaksi. Ja tämä hakemisto sisältää jo kaikki Postgresin vaatimat tiedostot ja alihakemistot.
Taulukkotilat ovat hakemistoja, jotka sisältävät Postgres-tietoja, mutta ne eivät sijaitse perushakemiston ulkopuolella. Dia näyttää, että taulukkovälit sijaitsevat perushakemiston ulkopuolella.
Miltä tämä näyttää itse Postgresille? Perushakemistossa on erillinen alihakemisto pg_tblspc. Ja se sisältää symbolilinkkejä hakemistoihin, jotka todella sisältävät Postgres-tietoja perushakemiston ulkopuolella.
Kun käytät tätä kaikkea, nämä komennot voivat näyttää sinulle tältä. Eli luot taulukon johonkin määritettyyn taulukkotilaan ja katsot missä se on nyt. Nämä ovat kaksi viimeistä riviä, joista kaksi viimeistä komentoa kutsutaan. Ja siellä on selvää, että jokin keino on olemassa. Mutta todellisuudessa tämä ei ole oikea tapa. Tämä on etuliitteenä oleva polku perushakemistosta taulukkotilaan. Ja sieltä se yhdistetään symlinkillä, joka johtaa todellisiin tietoihisi.
Emme käytä kaikkea tätä tiimissämme, mutta monet muut WAL-E-käyttäjät käyttivät sitä, jotka kirjoittivat meille haluavansa siirtyä WAL-G:hen, mutta tämä esti heitä. Tämä on nyt tuettu.
Toinen ominaisuus, jonka erikoiskurssimme toi meille, on kiinniotto. Ihmiset, jotka ovat todennäköisesti työskennelleet enemmän Oraclen kuin Postgresin kanssa, tietävät kiinniottamisesta.
Lyhyesti mitä se on. Palvelumme klusteritopologia voi yleensä näyttää suunnilleen tältä. Meillä on mestari. On kopio, joka lähettää siitä eteenpäin kirjoituslokin. Ja replika kertoo isännälle, missä LSN:ssä se on tällä hetkellä. Ja jossain rinnakkain tämän kanssa, loki voidaan arkistoida. Ja lokin arkistoinnin lisäksi varmuuskopiot lähetetään myös pilveen. Ja delta-varmuuskopiot lähetetään.
Mikä voisi olla ongelmana? Kun sinulla on melko suuri tietokanta, voi käydä ilmi, että replikasi alkaa olla paljon jäljessä isännästä. Ja hän on niin paljon jäljessä, ettei hän voi koskaan saada häntä kiinni. Tämä ongelma on yleensä ratkaistava jollakin tavalla.
Ja helpoin tapa on poistaa replika ja ladata se uudelleen, koska se ei tule koskaan kiinni ja ongelma on käsiteltävä. Mutta tämä on melko pitkä aika, koska koko 10 TB:n tietokannan varmuuskopion palauttaminen on erittäin, hyvin pitkä aika. Ja haluamme tehdä kaiken tämän mahdollisimman nopeasti, jos tällaisia ongelmia ilmenee. Ja juuri sitä varten catchup on.
Catchup antaa sinun käyttää delta-varmuuskopioita, jotka tallennetaan pilveen tällä tavalla. Sanot, missä LSN:ssä viivästynyt replika on tällä hetkellä käytössä, ja määrität sen catchup-komennossa, jotta voit luoda delta-varmuuskopion kyseisen LSN:n ja sen LSN:n välille, jossa klusterisi tällä hetkellä sijaitsee. Ja sen jälkeen palautat tämän varmuuskopion jäljennökseen, joka oli jäljessä.
Muut pohjat
Opiskelijat toivat meille myös paljon ominaisuuksia kerralla. Koska Yandexissä ei tee vain Postgresia, meillä on myös MySQL, MongoDB, Redis, ClickHouse, joten jossain vaiheessa meidän piti pystyä tekemään varmuuskopioita MySQL:n ajankohtaisella palautuksella ja jotta olisi mahdollisuus ladata. ne pilveen.
Halusimme tehdä sen samalla tavalla kuin WAL-G. Ja päätimme kokeilla ja katsoa, miltä se kaikki näyttäisi.
Ja aluksi he kirjoittivat koodin haarukkaan jakamatta tätä logiikkaa millään tavalla. He näkivät, että meillä on jonkinlainen toimiva malli ja se osaa lentää. Sitten ajattelimme, että pääyhteisömme on postgresistit, he käyttävät WAL-G:tä. Ja siksi meidän on jotenkin erotettava nämä osat. Eli kun muokkaamme koodia Postgresille, emme riko MySQL:ää; kun muokkaamme MySQL:ää, emme riko Postgresia.
Ensimmäinen ajatus tämän erottamisesta oli ajatus käyttää samaa lähestymistapaa, jota käytetään PostgreSQL-laajennuksissa. Ja itse asiassa MySQL-varmuuskopion tekemiseksi sinun oli asennettava jonkinlainen dynaaminen kirjasto.
Mutta tässä tämän lähestymistavan epäsymmetria näkyy heti. Kun varmuuskopioit Postgresin, laitat siihen tavallisen varmuuskopion Postgresille ja kaikki on kunnossa. Ja MySQL:lle käy ilmi, että asennat varmuuskopion Postgresille ja asennat siihen myös dynaamisen kirjaston MySQL:lle. Kuulostaa jotenkin oudolta. Mekin ajattelimme niin ja päätimme, että tämä ei ollut se ratkaisu, jota tarvitsimme.
Erilaisia koontiversioita Postgresille, MySQL:lle, MongoDB:lle, Redikselle
Mutta tämä antoi meidän mielestämme tehdä oikean päätöksen - allokoida erilaisia kokoonpanoja eri tukikohtiin. Tämä mahdollisti erilaisten tietokantojen varmuuskopioihin sidotun logiikan eristämisen, jotka käyttävät WAL-G:n toteuttamaa yhteistä API:ta.
Tämän osan kirjoitimme itse - ennen kuin annoimme opiskelijoille ongelmat. Eli tämä on juuri se osa, jossa he voivat tehdä jotain väärin, joten päätimme, että meidän on parempi tehdä jotain tällaista, niin kaikki on hyvin.
Sen jälkeen luovutimme ongelmia. Ne purettiin välittömästi. Opiskelijoiden piti tukea kolmea tukikohtaa.
Tämä on MySQL, jota olemme varmuuskopioineet WAL-G:llä tällä tavalla yli vuoden ajan.
Ja nyt MongoDB lähestyy tuotantoa, jossa se viimeistelee tiedostolla. Itse asiassa me kirjoitimme puitteet tälle kaikelle. Sitten opiskelijat kirjoittivat joitain toimivia asioita. Ja sitten saatamme ne sellaiseen tilaan, jonka voimme hyväksyä tuotannossa.
Nämä ongelmat eivät näyttäneet siltä, että opiskelijoiden tarvitsi kirjoittaa täydellisiä varmuuskopiointityökaluja jokaiselle näistä tietokannoista. Meillä ei ollut sellaista ongelmaa. Ongelmamme oli, että halusimme ajankohtaisen palautuksen ja halusimme varmuuskopioida pilveen. Ja he pyysivät oppilaita kirjoittamaan koodin, joka ratkaisisi tämän. Opiskelijat käyttivät jo olemassa olevia varmuuskopiointityökaluja, jotka jotenkin ottavat varmuuskopiot ja liimasivat sen sitten yhteen WAL-G:llä, joka välitti kaiken pilveen. Ja he lisäsivät tähän myös hetkellisen palautuksen.
Mitä muuta opiskelijat toivat? He toivat Libsodium-salaustuen WAL-G:lle.
Meillä on myös varmuuskopiointikäytännöt. Nyt varmuuskopiot voidaan merkitä pysyviksi. Ja jotenkin palvelullesi on kätevämpää automatisoida niiden tallennusprosessi.
Mikä oli tämän kokeilun tulos?
Aluksi kurssille ilmoittautui yli 100 henkilöä. Aluksi en sanonut, että Jekaterinburgin yliopisto on Uralin liittovaltion yliopisto. Ilmoitimme siellä kaiken. 100 ilmoittautunutta. Todellisuudessa paljon harvemmat ihmiset alkoivat tehdä jotain, noin 30 henkilöä.
Kurssin suoritti vielä vähemmän ihmisiä, koska jo olemassa oleville koodeille piti kirjoittaa testejä. Ja myös korjaa jokin bugi tai tee jokin ominaisuus. Ja jotkut opiskelijat sulkivat silti kurssin.
Tällä hetkellä tämän kurssin aikana opiskelijat ovat korjanneet noin 14 ongelmaa ja tehneet 10 erikokoista ominaisuutta. Ja minusta näyttää, että tämä on yhden tai kahden kehittäjän täysimittainen korvaaminen.
Annoimme muun muassa tutkintotodistukset ja kurssitöitä. Ja 12 sai diplomin. 6 heistä on jo puolustanut itseään arvolla "5". Jäljelle jääneillä ei vielä ollut suojaa, mutta uskon, että myös heille kaikki järjestyy.
Tulevaisuuden suunnitelmat
Mitä suunnitelmia meillä on tulevaisuuden varalle?
Ainakin ne ominaisuuspyynnöt, jotka olemme jo kuulleet käyttäjiltä ja haluamme tehdä. Tämä:
- Aikajanan seurannan oikeellisuuden valvonta HA-klusterin varmuuskopioarkistossa. Voit tehdä tämän WAL-G:llä. Ja uskon, että meillä on opiskelijoita, jotka ottavat tämän asian esille.
- Meillä on jo henkilö, joka vastaa varmuuskopioiden ja WAL:n siirtämisestä pilvien välillä.
- Ja julkaisimme äskettäin idean, jonka mukaan voimme nopeuttaa WAL-G:tä entisestään purkamalla varmuuskopiot uudelleen kirjoittamatta sivuja ja optimoimalla sinne lähetettäviä arkistoja.
Voit jakaa ne täällä
Mitä varten tämä raportti oli? Lisäksi nyt, 4 henkilöä, jotka tukevat tätä projektia, meillä on lisäkäsiä, joita on melko paljon. Varsinkin jos kirjoitat heille henkilökohtaisesti. Ja jos varmuuskopioit tietosi ja teet sen WAL-G:llä tai haluat siirtyä WAL-G:hen, voimme helposti toteuttaa toiveesi.
Tämä on QR-koodi ja linkki. Voit käydä ne läpi ja kirjoittaa kaikki toiveesi. Emme esimerkiksi korjaa joitain virheitä. Tai haluat todella jonkin ominaisuuden, mutta jostain syystä sitä ei ole vielä missään varmuuskopiossa, ei myöskään meillä. Muista kirjoittaa tästä.
kysymykset
Hei! Kiitos raportista! Kysymys WAL-G:stä, mutta ei Postgresista. WAL-G varmuuskopioi MySQL:n ja kutsuu ylimääräisen varmuuskopion. Jos otamme nykyaikaiset asennukset CentOS:ään ja jos asennat MySQL:n, MariDB asennetaan. Versiosta 10.3 alkaen ylimääräistä varmuuskopiointia ei tueta, MariDB-varmuuskopiointia tuetaan. Kuinka voit tämän kanssa?
Tällä hetkellä emme ole yrittäneet varmuuskopioida MariDB:tä. Meillä on ollut FoundationDB-tukea koskevia pyyntöjä, mutta yleensä, jos sellainen pyyntö on, voimme löytää ihmisiä, jotka tekevät sen. Se ei ole niin pitkä tai vaikea kuin luulen.
Hyvää iltapäivää Kiitos raportista! Kysymys mahdollisista uusista ominaisuuksista. Oletko valmis saamaan WAL-G:n toimimaan nauhoilla, jotta voit varmuuskopioida nauhoille?
Varmuuskopiointi nauhatallennustilaan ilmeisesti tarkoittaa?
Kyllä.
On Andrei Borodin, joka osaa vastata tähän kysymykseen paremmin kuin minä.
(Andrey) Kyllä, kiitos kysymyksestä! Meillä oli pyyntö siirtää varmuuskopio nauhalle pilvitallennustilasta. Ja tätä varten siirto pilvien välillä. Koska pilvestä pilveen siirto on yleistetty versio nauhasiirrosta. Lisäksi meillä on laajennettava arkkitehtuuri varastojen suhteen. Muuten, monet Storoges ovat opiskelijoiden kirjoittamia. Ja jos kirjoitat Tallennus nauhalle, sitä tietysti tuetaan. Olemme valmiita harkitsemaan vetopyyntöjä. Siellä sinun täytyy kirjoittaa tiedosto, lukea tiedosto. Jos teet nämä asiat Gossa, saat yleensä 50 riviä koodia. Ja sitten nauhaa tuetaan WAL-G:ssä.
Kiitos raportista! Mielenkiintoinen kehitysprosessi. Varmuuskopiointi on vakava toiminnallisuus, joka tulisi testata hyvin. Kun toteutit toiminnallisuutta uusille tietokantoille, kirjoittivatko opiskelijat myös testit vai kirjoititko testit itse ja annoit sitten toteutuksen opiskelijoille?
Oppilaat kirjoittivat myös kokeita. Mutta opiskelijat kirjoittivat enemmän ominaisuuksista, kuten uusista tietokannoista. He kirjoittivat integraatiotestejä. Ja he kirjoittivat yksikkötestejä. Jos integraatio menee läpi, eli tällä hetkellä, kyseessä on käsin suoritettava komentosarja tai esimerkiksi cron tekee sen. Eli käsikirjoitus on hyvin selkeä.
Opiskelijoilla ei ole paljoa kokemusta. Viekö tarkastelu paljon aikaa?
Kyllä, arvostelut vievät melko paljon aikaa. Eli yleensä, kun useat sitoutujat tulevat yhtä aikaa ja sanovat, että minä tein tämän, tein tuon, sinun täytyy ajatella ja varata noin puoli päivää selvittääksesi, mitä he kirjoittivat sinne. Koska koodi on luettava huolellisesti. Heillä ei ollut haastattelua. Emme tunne heitä kovin hyvin, joten se vie paljon aikaa.
Kiitos raportista! Aikaisemmin Andrey Borodin totesi, että WAL-G:ssä archive_command tulisi kutsua suoraan. Mutta jonkinlaisen klusterikasetin tapauksessa tarvitsemme lisälogiikkaa määrittääksemme solmun, josta akselit lähetetään. Miten ratkaiset tämän ongelman itse?
Mikä tässä on ongelmasi? Oletetaan, että sinulla on synkroninen kopio, josta teet varmuuskopion? Tai mitä?
(Andrey) Tosiasia on, että WAL-G on todellakin tarkoitettu käytettäväksi ilman shell-skriptejä. Jos jotain puuttuu, niin lisätään logiikka, jonka pitäisi olla WAL-G:n sisällä. Mitä tulee siitä, mistä arkistoinnin pitäisi tulla, uskomme, että arkistoinnin tulisi tapahtua klusterin nykyiseltä isännältä. Arkistointi kopiosta on huono idea. Ongelmiin liittyy useita mahdollisia skenaarioita. Erityisesti ongelmat aikataulujen ja muiden tietojen arkistointiin. Kiitos kysymyksestä!
(Selvennys: Pääsimme eroon shell-skripteistä )
Hyvää iltaa! Kiitos raportista! Olen kiinnostunut kiinniottoominaisuudesta, josta puhuit. Edessämme oli tilanne, jossa jäljennös oli takana eikä voinut saada kiinni. En löytänyt kuvausta tästä ominaisuudesta WAL-G-asiakirjoista.
Catchup ilmestyi kirjaimellisesti 20. tammikuuta 2020. Dokumentointi saattaa vaatia lisää työtä. Kirjoitamme sen itse, emmekä kirjoita sitä kovin hyvin. Ja ehkä meidän pitäisi alkaa vaatia opiskelijoita kirjoittamaan se.
Onko se jo julkaistu?
Vetopyyntö on jo kuollut, eli tarkistin sen. Kokeilin tätä testiklusterissa. Toistaiseksi meillä ei ole ollut tilannetta, jossa voisimme testata tätä taisteluesimerkissä.
Milloin odottaa?
Minä en tiedä. Odota kuukausi, niin tarkistetaan.
Lähde: will.com