Rezervoj de WAL-G. Kio estas tie en 2019? Andrej Borodin

Mi sugestas vin legi la transskribon de la raporto de la komenco de 2019 de Andrey Borodin "Sekurkopioj kun WAL-G. Kio estas en 2019?"

Saluton al ĉiuj! Mia nomo estas Andrej Borodin. Mi estas programisto ĉe Yandex. Mi interesiĝas pri PostgreSQL ekde 2016, post kiam mi parolis kun la programistoj kaj ili diris, ke ĉio estas simpla - vi prenas la fontkodon kaj konstruas ĝin, kaj ĉio funkcios. Kaj ekde tiam mi ne povas ĉesi - mi skribas ĉiajn diversajn aferojn.

Unu el la aferoj pri kiuj mi laboras estas rezerva sistemo. WAL-G. Ĝenerale, ĉe Yandex ni laboras pri rezervaj sistemoj en PostgreSQL dum tre longa tempo. Kaj vi povas trovi en la Interreto serion de ses raportoj pri kiel ni faras rezervajn sistemojn. Kaj ĉiujare ili iom evoluas, iom evoluas kaj fariĝas pli fidindaj.

Sed hodiaŭ la raporto temas ne nur pri tio, kion ni faris, sed ankaŭ pri kiom simpla ĝi estas kaj kio estas. Kiom el vi jam spektis miajn raportojn pri WAL-G? Estas bone, ke sufiĉe multaj homoj ne spektis, ĉar mi komencos per la plej simpla afero.

Se subite vi havas PostgreSQL-grupon, kaj mi pensas, ke ĉiuj havas kelkajn el ili kun ili, kaj subite ankoraŭ ne ekzistas rezerva sistemo, tiam vi devas akiri ajnan stokadon de S3 aŭ Google Cloud-kongruan stokadon.

Ekzemple, vi povas veni al nia stando kaj preni reklaman kodon por Yandex Object Storage, kiu estas kongrua kun S3.

Poste kreu Sitelon. Ĝi estas nur ujo por informoj.

Kreu servan uzanton.

Kreu alirŝlosilon por la servouzanto: aws-s3-key.

Elŝutu la plej novan stabilan eldonon de WAL-G.

Kiel niaj antaŭ-eldonoj diferencas de eldonoj? Ofte oni petas min liberigi frue. Kaj se ne ekzistas cimo en la versio dum sufiĉa tempo, ekzemple, monato, tiam mi liberigas ĝin. Jen ĉi tiu eldono de novembro. Kaj ĉi tio signifas, ke ĉiumonate ni trovis ian cimon, kutime en nekritika funkcio, sed ni ankoraŭ ne publikigis eldonon. La antaŭa versio estas nur novembro. Ne estas cimoj konataj de ni en ĝi, t.e. cimoj estis aldonitaj dum la projekto progresis.

Post kiam vi elŝutis WAL-G, vi povas ruli simplan "rezervliston" komandon, pasigante la mediajn variablojn. Kaj ĝi konektos al Object Storage kaj diros al vi kiajn sekurkopiojn vi havas. Komence, kompreneble, vi ne devus havi sekurkopiojn. La celo de ĉi tiu diapozitivo estas montri, ke ĉio estas sufiĉe simpla. Ĉi tio estas konzola komando, kiu akceptas mediovariablojn kaj efektivigas subkomandojn.

Post ĉi tio, vi povas fari vian unuan sekurkopion. Diru "backup-push" en WAL-G kaj specifu en WAL-G la pgdata loko de via areto. Kaj plej verŝajne, PostgreSQL diros al vi, se vi ne jam havas rezervan sistemon, ke vi devas ebligi "arkivo-reĝimon".

Ĉi tio signifas, ke vi devas iri al agordoj kaj ŝalti "archive_mode = on" kaj aldoni "archive_command", kiu ankaŭ estas subkomando en WAL-G. Sed ial homoj ofte uzas barskriptojn pri ĉi tiu temo kaj envolvas ĝin ĉirkaŭ WAL-G. Bonvolu ne fari ĉi tion. Uzu la funkciojn trovitajn en WAL-G. Se io mankas al vi, skribu al GitHub. WAL-G supozas, ke ĝi estas la nura programo, kiu funkcias en archive_command.

Ni uzas WAL-G ĉefe por krei Alta Haveblecon en administrado de Yandex Database.

Kaj ĝi estas kutime uzata en topologio de unu Majstro kaj pluraj reproduktaĵoj. Samtempe ĝi faras rezervan kopion en Yandex Object Storage.

La plej oftaj scenaroj estas kreado de kopioj de areto per Punkta tempo-reakiro. Sed en ĉi tiu kazo, la agado de la rezerva sistemo ne estas tiel grava por ni. Ni nur bezonas alŝuti novan areton de la sekurkopio.

