Suggerenu di leghje a trascrizione di u rapportu da u principiu di 2019 da Andrey Borodin "Backups with WAL-G Chì ci hè in 2019?"
Salut à tutti ! Mi chjamu Andrey Borodin. Sò un sviluppatore in Yandex. Sò interessatu in PostgreSQL da 2016, dopu avè parlatu cù i sviluppatori è anu dettu chì tuttu hè simplice - pigliate u codice fonte è custruite, è tuttu funziona. E da tandu ùn possu micca piantà - Scrivu ogni tipu di cose diffirenti.
Una di e cose chì aghju travagliatu hè un sistema di salvezza. . In generale, in Yandex avemu travagliatu nantu à i sistemi di salvezza in PostgreSQL per un tempu assai longu. È pudete truvà in Internet una seria di sei rapporti nantu à cumu facemu sistemi di salvezza. È ogni annu evoluzione un pocu, sviluppà un pocu, è diventanu più affidabili.
Ma oghje u rapportu ùn hè micca solu di ciò chì avemu fattu, ma ancu di quantu hè simplice è ciò chì hè. Quanti di voi avete digià guardatu i mo rapporti nantu à WAL-G? Hè bonu chì uni pochi di persone ùn anu micca guardatu, perchè principiaraghju cù a cosa più simplice.
Se di colpu avete un cluster PostgreSQL, è pensu chì tutti ne anu un coppiu cun elli, è di colpu ùn ci hè micca un sistema di salvezza, allora avete bisognu di avè qualchì almacenamentu S3 o Google Cloud cumpatibile.
Per esempiu, pudete vene à u nostru stand è piglià un codice promozionale per Yandex Object Storage, chì hè compatible S3.
Allora crea un Bucket. Hè solu un containeru per l'infurmazioni.
Crea un utilizatore di serviziu.
Crea una chjave d'accessu per l'utilizatori di serviziu: aws-s3-key.
Scaricate l'ultima versione stabile di WAL-G.
Cume sò i nostri pre-releases diffirenti da e versioni? Sò spessu dumandatu di liberà prima. È s'ellu ùn ci hè micca un bug in a versione per un tempu abbastanza, per esempiu, un mesi, allora l'aghju liberatu. Eccu sta liberazione da Novembre. È questu significa chì ogni mese avemu trovu qualchì tipu di bug, di solitu in funziunalità micca critica, ma ùn avemu micca ancu liberatu una liberazione. A versione precedente hè solu nuvembre. Ùn ci sò micca bugs cunnisciuti da noi in questu, vale à dì chì i bugs sò stati aghjunti mentre u prughjettu avanzava.
Una volta chì avete scaricatu WAL-G, pudete eseguisce un cumandamentu simplice di "lista di salvezza", passendu in e variabili di l'ambiente. È hà da cunnette à Object Storage è vi dicerà chì backups avete. À u primu, sicuru, ùn deve micca avè copia di salvezza. U puntu di sta slide hè di dimustrà chì tuttu hè abbastanza simplice. Questu hè un cumandamentu di cunsola chì accetta variabili di l'ambiente è eseguisce subcumandamenti.
Dopu questu, pudete fà a vostra prima copia di salvezza. Dite "backup-push" in WAL-G è specificate in WAL-G u locu pgdata di u vostru cluster. È assai prubabile, PostgreSQL vi diciarà, se ùn avete micca digià un sistema di salvezza, chì avete bisognu di attivà "modu archiviu".
Questu significa chì avete bisognu à andà in i paràmetri è accende "archive_mode = on" è aghjunghje "archive_command", chì hè ancu un subcumandamentu in WAL-G. Ma per una certa raggiuni, a ghjente spessu usa script di barra nantu à questu tema è l'imbulighjanu intornu à WAL-G. Per piacè ùn fate micca questu. Aduprate a funziunalità truvata in WAL-G. Se vi manca qualcosa, scrivite à . WAL-G assume chì hè u solu prugramma chì corre in archive_command.
Usemu WAL-G principalmente per creà un cluster High Availability in a gestione di a basa di dati Yandex.
È hè generalmente utilizatu in una topulugia di un Maestru è parechje replicazioni. À u listessu tempu, face una copia di salvezza in Yandex Object Storage.
I scenarii più cumuni sò a creazione di copie di un cluster utilizendu a ricuperazione Point in time. Ma in questu casu, u rendiment di u sistema di salvezza ùn hè micca cusì impurtante per noi. Avemu bisognu di carica un novu cluster da a copia di salvezza.
Di genere, avemu bisognu di u rendiment di u sistema di salvezza quandu aghjunghje un novu node. Perchè hè impurtante? Di genere, e persone aghjunghjenu un novu node à un cluster perchè u cluster esistente ùn pò micca trattà a carica di lettura. Hanu bisognu di aghjunghje una nova replica. Se aghjunghjemu a carica da pg_basebackup à u Maestru, allura u Maestru pò colapsà. Per quessa, era assai impurtante per noi chì pudemu carica rapidamente un novu node da l'archiviu, creendu una carica minima nantu à u Maestru.
È una altra situazione simili. Questa hè a necessità di riavvia u vechju Maestru dopu avè cambiatu u Cluster Master da u Data Center cù quale a cunnessione hè stata persa.
- In u risultatu, quandu furmulà i requisiti per u sistema di copia, avemu capitu chì pg_basebackup ùn hè micca adattatu per noi quandu operanu in u nuvulu.
- Vulemu esse capace di cumpressà i nostri dati. Ma quasi ogni sistema di salvezza altru ch'è ciò chì vene in a scatula furnisce a cumpressione di dati.
- Vulemu parallelizà tuttu perchè un utilizatore in u nuvulu compra un gran numaru di core di processore. Ma s'ellu ùn avemu micca parallelismu in qualchì operazione, allora un gran numaru di nuclei diventa inutile.
- Avemu bisognu di criptografia perchè spessu i dati ùn sò micca i nostri è ùn ponu micca esse guardati in testu chjaru. Per via, a nostra cuntribuzione à WAL-G hà cuminciatu cù a criptografia. Avemu cumpletu a criptografia in WAL-G, dopu chì ci hè statu dumandatu: "Forse unu di noi hà da sviluppà u prugettu?" E da tandu aghju travagliatu cù WAL-G per più di un annu.
- Avemu ancu bisognu di throttling di risorse, perchè cù u tempu utilizendu u nuvulu, avemu scupertu chì qualchì volta a ghjente hà una carica d'alimentazione impurtante di notte è sta carica ùn pò micca esse interferitu. Hè per quessa chì avemu aghjustatu u throttling di risorse.
- Cume a lista è a gestione.
- È verificazione.
Avemu guardatu assai strumenti diffirenti. Per furtuna, avemu una grande selezzione in PostgreSQL. È in ogni locu ci mancava qualcosa, una piccula funzione, una piccula funzione.
E dopu avè esaminatu i sistemi esistenti, avemu ghjuntu à a cunclusione chì avemu da sviluppà WAL-G. Tandu era un novu prughjettu. Era abbastanza faciule per influenzà u sviluppu versu l'infrastruttura nuvola di u sistema di salvezza.
L'ideulugia principale chì aderemu hè chì WAL-G deve esse simplice quant'è una balalaika.
WAL-G hà 4 cumandamenti. Questu:
WAL-PUSH - archiviu u fustu.
WAL-FETCH - uttene un fustu.
BACKUP-PUSH - fà una copia di salvezza.
BACKUP-FETCH - uttene una copia di salvezza da u sistema di salvezza.
In fatti, WAL-G hà ancu a gestione di sti backups, vale à dì elencu è sguassate records è backups in a storia chì ùn sò più necessarii à u mumentu.
Una di e funzioni impurtanti per noi hè a funzione di creà copie delta.
I copie di Delta significanu chì ùn creamu micca una copia di salvezza completa di tuttu u cluster, ma solu e pagine cambiate di i schedarii cambiati in u cluster. Sembra chì funziunale questu hè assai simili à a capacità di ricuperà cù WAL. Ma pudemu rializà una copia di salvezza di delta unicu WAL in parallelu. In cunsiquenza, quandu avemu una copia di salvezza di basa fatta u sabbatu, backups delta ogni ghjornu, è ghjovi fallemu, allora avemu bisognu di roll up 4 backups delta è 10 ore di WAL. Ci hà da piglià circa u listessu tempu perchè i backups delta rollu in parallelu.
Deltas basati in LSN - questu significa chì quandu crea una copia di salvezza, avemu bisognu di cumminà ogni pagina è verificate u so LSN cù u LSN di a copia di salvezza precedente per capisce chì hà cambiatu. Ogni pagina chì puderia cuntene dati cambiati deve esse presente in a copia di salvezza delta.
Comu dissi, assai attenti hè stata pagata à u parallelismu.
Ma l'archiviu API in PostgreSQL hè coherente. PostgreSQL archivia un schedariu WAL è, quandu u restaurazione, dumanda un schedariu WAL. Ma quandu a basa di dati dumanda un schedariu WAL cù u cumandimu "WAL-FETCH", chjamemu u cumandimu "WAL-PREFETCH", chì prepara i prossimi 8 schedarii per piglià e dati da u magazinu di l'ughjettu in parallelu.
È quandu a basa di dati ci dumanda di archivià un schedariu, fighjemu archive_status è vede s'ellu ci sò altri schedari WAL. È avemu ancu pruvà à scaricà WAL in parallelu. Questu furnisce un guadagnu di rendimentu significativu è riduce significativamente a distanza in u numeru di WAL non archiviati. Parechji sviluppatori di u sistema di salvezza crede chì questu hè un sistema cusì risicatu, perchè avemu a basa di a nostra cunniscenza di l'internu di u codice chì ùn hè micca l'API PostgreSQL. PostgreSQL ùn guarantisci micca a prisenza di u cartulare archive_status per noi è ùn guarantisci micca a semantica, a presenza di signali di prontezza per i schedari WAL quì. Tuttavia, studiemu u codice fonte, vedemu chì questu hè cusì è pruvemu di sfruttà. E cuntrullemu a direzzione in quale PostgreSQL hè sviluppatu, se di colpu stu mecanismu hè rottu, cessemu di usà.
In a so forma pura, basata in LSN WAL delta richiede a lettura di qualsiasi fugliale di cluster chì u modu-tempu in u sistema di fugliale hè cambiatu da a copia di salvezza precedente. Avemu campatu cun questu per un bellu pezzu, quasi un annu. È à a fine avemu ghjuntu à a cunclusione chì avemu WAL deltas.
Questu significa chì ogni volta chì avemu l'archiviu WAL nantu à u Maestru, ùn avemu micca solu cumpressà, criptate è mandà à a reta, ma ancu leghje à u stessu tempu. Analizemu è leghje i registri in questu. Capemu chì i blocchi sò cambiati è cullà i fugliali delta.
Un schedariu delta descrive una certa gamma di schedari WAL, descrive l'infurmazioni nantu à quali blocchi sò stati cambiati in questa gamma di WAL. E poi sti schedarii delta sò ancu archiviati.
Quì avemu affruntatu cù u fattu chì avemu parallelizatu tuttu abbastanza rapidamente, ma ùn pudemu micca leghje una storia sequenziale in parallelu, perchè in un certu segmentu pudemu scontru à a fine di u record WAL precedente, chì ùn avemu nunda di cunnetta, perchè. lettura parallela hà purtatu à chì avemu prima analizà u futuru, chì ùn hà ancu un passatu.
In u risultatu, avemu avutu à mette pezzi incomprensibili in i schedari _delta_partial. In u risultatu, quandu vultemu in u passatu, pegue i pezzi di u record WAL in unu, dopu avemu da analizà è capisce ciò chì hà cambiatu in questu.
Se in a storia di a nostra analisi di l'arburetu ci hè almenu un puntu induve ùn avemu micca capitu ciò chì succede, allora, per quessa, durante a prossima copia di salvezza, seremu custretti à leghje u cluster sanu di novu, cum'è avemu fattu cù un LSN regular. basata in delta.
In u risultatu, tuttu u nostru soffrenu hà purtatu à u fattu chì avemu apertu a biblioteca di parsing WAL-G. Per ciò ch'e so, nimu ùn l'utiliza ancu, ma s'ellu vole, scrive è aduprà, hè in u duminiu publicu. (Ligame aghjurnatu )
In u risultatu, tutti i flussi di l'infurmazioni parenu abbastanza cumplicati. U nostru Maestru archivia l'arbureti è i schedarii delta. È a replica chì face a copia di salvezza deve riceve i fugliali delta durante u tempu chì hè passatu trà e copie di salvezza. In questu casu, parte di a storia deve esse aghjuntu in massa è analizata, perchè micca tutta a storia si mette in grandi segmenti. È solu dopu chì a replica pò archivià una copia di salvezza completa di delta.
Nantu à i grafici tuttu pare assai più simplice. Questu hè un scaricamentu da unu di i nostri veri clusters. Avemu basatu LSN, fattu in un ghjornu. È vedemu chì a copia di salvezza di delta basata in LSN era in esecuzione da trè di a matina à cinque di a matina. Questa hè a carica in u numeru di core di processore. WAL-delta ci hà pigliatu circa 20 minuti quì, hè diventatu significativamente più veloce, ma à u stessu tempu ci era un scambiu più intensu nantu à a reta.
Siccomu avemu infurmazione nantu à quali blocchi anu cambiatu è in quale tempu in a storia di a basa di dati, andemu più in là è decisu di integrà e funziunalità - una estensione PostgreSQL chjamata "pg_prefaulter"
Questu significa chì quandu a basa di stand-by eseguisce u cumandamentu di restaurazione, dice à WAL-G per piglià u prossimu file WAL. Capemu apprussimatamente quali blocchi di dati u prucessu di ricuperazione WAL accede in un futuru vicinu è inizià una operazione di lettura nantu à questi blocchi. Questu hè statu fattu per aumentà u rendiment di i controller SSD. Perchè u rollu WAL ghjunghje à a pagina chì deve esse cambiata. Questa pagina hè nantu à u discu è ùn hè micca in a cache di a pagina. È aspittà sincronamente chì sta pagina arrivà. Ma vicinu hè WAL-G, chì sà chì in i prossimi centu di megabyte di WAL avemu bisognu di certe pagine è à u stessu tempu principia à riscaldallu. Inizia parechji accessi di discu in modu chì sò eseguiti in parallelu. Questu funziona bè nantu à i discu SSD, ma, sfurtunatamenti, ùn hè assolutamente micca applicabile per un discu duru, perchè l'interferemu solu cù i nostri suggerimenti.
Questu hè ciò chì hè in u codice avà.
Ci sò funziunalità chì vulemu aghjunghje.
Sta stampa mostra chì WAL-delta pigghia un tempu relativamente cortu. È questu hè leghje i cambiamenti chì sò accaduti in a basa di dati durante u ghjornu. Pudemu fà WAL-delta micca solu di notte, perchè ùn hè più una fonte significativa di carica. Pudemu leghje WAL-delta ogni minutu perchè hè prezzu. In un minutu pudemu scansà tutti i cambiamenti chì sò accaduti à u cluster. È questu puderia esse chjamatu "instant WAL-delta".
U puntu hè chì quandu ristabilisce u cluster, riducemu u nùmeru di storii chì avemu da sbulicà in sequenza. Questu hè, a quantità di WAL chì PostgreSQL rolls deve esse ridutta, perchè pigghia un tempu significativu.
Ma ùn hè micca tuttu. Se sapemu chì qualchì bloccu serà cambiatu à u puntu di a cunsistenza di salvezza, ùn pudemu micca cambià in u passatu. Questu hè, avà avemu l'ottimisazione file-by-file di WAL-delta forwarding. Questu significa chì se, per esempiu, u marti, una tavola hè stata completamente sguassata o alcuni schedari sò stati sguassati sanu sanu da a tavula, allora quandu u delta rolls over u luni è u sabbatu pg_basebackup hè restauratu, ùn avemu micca ancu creà sta dati.
Vulemu allargà sta tecnulugia à u livellu di a pagina. Vale à dì, se una parte di u schedariu cambia u luni, ma serà soprascritta u mercuri, allora quandu si restaurà à un puntu ghjovi, ùn avemu micca bisognu di scrive e prime versioni di e pagine à u discu.
Ma questu hè sempre una idea chì hè attivamente discussa in noi, ma ùn hè ancu ghjunta à u codice.
Vulemu fà una funzione più in WAL-G. Vulemu fà estensibile perchè avemu bisognu di supportà diverse basa di dati è vulemu esse capace di avvicinà a gestione di salvezza in u listessu modu. Ma u prublema hè chì l'API MySQL sò radicali diffirenti. In MySQL, PITR ùn hè micca basatu annantu à u logu WAL fisicu, ma in u binlog. È ùn avemu micca un sistema di archiviu in MySQL chì diceria à qualchì sistema esternu chì stu binlog hè finitu è deve esse archiviatu. Avemu bisognu di stà in un locu in cron cù a basa di dati è verificate s'ellu ci hè qualcosa pronta?
È in u listessu modu, durante una restaurazione MySQL, ùn ci hè micca un cumandamentu di restaurazione chì puderia dì à u sistema chì aghju bisognu di tali file. Prima di cumincià à ricustruisce u vostru cluster, avete bisognu di sapè quale fugliali avete bisognu. Avete bisognu di guessà quale fugliali avete bisognu. Ma questi prublemi ponu esse sbulicati in qualchì modu. (Clarificazione: MySQL hè digià supportatu)
In u rapportu, vulia ancu parlà di quelli casi quandu WAL-G ùn hè micca adattatu per voi.
Se ùn avete micca una replica sincrona, WAL-G ùn guarantisci micca chì l'ultimu segmentu serà priservatu. È se l'archiviazione hè in ritardu di l'ultimi segmenti di a storia, questu hè un risicu. Se ùn ci hè micca una replica sincrona, ùn aghju micca cunsigliatu di utilizà WAL-G. Tuttavia, hè principalmente pensatu per una stallazione di nuvola, chì implica una soluzione d'Alta Disponibilità cù una replica sincrona, chì hè rispunsevule per a sicurità di l'ultimi byte impegnati.
Spessu vecu a ghjente chì prova di eseguisce WAL-G è WAL-E à u stessu tempu. Supportemu a cumpatibilità retrocede in u sensu chì WAL-G pò restaurà un schedariu da WAL-E è pò restaurà una copia di salvezza fatta in WAL-E. Ma postu chì i dui sistemi utilizanu wal-push paralleli, cumincianu à arrubbari i schedari l'un l'altru. Se u correggemu in WAL-G, ferma sempre in WAL-E. In WAL-E, guardà l'archiviu-status, vede i fugliali finiti è l'archivi, mentri àutri sistemi simpricimenti ùn sapanu micca chì stu schedariu WAL esiste, perchè PostgreSQL ùn pruvarà micca di archivià una seconda volta.
Chì andemu à riparà quì da u latu WAL-G ? Ùn avemu micca infurmatu à PostgreSQL chì stu schedariu hè statu trasferitu in parallelu, è quandu PostgreSQL ci dumanda à l'archiviu, sapemu digià chì un tali schedariu cù questu modu-tempu è cù questu md5 hè digià statu archiviatu è solu diceremu PostgreSQL - OK, tuttu hè prontu senza essenzialmente fà nunda.
Ma questu prublema hè improbabile di esse risoltu in u latu WAL-E, cusì hè attualmente impussibile di creà un cumandamentu d'archiviu chì archivirà u schedariu sia in WAL-G sia in WAL-E.
Inoltre, ci sò casi induve WAL-G ùn hè micca adattatu per voi avà, ma certamente l'averemu.
Prima, attualmente ùn avemu micca una verificazione di salvezza integrata. Ùn avemu micca verificazione nè durante a copia di salvezza nè a ricuperazione. Di sicuru, questu hè implementatu in u nuvulu. Ma questu hè implementatu solu per pre-verificà, solu per restaurà u cluster. Vogliu dà sta funziunalità à l'utilizatori. Ma da a verificazione, assume chì in WAL-G serà pussibule restaurà u cluster è inizià, è eseguite teste di fumu: pg_dumpall à /dev/null è amcheck index verification.
Attualmente in WAL-G ùn ci hè manera di posponà una copia di salvezza da WAL. Questu hè, sustenemu qualchì finestra. Per esempiu, almacenà l'ultimi sette ghjorni, almacenà l'ultimi deci backups, almacenà l'ultimi trè backups cumpleti. Piuttostu spessu a ghjente vene è dice: "Avemu bisognu di una copia di salvezza di ciò chì hè accadutu u Capu d'annu è vulemu mantene per sempre". WAL-G ùn sapi ancu cumu fà questu. (Nota - Questu hè digià statu riparatu. Leghjite più - Opzione di marca di salvezza in )
È ùn avemu micca checksum di pagina è cuntrolli di integrità per tutti i segmenti di l'arbureti quandu validate PITR.
Da tuttu questu aghju aghjustatu un prughjettu per Google Summer of Code. Se cunnosci studienti intelligenti chì vulianu scrive qualcosa in Go è uttene parechji millai di dollari da una cumpagnia cù a lettera "G", allora ricumandemu u nostru prughjettu à elli. Aghju da fà cum'è un mentor per stu prughjettu, ponu fà. S'ellu ùn ci hè micca studienti, allora l'aghju da piglià è fà per mè stessu in l'estiu.
È avemu parechji altri picculi prublemi chì avemu da travaglià à pocu à pocu. E cose abbastanza strane succedenu.
Per esempiu, s'è vo dete WAL-G una copia di salvezza viota, si simpricimenti falà. Per esempiu, s'è vo dite à ellu chì hà bisognu di salvezza un cartulare viotu. U schedariu pg_control ùn serà micca quì. È penserà chì ùn capisce micca qualcosa. In teoria, in questu casu avete bisognu di scrive un missaghju normale à l'utilizatore per spiegà à ellu cumu utilizà l'uttellu. Ma questu ùn hè ancu una funzione di prugrammazione, ma una caratteristica di una bona lingua intelligibile.
Ùn sapemu micca cumu fà una copia di salvezza offline. Se a basa di dati si trova, ùn pudemu micca fà una copia di salvezza. Ma tuttu hè assai simplice quì. Chjamemu backups da LSN quandu hà cuminciatu. U LSN di a basa sottostante deve esse lettu da u schedariu di cuntrollu. È questu hè una funzione cusì micca realizata. Parechji sistemi di salvezza ponu salvà una basa di dati sottostanti. È hè cunvene.
Attualmente ùn pudemu micca trattà bè a mancanza di spaziu di salvezza. Perchè di solitu travaglià cù grandi backups in casa. È ùn anu micca ghjuntu. Ma se qualchissia vole programà in Go avà, aghjunghje a gestione di l'errori fora di u spaziu à u bucket. Certamente esamineraghju a dumanda di pull.
È a cosa principale chì ci preoccupa hè chì vulemu quant'è più teste di integrazione di docker pussibule chì verificanu diversi scenarii. In questu momentu testemu solu scenarii basi. In ogni impegnu, ma vulemu verificà commit-by-commit tutte e funziunalità chì sustenemu. In particulare, per esempiu, averemu abbastanza supportu per PostgreSQL 9.4-9.5. Li sustenemu perchè a cumunità sustene PostgreSQL, ma ùn cuntrollemu micca commit-by-commit per assicurà chì tuttu ùn hè micca rottu. È mi pare chì questu hè un risicu piuttostu seriu.
Avemu WAL-G chì funziona in più di mille clusters in a gestione di a basa di dati Yandex. È face una copia di salvezza di parechji centu terabyte di dati ogni ghjornu.
Avemu assai TODO in u nostru codice. Sè vo vulete programà, venite, aspettemu dumande di pull, aspettemu dumande.
I vostri dumanni
Bona sera! Grazie! A mo ipotesi hè chì sè vo aduprate WAL-delta, probabilmente vi fidate assai di scrittura di pagina intera. È s'ellu hè cusì, avete eseguitu testi? Avete mostratu un bellu graficu. Quantu più bella diventa se FPW hè spenta?
A scrittura full-page hè attivata per noi, ùn avemu micca pruvatu à disattivà. Questu hè, eiu, cum'è sviluppatore, ùn aghju micca pruvatu à disattivà. L'amministratori di sistema chì anu investigatu anu prubabilmente investigatu stu prublema. Ma avemu bisognu di FPW. Quasi nimu disattiva, perchè altrimenti hè impussibile di piglià una copia di salvezza da una replica.
Grazie per u rapportu! Aghju duie dumande. A prima quistione hè chì succede à i tablespaces?
Aspittemu una dumanda di pull. A nostra basa di dati vive nantu à i dischi SSD è NMVE è ùn avemu micca veramente bisognu di sta funzione. Ùn sò micca prontu à passà u tempu seriu per fà bè avà. Avucatu di tuttu u core chì sustenemu questu. Ci sò persone chì l'anu sustinutu, ma l'anu sustinutu in una manera chì li cunvene. Hanu fattu una furchetta, ma ùn facenu micca richieste di pull. (Aghjuntu in a versione 0.2.13)
È a seconda quistione. Avete dettu à u principiu chì WAL-G assume chì funziona solu è ùn ci hè micca bisognu di wrappers. Aghju aduprà i wrappers stessu. Perchè ùn deve esse usatu?
Vulemu chì sia simplice cum'è una balalaika. Questu significa chì ùn avete micca bisognu di nunda, salvu una balalaika. Vulemu chì u sistema sia simplice. Se avete funziunalità chì avete bisognu à fà in un script, allora venite è diteci - a faremu in Go.
Bona sera! Grazie per u rapportu! Ùn pudemu micca avè WAL-G per travaglià cù a decifrazione GPG. Cifra normalmente, ma ùn vole micca decifrare. Hè qualcosa chì ùn hà micca travagliatu per noi? A situazione hè deprimente.
Crea un prublema in GitHub è scopremu.
Questu hè, ùn avete micca scontru questu?
Ci hè una caratteristica di u rapportu d'errore chì quandu WAL-G ùn capisce micca chì tipu di fugliale hè, dumanda: "Forse hè criptatu?" Forsi u prublema ùn hè micca a criptografia. Vogliu migliurà u logu nantu à questu tema. Deve decifrallu. Attualmente avemu travagliatu annantu à questu tema in u sensu chì ùn ci piace micca veramente cumu hè urganizatu u sistema per ottene chjavi publichi è privati. Perchè chjamemu GPG esternu per ch'ellu ci dessi e so chjave. E poi pigliamu sti chjavi è trasfiriu à u GPG internu, chì hè apertu PGP, chì hè compilatu per noi in WAL-G, è quì chjamemu criptografia. In questu sensu, vulemu migliurà u sistema è vulemu sustene l'encryption Libsodium (Add in versione 0.2.15). Di sicuru, a decodificazione duveria travaglià, simulemu - avete bisognu di più di un sintumu cà un paru di parolle. Pudete riunite in a stanza di u parlante qualchì volta è fighjà u sistema. (Crittografia PGP senza GPG esternu - v0.2.9)
Bonghjornu! Grazie per u rapportu! Aghju duie dumande. Aghju un desideriu stranu di fà pg_basebackup è WAL log in dui fornituri, vale à dì, vogliu fà un nuvulu è un altru. Ci hè una manera di fà questu?
Questu ùn esiste micca avà, ma hè una idea interessante.
Solu ùn aghju micca fiducia in un fornitore, vogliu avè u listessu in un altru, solu in casu.
L'idea hè interessante. Tecnicamente, questu ùn hè micca difficiule di implementà. Per impediscenu chì l'idea si perde, possu dumandà di fà un prublema in GitHub?
Iè, di sicuru.
È dopu, quandu i studienti venenu à Google Summer of Code, l'aghjunghjemu à u prugettu per chì ci hè più travagliu per ottene più fora di elli.
È a seconda quistione. Ci hè un prublema in GitHub. Pensu chì hè digià chjusu. Ci hè un panicu durante a restaurazione. È per scunfighja, avete fattu una assemblea separata. Hè ghjustu in i prublemi. È ci hè una opzione per fà un ambiente variabile in un filu. È hè per quessa chì travaglia assai pianu. È avemu scontru stu prublema, è ùn hè micca stata risolta.
U prublema hè chì per una certa ragione l'almacenamiento (CEPH) resetta a cunnessione quandu avemu da vene cun alta cuncurrenza. Chì si pò fà nantu à questu? A logica di riprova hè cusì. Pruvamu di scaricà u schedariu di novu. In un passu, avemu avutu una quantità di schedari micca scaricati, faremu un secondu per tutti quelli chì ùn anu micca login. È finu à chì almenu un schedariu hè caricatu per iterazione, ripetemu è ripetemu è ripetite. Avemu migliuratu a logica di retry - backoff esponenziale. Ma ùn hè micca sanu sanu chjaru chì fà cù u fattu chì a cunnessione si rompe solu da u latu di u sistema di almacenamiento. Vale à dì, quandu carichemu in un flussu, ùn rompe micca queste cunnessione. Chì pudemu migliurà quì? Avemu un throttling di rete, pudemu limità ogni cunnessione per u numeru di bytes chì manda. Altrimenti, ùn sò micca sapè cumu trattà cù u fattu chì l'almacenamiento d'ughjettu ùn ci permette micca di scaricà o scaricate da ellu in parallelu.
Nisun SLA? Ùn hè micca scrittu per elli cumu si permettenu di turmentà ?
U puntu hè chì e persone chì venenu cù sta quistione di solitu anu a so propria volta. Questu hè, nimu vene da Amazon o Google Cloud, o Yandex Object Storage.
Forse a quistione ùn hè più per voi ?
A quistione quì in questu casu ùn importa micca à quale. Se ci sò idee nantu à cumu trattà cun questu, femu in WAL-G. Ma finu à avà ùn aghju micca idee boni nantu à cumu trattà cun questu. Ci sò qualchi Object Storage chì supportanu i backups di lista in modu diversu. Li dumandate di listinu l'uggetti, è aghjunghjenu u cartulare. WAL-G si spaventa da questu - ci hè un tipu di cosa quì chì ùn hè micca un schedariu, ùn possu micca restaurà, chì significa chì a copia di salvezza ùn hè micca stata restaurata. Hè, in fattu, avete un cluster completamente restauratu, ma vi torna un statu erroneu perchè Object Storage hà tornatu qualchì infurmazione strana chì ùn hà micca capitu sanu.
Questa hè una cosa chì succede in u nuvulu di Mail.
Se pudete custruisce una riproduzione ...
Hè riproduciutu in modu coerente ...
S'ellu ci hè una ripruduzzione, allora pensu chì sperimentaremu strategie di ricuperazione è capisce cumu per ripruverà è capisce ciò chì a nuvola richiede di noi. Forsi serà stabile per noi nantu à trè cunnessione è ùn romperà micca a cunnessione, allora avemu da ghjunghje cù cura à trè. Perchè avà abbandunemu a cunnessione assai rapidamente, vale à dì s'è avemu lanciatu una ricuperazione cù 16 fili, dopu à a prima volta ci saranu 8 fili, 4 fili, 2 fili è unu. E poi tirà u schedariu in un flussu. Se ci sò qualchi valori magichi cum'è 7,5 fili sò u megliu per pompà, allora stendu nantu à elli è pruvate à fà un altru filu 7,5. Eccu una idea.
Grazie per u rapportu! Cume hè un flussu di travagliu cumpletu per travaglià cù WAL-G? Per esempiu, in u casu stupidu quandu ùn ci hè micca delta in e pagine. E pigliemu è sguassate a copia di salvezza iniziale, dopu archiviu l'arbulu finu à chì simu turchini in faccia. Quì, cum'è l'aghju capitu, ci hè un scontru. À un certu puntu avete bisognu di fà una copia di salvezza delta di e pagine, vale à dì qualchì prucessu esternu hè guidatu questu o cumu si succede?
L'API di backup delta hè abbastanza simplice. Ci hè un numeru quì - max delta steps, hè ciò chì si chjama. Hè predeterminatu à zero. Questu significa chì ogni volta chì fate una copia di salvezza, scarica una copia di salvezza completa. Se cambiassi à qualsiasi numeru pusitivu, per esempiu, 3, allora a prossima volta chì fate un backup-push, guarda a storia di backups precedente. Ellu vede chì ùn trapassa micca a catena di 3 delta è face un delta.
Hè, ogni volta chì lanciamu WAL-G, prova di fà una copia di salvezza completa?
Innò, eseguimu WAL-G, è prova di fà un delta se e vostre pulitiche permettenu.
À pocu pressu, se l'eseguite cù zero ogni volta, si cumportarà cum'è pg_basebackup?
No, serà sempre più veloce perchè usa cumpressione è parallelismu. Pg_basebackup metterà l'arbulu vicinu à voi. WAL-G assume chì avete l'archiviazione cunfigurata. È emette un avvisu s'ellu ùn hè micca cunfiguratu.
Pg_basebackup pò esse eseguitu senza shafts.
Iè, allora si cumportanu quasi u listessu. Pg_basebackup copie à u sistema di schedari. A propositu, avemu una nova funzione chì aghju scurdatu di mintuvà. Pudemu avà una copia di salvezza in u sistema di schedari da pg_basebackup. Ùn sò micca sapè perchè questu hè necessariu, ma hè quì.
Per esempiu, nantu à CephFS. Micca tutti volenu cunfigurà Object Storage.
Iè, hè probabilmente per quessa ch'elli anu dumandatu una quistione nantu à sta funzione in modu chì pudemu fà. È avemu fattu.
Grazie per u rapportu! Ci hè solu una quistione di cupià à u sistema di schedari. Fora di a scatula, avà sustene a copia à u almacenamentu remoto, per esempiu, s'ellu ci hè qualchì scaffale in u centru di dati o qualcosa altru?
In questa formulazione, questa hè una quistione difficiule. Iè, sustenemu, ma sta funziunalità ùn hè ancu inclusa in alcuna versione. Questu hè, tutti i pre-releases supportanu questu, ma e versioni di liberazione ùn sò micca. Sta funziunalità hè stata aghjunta in a versione 0.2. Di sicuru, sarà liberatu prestu, appena avemu riparatu tutti i bug cunnisciuti. Ma avà questu pò esse fattu solu in pre-release. Ci sò dui bug in a pre-liberazione. Prublemu cù a ricuperazione di WAL-E, ùn avemu micca riparatu. È in l'ultime pre-release hè statu aghjuntu un bug di delta-backup. Dunque, ricumandemu à tutti di utilizà e versioni di liberazione. Appena ùn ci sò più bugs in u pre-release, pudemu dì chì sustenemu Google Cloud, cose cumpatibili S3 è archiviazione di schedari.
Hola, grazie per u rapportu. Cum'è l'aghju capitu, WAL-G ùn hè micca un tipu di sistema centralizatu cum'è barmen? Pensate di passà in questa direzzione ?
U prublema hè chì avemu alluntanatu da sta direzzione. WAL-G vive nantu à l'ospite di basa, nantu à l'ospite di cluster, è in tutti l'ospiti in u cluster. Quandu avemu trasfirutu à parechji mila clusters, avemu avutu assai installazioni di bartender. È ogni volta chì qualcosa casca in elli, hè un grande prublema. Perchè anu da esse riparatu, avete bisognu di capiscenu chì clusters avà ùn anu micca copia di salvezza. Ùn aghju micca pensatu à sviluppà WAL-G in a direzzione di hardware fisicu per i sistemi di salvezza. Se a cumunità vole qualchì funziunalità quì, ùn mi importa micca.
Avemu squadre chì sò rispunsevuli di u almacenamentu. È ci sentimu cusì bè chì ùn hè micca noi, chì ci sò persone spiciali chì mette i nostri schedari induve i schedari sò sicuru. Facenu ogni tipu di codificazione intelligente quì per sustene a perdita di un certu numaru di schedari. Sò rispunsevuli di a larghezza di banda di a rete. Quandu avete un barman, pudete scopre di colpu chì e piccule basa di dati cù assai trafficu anu riunitu nantu à u stessu servitore. Sembra chì avete assai spaziu nantu à questu, ma per qualchì ragiuni tuttu ùn si mette in a reta. Pò esce da l'altra manera. Ci sò assai rete, ci sò nuclei di processore, ma ùn ci sò micca dischi quì. E avemu stancu di sta necessità di juggle qualcosa, è avemu spusatu à u fattu chì l'almacenamiento di dati hè un serviziu separatu, per quale e persone spiciali separati sò rispunsevuli.
PS Una nova versione hè stata liberata , in quale pudete aduprà u schedariu di cunfigurazione .walg.json, chì si trova in u repertoriu di casa postgres per automaticamente. Pudete abbandunà i scripts bash. Esempiu .walg.json hè in questu prublema
Video:
Source: www.habr.com