Tipe, ni bezonas rezervan sisteman rendimenton kiam oni aldonas novan nodon. Kial ĝi estas grava? Tipe homoj aldonas novan nodon al areto ĉar la ekzistanta areto ne povas pritrakti la legan ŝarĝon. Ili devas aldoni novan kopion. Se ni aldonas la ŝarĝon de pg_basebackup al la Majstro, tiam la Majstro povas kolapsi. Tial, estis tre grave por ni, ke ni povus rapide alŝuti novan nodon el la arkivo, kreante minimuman ŝarĝon sur la Majstro.

Kaj alia simila situacio. Ĉi tio estas la bezono rekomenci la malnovan Majstron post ŝanĝi la Cluster Master de la Datuma Centro kun kiu la konektebleco estis perdita.

• Kiel rezulto, formulante la postulojn por la kopisistemo, ni rimarkis, ke pg_basebackup ne taŭgas por ni kiam funkcias en la nubo.
• Ni volis povi kunpremi niajn datumojn. Sed preskaŭ ajna rezerva sistemo krom tio, kio venas en la skatolo, provizos datumkunpremadon.
• Ni volis paraleligi ĉion ĉar uzanto en la nubo aĉetas grandan nombron da procesoraj kernoj. Sed se ni ne havas paralelecon en iu operacio, tiam granda nombro da kernoj fariĝas senutila.
• Ni bezonas ĉifradon ĉar ofte la datumoj ne estas niaj kaj ne povas esti konservitaj en klara teksto. Cetere, nia kontribuo al WAL-G komenciĝis per ĉifrado. Ni kompletigis la ĉifradon en WAL-G, post kio oni demandis nin: "Eble unu el ni disvolvos la projekton?" Kaj ekde tiam mi laboras kun WAL-G pli ol unu jaron.
• Ni ankaŭ bezonis resursan streĉon, ĉar kun la tempo uzante la nubon, ni eksciis, ke foje homoj havas gravan nutraĵŝarĝon nokte kaj ĉi tiun ŝarĝon ne povas esti malhelpita. Tial ni aldonis rimedon-streĉon.
• Same kiel listigo kaj administrado.
• Kaj konfirmo.

Ni rigardis multajn malsamajn ilojn. Feliĉe, ni havas grandegan elekton en PostgreSQL. Kaj ĉie mankis al ni io, iu malgranda funkcio, iu malgranda funkcio.

Kaj ekzameninte la ekzistantajn sistemojn, ni alvenis al la konkludo, ke ni disvolvos WAL-G. Estis nova projekto tiam. Estis sufiĉe facile influi la evoluon al la nuba infrastrukturo de la rezerva sistemo.

La ĉefa ideologio, al kiu ni aliĝas, estas, ke WAL-G estu tiel simpla kiel balalajko.

WAL-G havas 4 komandojn. Ĉi tio:

WAL-PUSH - arkivu la ŝakton.

WAL-FETCH – akiri ŝakton.

BACKUP-PUSH - fari sekurkopion.

BACKUP-FETCH - akiru sekurkopion de la rezerva sistemo.

Fakte, WAL-G ankaŭ havas administradon de ĉi tiuj sekurkopioj, t.e. listigante kaj forigante rekordojn kaj sekurkopiojn en la historio, kiuj ne plu bezonas nuntempe.

Unu el la gravaj funkcioj por ni estas la funkcio krei deltajn kopiojn.

Delta kopioj signifas, ke ni ne kreas plenan sekurkopion de la tuta areto, sed nur la ŝanĝitajn paĝojn de la ŝanĝitaj dosieroj en la areto. Ŝajnus, ke funkcie ĉi tio tre similas al la kapablo rekuperi uzante WAL. Sed ni povas ruliĝi WAL-unu-fadenan deltan sekurkopion paralele. Sekve, kiam ni havas bazan sekurkopion faritan sabate, deltaj sekurkopioj ĉiutage, kaj ĵaŭde ni malsukcesas, tiam ni devas kunigi 4 deltajn sekurkopiojn kaj 10 horojn da WAL. Ĝi daŭros proksimume la saman tempon ĉar la deltaj sekurkopioj ruliĝas paralele.

LSN-bazitaj deltoj - tio signifas, ke kreante sekurkopion, ni devos kombini ĉiun paĝon kaj kontroli ĝian LSN kun la LSN de la antaŭa sekurkopio por kompreni, ke ĝi ŝanĝiĝis. Ajna paĝo, kiu eble povus enhavi ŝanĝitajn datumojn, devus ĉeesti en la delta sekurkopio.

Kiel mi diris, oni multe atentis paralelecon.

Sed la arkiva API en PostgreSQL estas konsekvenca. PostgreSQL arkivas unu WAL-dosieron kaj dum ĝi restarigo petas unu WAL-dosieron. Sed kiam la datumbazo petas unu WAL-dosieron uzante la komandon "WAL-FETCH", ni nomas la komandon "WAL-PREFETCH", kiu preparas la sekvajn 8 dosierojn por preni datumojn de la objektobutiko paralele.

Kaj kiam la datumbazo petas nin arkivi unu dosieron, ni rigardas archive_status kaj vidas ĉu ekzistas aliaj WAL-dosieroj. Kaj ni ankaŭ provas elŝuti WAL paralele. Ĉi tio disponigas signifan rendimentan gajnon kaj signife reduktas la distancon en la nombro da nearkivitaj WALoj. Multaj rezervaj sistemprogramistoj kredas, ke ĉi tio estas tia riska sistemo ĉar ni fidas je nia scio pri la internoj de kodo, kiu ne estas la PostgreSQL-API. PostgreSQL ne garantias la ĉeeston de la dosierujo archive_status por ni kaj ne garantias la semantikon, la ĉeeston de pretaj signaloj por WAL-dosieroj tie. Tamen ni studas la fontkodon, ni vidas, ke tiel estas kaj ni provas ekspluati ĝin. Kaj ni kontrolas la direkton en kiu PostgreSQL disvolviĝas; se subite ĉi tiu mekanismo rompiĝos, ni ĉesos uzi ĝin.

En ĝia pura formo, LSN-bazita WAL-delto postulas legi ajnan grapoldosieron kies reĝimtempo en la dosiersistemo ŝanĝiĝis ekde la antaŭa sekurkopio. Ni vivis kun ĉi tio longe, preskaŭ unu jaron. Kaj finfine ni alvenis al la konkludo, ke ni havas WAL-deltojn.

Ĉi tio signifas, ke ĉiufoje kiam ni arkivas WAL sur la Majstro, ni ne nur kunpremas ĝin, ĉifras ĝin kaj sendas ĝin al la reto, sed ni ankaŭ legas ĝin samtempe. Ni analizas kaj legas la rekordojn en ĝi. Ni komprenas, kiuj blokoj ŝanĝiĝis kaj kolektas deltajn dosierojn.

Delta dosiero priskribas certan gamon da WAL-dosieroj, priskribas informojn pri kiuj blokoj estis ŝanĝitaj en ĉi tiu gamo de WAL. Kaj tiam ĉi tiuj deltaj dosieroj ankaŭ estas arkivitaj.

Ĉi tie ni alfrontas la fakton, ke ni sufiĉe rapide paraleligis ĉion, sed ni ne povas paralele legi sinsekvan historion, ĉar en certa segmento ni povas renkonti la finon de la antaŭa WAL-rekordo, al kiu ni ankoraŭ havas nenion por konekti, ĉar paralela legado kondukis al tio, ke ni unue analizas la estontecon, kiu ankoraŭ ne havas pasintecon.

Rezulte, ni devis meti nekompreneblajn pecojn en _delta_partajn dosierojn. Kiel rezulto, kiam ni revenos al la pasinteco, ni gluos la pecojn de la WAL-rekordo en unu, post tio ni analizos ĝin kaj komprenos kio ŝanĝiĝis en ĝi.

Se en la historio de nia ŝafta analizo estas almenaŭ unu punkto, kie ni ne komprenas, kio okazis, tiam, sekve, dum la sekva sekurkopio ni estos devigitaj legi la tutan areton denove, same kiel ni faris kun regula LSN. -bazita delto.

Kiel rezulto, nia tuta sufero kondukis al la fakto, ke ni malfermfonte la analiza biblioteko de WAL-G. Laŭ mia scio, neniu ankoraŭ uzas ĝin, sed se iu volas, skribi kaj uzi ĝin, ĝi estas en la publika domeno. (Ĝisdatigita ligilo https://github.com/wal-g/wal-g/tree/master/internal/walparser)

Rezulte, ĉiuj informaj fluoj aspektas sufiĉe komplikaj. Nia Majstro arkivas la ŝakton kaj arkivas deltajn dosierojn. Kaj la kopio, kiu faras la rezervan kopion, devas ricevi deltajn dosierojn dum la tempo, kiu pasis inter sekurkopioj. En ĉi tiu kazo, partoj de la historio devos esti aldonitaj amase kaj analizitaj, ĉar ne la tuta historio konvenas en grandajn segmentojn. Kaj nur post tio la kopio povas arkivi plenan deltan sekurkopion.

Sur la grafikaĵoj ĉio aspektas multe pli simpla. Ĉi tio estas elŝuto de unu el niaj veraj aretoj. Ni havas LSN-bazita, farita en unu tago. Kaj ni vidas, ke la delta sekurkopio bazita en LSN funkciis de la tria matene ĝis la kvina matene. Ĉi tio estas la ŝarĝo en la nombro da procesoraj kernoj. WAL-delta daŭris al ni ĉirkaŭ 20 minutojn ĉi tie, tio estas, ĝi fariĝis signife pli rapida, sed samtempe estis pli intensa interŝanĝo tra la reto.

Ĉar ni havas informojn pri kiuj blokoj ŝanĝiĝis kaj je kiu tempo en la historio de la datumbazo, ni iris plu kaj decidis integri funkciecon - PostgreSQL-etendo nomata "pg_prefaulter"

Ĉi tio signifas, ke kiam la stand-by-bazo efektivigas la restarigi komandon, ĝi diras al WAL-G alporti la sekvan WAL-dosieron. Ni komprenas proksimume kiujn datumajn blokojn aliros la procezo de reakiro de WAL en proksima estonteco kaj komencos legan operacion sur ĉi tiuj blokoj. Ĉi tio estis farita por pliigi la agadon de SSD-regiloj. Ĉar la WAL-rulo atingos la paĝon, kiun oni devas ŝanĝi. Ĉi tiu paĝo estas sur disko kaj ne estas en la paĝa kaŝmemoro. Kaj li atendos sinkrone la alvenon de ĉi tiu paĝo. Sed proksime estas WAL-G, kiu scias, ke en la venontaj centoj da megabajtoj de WAL ni bezonos iujn paĝojn kaj samtempe komencas varmigi ilin. Iniciatas multoblajn diskalirojn tiel ke ili estas ekzekutitaj paralele. Ĉi tio funkcias bone sur SSD-diskoj, sed, bedaŭrinde, ĝi absolute ne aplikeblas por malmola disko, ĉar ni nur malhelpas ĝin per niaj asignoj.

Jen kio nun estas en la kodo.

Estas funkcioj, kiujn ni ŝatus aldoni.

Ĉi tiu bildo montras, ke WAL-delta daŭras relative mallongan tempon. Kaj ĉi tio legas la ŝanĝojn, kiuj okazis en la datumbazo dum la tago. Ni povus fari WAL-delta ne nur nokte, ĉar ĝi ne plu estas grava fonto de ŝarĝo. Ni povas legi WAL-delta ĉiuminute ĉar ĝi estas malmultekosta. En unu minuto ni povas skani ĉiujn ŝanĝojn, kiuj okazis al la cluster. Kaj ĉi tio povus esti nomita "tuja WAL-delta".

La punkto estas, ke kiam ni restarigas la areton, ni reduktas la nombron da rakontoj, kiujn ni devas kunigi sinsekve. Tio estas, la kvanto de WAL, kiun PostgreSQL ruliĝas, devus esti reduktita, ĉar ĝi prenas gravan tempon.

Sed tio ne estas ĉio. Se ni scias, ke iu bloko estos ŝanĝita ĝis rezerva konsistenco, ni ne povas ŝanĝi ĝin en la pasinteco. Tio estas, nun ni havas dosier-post-dosieran optimumigon de WAL-delta plusendado. Ĉi tio signifas, ke se, ekzemple, marde iu tabelo estis tute forigita aŭ iuj dosieroj estis tute forigitaj de la tabelo, tiam kiam delto ruliĝas lunde kaj la pg_basebackup de sabato estas restarigita, ni eĉ ne kreos ĉi tiujn datumojn.

Ni volas etendi ĉi tiun teknologion al la paĝa nivelo. Tio estas, se iu parto de la dosiero ŝanĝas lunde, sed estos anstataŭita merkrede, tiam dum restarigo al punkto ĵaŭde, ni ne bezonas skribi la unuajn versiojn de paĝoj al disko.

Sed ĉi tio ankoraŭ estas ideo, kiun oni aktive diskutas en ni, sed ĝi ankoraŭ ne atingis la kodon.

Ni volas fari unu plian funkcion en WAL-G. Ni volas igi ĝin etendebla ĉar ni bezonas subteni malsamajn datumbazojn kaj ŝatus povi alproksimiĝi al rezerva administrado de la sama maniero. Sed la problemo estas, ke la MySQL-APIoj estas radikale malsamaj. En MySQL, PITR baziĝas ne sur la fizika WAL-protokolo, sed sur la binlog. Kaj ni ne havas arkivan sistemon en MySQL, kiu dirus al iu ekstera sistemo, ke ĉi tiu binlog estas finita kaj devas esti arkivita. Ni devas stari ie en cron kun la datumbazo kaj kontroli ĉu estas io preta?

Kaj same, dum restarigo de MySQL, ne ekzistas restariga komando, kiu povus diri al la sistemo, ke mi bezonas tiajn kaj tiajn dosierojn. Antaŭ ol vi komencas rekonstrui vian areton, vi devas scii kiajn dosierojn vi bezonos. Vi mem devas diveni kiajn dosierojn vi bezonos. Sed ĉi tiuj problemoj povas esti iel evitindaj. (Klarigo: MySQL jam estas subtenata)

En la raporto mi ankaŭ volis paroli pri tiuj kazoj, kiam WAL-G ne taŭgas por vi.

Se vi ne havas sinkronan kopion, WAL-G ne garantias, ke la lasta segmento estos konservita. Kaj se arkivado restas malantaŭ la lastaj kelkaj segmentoj de la historio, tio estas risko. Se ne ekzistas sinkrona kopio, mi ne rekomendus uzi WAL-G. Tamen, ĝi estas ĉefe desegnita por nuba instalado, kio implicas solvon de Alta Havebleco kun sinkrona kopio, kiu respondecas pri la sekureco de la lastaj bajtoj faritaj.

Mi ofte vidas homojn provas kuri kaj WAL-G kaj WAL-E samtempe. Ni subtenas malantaŭan kongruecon en la senco, ke WAL-G povas restarigi dosieron de WAL-E kaj povas restarigi sekurkopion faritan en WAL-E. Sed ĉar ambaŭ ĉi tiuj sistemoj uzas paralelan wal-push, ili komencas ŝteli dosierojn unu de la alia. Se ni fiksas ĝin en WAL-G, ĝi ankoraŭ restos en WAL-E. En WAL-E, ĝi rigardas arkivan staton, vidas la finitajn dosierojn kaj arkivas ilin, dum aliaj sistemoj simple ne scios, ke ĉi tiu WAL-dosiero ekzistis, ĉar PostgreSQL ne provos arkivi ĝin duan fojon.

Kion ni riparos ĉi tie ĉe la flanko de WAL-G? Ni ne informos PostgreSQL, ke ĉi tiu dosiero estis translokigita paralele, kaj kiam PostgreSQL petos nin arkivi ĝin, ni jam scios, ke tia dosiero kun ĉi tiu reĝimo-tempo kaj kun ĉi tiu md5 jam estas arkivita kaj ni simple diros PostgreSQL - Bone, ĉio estas preta sen fari ion ajn.

Sed ĉi tiu problemo verŝajne ne estos riparita ĉe la flanko de WAL-E, do nuntempe estas neeble krei arkivan komandon kiu arkivos la dosieron en kaj WAL-G kaj WAL-E.

Krome, estas kazoj kie WAL-G ne taŭgas por vi nun, sed ni certe riparos ĝin.

Unue, ni nuntempe ne havas enkonstruitan rezervan konfirmon. Ni ne havas konfirmon aŭ dum sekurkopio aŭ reakiro. Kompreneble, ĉi tio estas efektivigita en la nubo. Sed ĉi tio estas efektivigita simple per antaŭkontrolado, simple restarigante la areton. Mi ŝatus doni ĉi tiun funkcion al uzantoj. Sed per konfirmo, mi supozas, ke en WAL-G eblos restarigi la areton kaj komenci ĝin, kaj ruli fumtestojn: pg_dumpall al /dev/null kaj amcheck index-kontrolo.

Nuntempe en WAL-G ne ekzistas maniero prokrasti unu sekurkopion de WAL. Tio estas, ni subtenas iun fenestron. Ekzemple, konservante la lastajn sep tagojn, stokante la lastajn dek sekurkopiojn, stokante la lastajn tri plenajn sekurkopiojn. Tre ofte homoj venas kaj diras: "Ni bezonas sekurkopion de tio, kio okazis en Novjaro kaj ni volas konservi ĝin por ĉiam." WAL-G ankoraŭ ne povas fari tion. (Noto - Ĉi tio jam estis riparita. Legu pli - Sekurkopio-marko opcio en https://github.com/wal-g/wal-g/blob/master/PostgreSQL.md)

Kaj ni ne havas paĝajn kontrolsumojn kaj integrecajn kontrolojn por ĉiuj ŝaftaj segmentoj dum validado de PITR.

El ĉio ĉi mi kunmetis projekton por Google Summer of Code. Se vi konas inteligentajn studentojn, kiuj ŝatus skribi ion en Go kaj akiri plurajn milojn da dolaroj de unu kompanio kun la litero "G", tiam rekomendu nian projekton al ili. Mi agos kiel mentoro por ĉi tiu projekto, ili povas fari ĝin. Se ne estas studentoj, tiam mi prenos ĝin kaj faros ĝin mem somere.

Kaj ni havas multajn aliajn malgrandajn problemojn, pri kiuj ni iom post iom laboras. Kaj kelkaj sufiĉe strangaj aferoj okazas.

Ekzemple, se vi donas al WAL-G malplenan sekurkopion, ĝi simple falos. Ekzemple, se vi diras al li, ke li bezonas rezervan malplenan dosierujon. La pg_control-dosiero ne estos tie. Kaj li pensos, ke li ne komprenas ion. En teorio, ĉi-kaze vi devas skribi normalan mesaĝon al la uzanto por klarigi al li kiel uzi la ilon. Sed tio eĉ ne estas trajto de programado, sed trajto de bona, komprenebla lingvo.

Ni ne scias kiel fari eksterrete sekurkopion. Se la datumbazo mensogas, ni ne povas kopii ĝin. Sed ĉio estas tre simpla ĉi tie. Ni nomas sekurkopiojn per LSN kiam ĝi komenciĝis. La LSN de la subesta bazo devas esti legita el la kontroldosiero. Kaj ĉi tio estas tia nerealigita trajto. Multaj rezervosistemoj povas sekurkopii subesta datumbazo. Kaj ĝi estas oportuna.

Ni nuntempe ne povas trakti la mankon de rezerva spaco ĝuste. Ĉar ni kutime laboras kun grandaj sekurkopioj hejme. Kaj ili ne atingis ĝin. Sed se iu volas programi en Go nun, aldonu pritraktadon por eksterspacaj eraroj al la sitelo. Mi certe rigardos la tiran peton.

Kaj la ĉefa afero, kiu maltrankviligas nin, estas, ke ni volas kiel eble plej multajn docker-integrigajn testojn, kiuj kontrolas diversajn scenarojn. Ĝuste nun ni nur testas bazajn scenarojn. En ĉiu komitaĵo, sed ni volas kontroli kommit-post-commit ĉiujn funkciojn, kiujn ni subtenas. Aparte, ekzemple, ni havos sufiĉe da subteno por PostgreSQL 9.4-9.5. Ni subtenas ilin ĉar la komunumo subtenas PostgreSQL, sed ni ne kontrolas kommit-by-commit por certigi, ke ĉio ne estas rompita. Kaj ŝajnas al mi, ke tio estas sufiĉe grava risko.

Ni havas WAL-G funkciantan sur pli ol mil aretoj en Yandex Database-administrado. Kaj ĝi rezervas plurajn centojn da terabajtoj da datumoj ĉiutage.

Ni havas multajn TODO en nia kodo. Se vi volas programi, venu, ni atendas tirpetojn, ni atendas demandojn.

Viaj demandoj

Bonan vesperon! Dankon! Mi supozas, ke se vi uzas WAL-delta, vi verŝajne multe fidas je tutpaĝaj skribaĵoj. Kaj se jes, ĉu vi faris testojn? Vi montris belan grafikon. Kiom pli bela fariĝas se FPW estas malŝaltita?

Tutpaĝaj skribadoj estas ebligitaj por ni, ni ne provis malŝalti ĝin. Tio estas, mi, kiel programisto, ne provis malŝalti ĝin. Sistemadministrantoj kiuj esploris verŝajne esploris ĉi tiun aferon. Sed ni bezonas FPW. Preskaŭ neniu malŝaltas ĝin, ĉar alie estas neeble preni sekurkopion de kopio.

Dankon pro la raporto! Mi havas du demandojn. La unua demando estas kio okazos al tabelspacoj?

Ni atendas tiran peton. Niaj datumbazoj vivas sur SSD kaj NMVE-diskoj kaj ni ne vere bezonas ĉi tiun funkcion. Mi ne pretas pasigi seriozan tempon ĝuste nun por fari ĝin bone. Mi tutkore pledas, ke ni subtenu tion. Estas homoj, kiuj subtenis ĝin, sed subtenis ĝin en maniero kiu konvenas al ili. Ili faris forkon, sed ili ne faras tirpetojn. (Aldonita en versio 0.2.13)

Kaj la dua demando. Vi diris komence, ke WAL-G supozas, ke ĝi funkcias sole kaj ne necesas envolvaĵoj. Mi mem uzas envolvaĵojn. Kial ili ne estu uzataj?

Ni volas, ke ĝi estu tiel simpla kiel balalajko. Ĉi tio signifas, ke vi bezonas nenion krom balalajko. Ni volas, ke la sistemo estu simpla. Se vi havas funkciojn, kiujn vi devas fari en skripto, do venu kaj diru al ni - ni faros ĝin en Go.

Bonan vesperon! Dankon pro la raporto! Ni ne povis igi WAL-G labori kun GPG-malĉifrado. Ĝi ĉifras normale, sed ne volas deĉifri. Ĉu estas io, kio ne funkciis por ni? La situacio estas deprima.

Kreu problemon en GitHub kaj ni eltrovu ĝin.

Tio estas, ĉu vi ne renkontis ĉi tion?

Estas trajto de la erara raporto, ke kiam WAL-G ne komprenas kian dosieron ĝi estas, ĝi demandas: "Eble ĝi estas ĉifrita?" Eble la problemo tute ne estas ĉifrado. Mi volas plibonigi la ensalutadon pri ĉi tiu temo. Li devas deĉifri ĝin. Ni nuntempe laboras pri ĉi tiu temo en la senco, ke ni ne tre ŝatas kiel la sistemo por akiri publikajn kaj privatajn ŝlosilojn estas organizita. Ĉar ni nomas eksteran GPG por ke ĝi donu al ni siajn ŝlosilojn. Kaj tiam ni prenas ĉi tiujn ŝlosilojn kaj transdonas ilin al la interna GPG, kiu estas malfermita PGP, kiu estas kompilita por ni ene de WAL-G, kaj tie ni nomas ĉifradon. Ĉi-rilate, ni volas plibonigi la sistemon kaj volas subteni Libsodium-ĉifradon (Aldonita en versio 0.2.15). Kompreneble, dekodado devus funkcii, ni eltrovu ĝin - vi bezonas pli da simptomo ol paro da vortoj. Vi povas iam kunveni en la ĉambro de la parolanto kaj rigardi la sistemon. (PGP-ĉifrado sen ekstera GPG - v0.2.9)

Saluton! Dankon pro la raporto! Mi havas du demandojn. Mi havas strangan deziron fari pg_basebackup kaj WAL ensaluti du provizantoj, t.e. mi volas fari unu nubon kaj alian. Ĉu estas ia maniero fari ĉi tion?

Ĉi tio ne ekzistas nun, sed ĝi estas interesa ideo.

Mi simple ne fidas unu provizanton, mi volas havi la samon en alia, ĉiaokaze.

La ideo estas interesa. Teknike, ĉi tio tute ne malfacilas efektivigi. Por eviti ke la ideo perdiĝu, ĉu mi povas peti vin fari problemon en GitHub?

Jes kompreneble.

Kaj tiam, kiam studentoj venos al Google Somero de Kodo, ni aldonos ilin al la projekto por ke estu pli da laboro por akiri pli el ili.

Kaj la dua demando. Estas problemo en GitHub. Mi pensas, ke ĝi jam estas fermita. Estas paniko dum restarigo. Kaj por venki ĝin, vi faris apartan asembleon. Ĝi estas ĝuste en aferoj. Kaj ekzistas eblo fari varian medion en unu fadeno. Kaj tial ĝi funkcias tre malrapide. Kaj ni renkontis ĉi tiun problemon, kaj ĝi ankoraŭ ne estis riparita.

La problemo estas, ke ial la stokado (CEPH) restarigas la konekton kiam ni venas al ĝi kun alta samtempeco. Kion oni povas fari pri tio? La reprova logiko aspektas tiel. Ni provas elŝuti la dosieron denove. En unu paŝo, ni havis kelkajn dosierojn ne elŝutitajn, ni faros duan por ĉiuj, kiuj ne ensalutis. Kaj kondiĉe ke almenaŭ unu dosiero estas ŝarĝita per ripeto, ni ripetas kaj ripetas kaj ripetas. Ni plibonigis la logikon de reprovo - eksponenta retroiro. Sed ne estas tute klare, kion fari kun la fakto, ke la konekto simple rompas ĉe la stokada sistemo. Tio estas, kiam ni alŝutas al unu rivereto, ĝi ne rompas ĉi tiujn ligojn. Kion ni povas plibonigi ĉi tie? Ni havas reton-strangadon, ni povas limigi ĉiun konekton per la nombro da bajtoj, kiujn ĝi sendas. Alie, mi ne scias kiel trakti la fakton, ke objektostokado ne permesas al ni elŝuti aŭ elŝuti de ĝi paralele.

Neniu SLA? Ĉu por ili ne estas skribite, kiel ili lasas sin turmenti?

La punkto estas, ke homoj, kiuj elpensas ĉi tiun demandon, kutime havas sian propran trezorejon. Tio estas, neniu venas de Amazon aŭ Google Cloud aŭ Yandex Object Storage.

Eble la demando ne plu estas por vi?

La demando ĉi tie en ĉi tiu kazo ne gravas al kiu. Se estas ideoj pri kiel trakti ĉi tion, ni faru ĝin en WAL-G. Sed ĝis nun mi ne havas bonajn ideojn pri kiel trakti ĉi tion. Estas iuj Objektaj Stokado, kiuj subtenas listigi sekurkopiojn alimaniere. Vi petas ilin listigi objektojn, kaj ili aldonas dosierujon tie. WAL-G timas pro tio - estas ia afero ĉi tie, kiu ne estas dosiero, mi ne povas restarigi ĝin, kio signifas, ke la sekurkopio ne estis restarigita. Tio estas, fakte, vi havas tute restarigitan areton, sed ĝi resendas al vi eraran staton ĉar Objekta Stokado resendis kelkajn strangajn informojn, kiujn ĝi ne plene komprenis.

Ĉi tio estas afero, kiu okazas en la Mail-nubo.

Se vi povas konstrui reproduktaĵon...

Ĝi estas konstante reproduktita...

Se estas reproduktado, tiam mi pensas, ke ni eksperimentos kun reprovi strategioj kaj eltrovos kiel reprovi kaj kompreni kion la nubo postulas de ni. Eble ĝi estos stabila por ni sur tri konektoj kaj ne rompos la ligon, tiam ni zorge atingos tri. Ĉar nun ni tre rapide forlasas la konekton, t.e. se ni lanĉis reakiron kun 16 fadenoj, tiam post la unua reprovo estos 8 fadenoj, 4 fadenoj, 2 fadenoj kaj unu. Kaj tiam ĝi tiros la dosieron en unu rivereton. Se ekzistas iuj magiaj valoroj kiel 7,5-fadenoj estas la plej bonaj por pumpado, tiam ni prizorgos ilin kaj provos fari aliajn 7,5-fadenojn. Jen ideo.

Dankon pro la raporto! Kiel aspektas kompleta laborfluo por labori kun WAL-G? Ekzemple, en la stulta kazo kiam ne estas delto trans paĝoj. Kaj ni prenas kaj forigas la komencan sekurkopion, tiam arkivas la ŝafton ĝis ni estas bluaj en la vizaĝo. Ĉi tie, kiel mi komprenas, estas paneo. Iam vi devas fari deltan sekurkopion de paĝoj, t.e. iu ekstera procezo kondukas tion aŭ kiel tio okazas?

La delta rezerva API estas sufiĉe simpla. Estas nombro tie - max delta paŝoj, jen kiel ĝi nomiĝas. Ĝi defaŭlte al nulo. Ĉi tio signifas, ke ĉiufoje kiam vi faras rezervan-puŝon, ĝi elŝutas plenan sekurkopion. Se vi ŝanĝas ĝin al iu pozitiva nombro, ekzemple, 3, tiam la venontan fojon kiam vi faros rezervan-puŝon, ĝi rigardas la historion de antaŭaj sekurkopioj. Li vidas, ke vi ne superas la ĉenon de 3 deltoj kaj faras delton.

Tio estas, ĉiufoje kiam ni lanĉas WAL-G, ĝi provas fari plenan sekurkopion?

Ne, ni rulas WAL-G, kaj ĝi provas fari delton se viaj politikoj permesas ĝin.

Proksimume, se vi rulas ĝin kun nulo ĉiufoje, ĉu ĝi kondutos kiel pg_basebackup?

Ne, ĝi ankoraŭ funkcios pli rapide ĉar ĝi uzas kunpremadon kaj paralelecon. Pg_basebackup metos la ŝafton apud vi. WAL-G supozas, ke vi havas arkivadon agordita. Kaj ĝi eligos averton se ĝi ne estas agordita.

Pg_basebackup povas ruliĝi sen ŝaftoj.

Jes, tiam ili kondutas preskaŭ same. Pg_basebackup kopias al la dosiersistemo. Cetere, ni havas novan funkcion, kiun mi forgesis mencii. Ni nun povas sekurkopii al la dosiersistemo de pg_basebackup. Mi ne scias kial ĉi tio estas bezonata, sed ĝi estas tie.

Ekzemple, ĉe CephFS. Ne ĉiuj volas agordi Objektan Stokadon.

Jes, probable tial ili demandis pri ĉi tiu funkcio, por ke ni povu fari ĝin. Kaj ni faris ĝin.

Dankon pro la raporto! Estas nur demando pri kopiado al la dosiersistemo. El la skatolo, ĉu vi nun subtenas kopiadon al fora stokado, ekzemple, se estas iu breto en la datumcentro aŭ io alia?

En ĉi tiu formulo, ĉi tio estas malfacila demando. Jes, ni subtenas, sed ĉi tiu funkcio ankoraŭ ne estas inkluzivita en iu ajn eldono. Tio estas, ĉiuj antaŭ-eldonoj subtenas tion, sed la eldonversioj ne. Ĉi tiu funkcio estis aldonita en versio 0.2. Ĝi certe estos liberigita baldaŭ, tuj kiam ni riparos ĉiujn konatajn cimojn. Sed nun ĉi tio povas esti farita nur en antaŭ-eldono. Estas du cimoj en la antaŭ-eldono. Problemo kun WAL-E-reakiro, ni ne riparis ĝin. Kaj en la plej nova antaŭ-eldono estis aldonita cimo pri delta-rezervo. Tial ni rekomendas al ĉiuj uzi la eldonajn versiojn. Tuj kiam ne plu estas cimoj en la antaŭ-eldono, ni povas diri, ke ni subtenas Google Cloud, S3-kongruajn aferojn kaj dosier-stokadon.

Saluton, dankon pro la raporto. Kiel mi komprenas ĝin, WAL-G ne estas ia centralizita sistemo kiel drinkejistoj? Ĉu vi planas moviĝi en ĉi tiu direkto?

La problemo estas, ke ni malproksimiĝis de ĉi tiu direkto. WAL-G vivas sur la baza gastiganto, sur la aretogastiganto, kaj sur ĉiuj gastigantoj en la areto. Kiam ni transloĝiĝis al plurmil aretoj, ni havis multajn drinkejistajn instalaĵojn. Kaj ĉiufoje kiam io disfalas en ili, ĝi estas granda problemo. Ĉar ili devas esti riparitaj, vi devas kompreni, kiuj aretoj nun ne havas sekurkopiojn. Mi ne planas evoluigi WAL-G en la direkto de fizika aparataro por rezervaj sistemoj. Se la komunumo volas iun funkcion ĉi tie, mi tute ne ĝenas.

Ni havas teamojn, kiuj respondecas pri stokado. Kaj ni sentas nin tiel bone, ke ĝi ne estas ni, ke ekzistas specialaj homoj, kiuj metas niajn dosierojn kie la dosieroj estas sekuraj. Ili faras ĉiajn lertajn kodigojn tie por elteni la perdon de certa nombro da dosieroj. Ili respondecas pri reta bendolarĝo. Kiam vi havas drinkejiston, vi eble subite ekscios, ke malgrandaj datumbazoj kun multe da trafiko kolektiĝis sur la sama servilo. Vi ŝajnas havi multe da spaco sur ĝi, sed ial ĉio ne taŭgas tra la reto. Ĝi povas rezulti inverse. Estas multaj retoj tie, estas procesoraj kernoj, sed ĉi tie ne estas diskoj. Kaj ni laciĝis de ĉi tiu bezono ĵongli ion, kaj ni moviĝis al la fakto, ke datumstokado estas aparta servo, pri kiu respondecas apartaj specialaj homoj.

PS Nova versio estis publikigita 0.2.15, en kiu vi povas uzi la agordan dosieron .walg.json, kiu defaŭlte troviĝas en la hejma dosierujo postgres. Vi povas forlasi bash-skriptojn. Ekzemplo .walg.json estas en ĉi tiu temo https://github.com/wal-g/wal-g/issues/545

Video:

fonto: www.habr.com