Us suggereixo que llegiu la transcripció de l'informe de principis de 2019 d'Andrey Borodin "Còpia de seguretat amb WAL-G. Què hi ha el 2019?"
Hola a tots! Em dic Andrey Borodin. Sóc desenvolupador a Yandex. Estic interessat en PostgreSQL des del 2016, després que parlés amb els desenvolupadors i em diguessin que tot és senzill: agafeu el codi font i el creeu, i tot sortirà. I des de llavors no puc parar: escric tot tipus de coses diferents.
Una de les coses en què estic treballant és un sistema de còpia de seguretat. . En general, a Yandex portem molt de temps treballant en sistemes de còpia de seguretat a PostgreSQL. I podeu trobar a Internet una sèrie de sis informes sobre com fem sistemes de còpia de seguretat. I cada any evolucionen una mica, es desenvolupen una mica i es fan més fiables.
Però avui l'informe no només tracta del que hem fet, sinó també del senzill que és i què és. Quants de vosaltres ja heu vist els meus informes sobre WAL-G? És bo que molta gent no l'hagi mirat, perquè començaré pel més senzill.
Si de sobte teniu un clúster PostgreSQL i crec que tothom en té un parell amb ells i, de sobte, encara no hi ha cap sistema de còpia de seguretat, heu d'aconseguir qualsevol emmagatzematge S3 o emmagatzematge compatible amb Google Cloud.
Per exemple, podeu venir al nostre estand i agafar un codi promocional per a Yandex Object Storage, que és compatible amb S3.
A continuació, creeu un Bucket. És només un contenidor per a la informació.
Crear un usuari del servei.
Creeu una clau d'accés per a l'usuari del servei: aws-s3-key.
Baixeu la darrera versió estable de WAL-G.
En què es diferencien les nostres versions prèvies dels llançaments? Sovint se'm demana que l'alliberi abans. I si no hi ha cap error a la versió durant un temps suficient, per exemple, un mes, l'allibero. Aquí teniu aquesta publicació del novembre. I això vol dir que cada mes trobem algun tipus d'error, normalment en funcionalitats no crítiques, però encara no hem publicat cap versió. La versió anterior només és de novembre. No hi ha errors coneguts per nosaltres, és a dir, s'han afegit errors a mesura que avançava el projecte.
Un cop hàgiu descarregat WAL-G, podeu executar una ordre senzilla de "llista de còpia de seguretat", passant les variables d'entorn. I es connectarà a Object Storage i us indicarà quines còpies de seguretat teniu. Al principi, per descomptat, no hauríeu de tenir còpies de seguretat. L'objectiu d'aquesta diapositiva és mostrar que tot és bastant senzill. Aquesta és una ordre de consola que accepta variables d'entorn i executa subordres.
Després d'això, podeu fer la vostra primera còpia de seguretat. Digueu "backup-push" a WAL-G i especifiqueu a WAL-G la ubicació pgdata del vostre clúster. I molt probablement, PostgreSQL us dirà, si encara no teniu un sistema de còpia de seguretat, que heu d'habilitar el "mode d'arxiu".
Això vol dir que heu d'anar a la configuració i activar "archive_mode = on" i afegir "archive_command", que també és una subordre a WAL-G. Però per alguna raó, la gent sovint utilitza scripts de barres sobre aquest tema i l'embolica al voltant de WAL-G. Si us plau, no facis això. Utilitzeu la funcionalitat que es troba a WAL-G. Si et perd alguna cosa, escriu-hi . WAL-G suposa que és l'únic programa que s'executa a archive_command.
Utilitzem WAL-G principalment per crear un clúster d'alta disponibilitat a la gestió de bases de dades Yandex.
I normalment s'utilitza en una topologia d'un mestre i diverses rèpliques. Al mateix temps, fa una còpia de seguretat a Yandex Object Storage.
Els escenaris més habituals són la creació de còpies d'un clúster mitjançant la recuperació puntual. Però en aquest cas, el rendiment del sistema de còpia de seguretat no és tan important per a nosaltres. Només hem de pujar un nou clúster des de la còpia de seguretat.
Normalment, necessitem el rendiment del sistema de còpia de seguretat quan afegim un nou node. Per què és important? Normalment, la gent afegeix un node nou a un clúster perquè el clúster existent no pot gestionar la càrrega de lectura. Han d'afegir una nova rèplica. Si afegim la càrrega de pg_basebackup al mestre, llavors el mestre pot col·lapsar-se. Per tant, era molt important per a nosaltres que poguéssim pujar ràpidament un nou node des de l'arxiu, creant una càrrega mínima al mestre.
I una altra situació semblant. Aquesta és la necessitat de reiniciar l'antic mestre després de canviar el Cluster Master del centre de dades amb el qual es va perdre la connectivitat.
- Com a resultat, en formular els requisits per al sistema de còpia, ens vam adonar que pg_basebackup no és adequat per a nosaltres quan operem al núvol.
- Volíem poder comprimir les nostres dades. Però gairebé qualsevol sistema de còpia de seguretat que no sigui el que ve a la caixa proporcionarà compressió de dades.
- Volíem paral·lelitzar-ho tot perquè un usuari al núvol compra un gran nombre de nuclis de processador. Però si no tenim paral·lelisme en alguna operació, llavors un gran nombre de nuclis esdevé inútil.
- Necessitem xifratge perquè sovint les dades no són nostres i no es poden emmagatzemar en text clar. Per cert, la nostra contribució a WAL-G va començar amb el xifratge. Vam completar el xifratge a WAL-G, després de la qual cosa ens van preguntar: "Potser algun de nosaltres desenvoluparà el projecte?" I des d'aleshores porto més d'un any treballant amb WAL-G.
- També necessitàvem l'acceleració de recursos, perquè amb el temps utilitzant el núvol, vam descobrir que de vegades la gent té una càrrega important de queviures a la nit i aquesta càrrega no es pot interferir. És per això que hem afegit l'acceleració de recursos.
- Així com la llista i la gestió.
- I comprovació.
Hem observat moltes eines diferents. Afortunadament, tenim una gran selecció a PostgreSQL. I a tot arreu ens faltava alguna cosa, una petita funció, una petita funció.
I després d'examinar els sistemes existents, vam arribar a la conclusió que desenvoluparem WAL-G. Aleshores era un projecte nou. Va ser bastant fàcil influir en el desenvolupament cap a la infraestructura del núvol del sistema de còpia de seguretat.
La principal ideologia a la qual ens adherim és que WAL-G hauria de ser tan simple com una balalaika.
WAL-G té 4 ordres. Això:
WAL-PUSH: arxivar l'eix.
WAL-FETCH: aconseguiu un eix.
BACKUP-PUSH: feu una còpia de seguretat.
BACKUP-FETCH: obteniu una còpia de seguretat del sistema de còpia de seguretat.
De fet, WAL-G també té la gestió d'aquestes còpies de seguretat, és a dir, llistar i esborrar fitxers i còpies de seguretat de l'historial que ja no són necessaris en aquest moment.
Una de les funcions importants per a nosaltres és la funció de crear còpies delta.
Les còpies delta signifiquen que no creem una còpia de seguretat completa de tot el clúster, sinó només les pàgines modificades dels fitxers modificats del clúster. Sembla que funcionalment això és molt semblant a la capacitat de recuperar-se mitjançant WAL. Però podem enrollar una còpia de seguretat delta d'un sol fil WAL en paral·lel. En conseqüència, quan tenim una còpia de seguretat bàsica realitzada el dissabte, còpies de seguretat delta diàriament, i dijous fallem, llavors haurem de acumular 4 còpies de seguretat delta i 10 hores de WAL. Trigarà aproximadament el mateix temps perquè les còpies de seguretat delta es desenvolupen en paral·lel.
Deltas basats en LSN: això vol dir que en crear una còpia de seguretat, haurem de combinar cada pàgina i comprovar el seu LSN amb el LSN de la còpia de seguretat anterior per entendre que ha canviat. Qualsevol pàgina que pugui contenir dades modificades hauria d'estar present a la còpia de seguretat delta.
Com he dit, es va prestar molta atenció al paral·lelisme.
Però l'API d'arxiu a PostgreSQL és coherent. PostgreSQL arxiva un fitxer WAL i en restaurar-lo sol·licita un fitxer WAL. Però quan la base de dades sol·licita un fitxer WAL mitjançant l'ordre "WAL-FETCH", anomenem l'ordre "WAL-PREFETCH", que prepara els següents 8 fitxers per obtenir dades del magatzem d'objectes en paral·lel.
I quan la base de dades ens demana que arxivem un fitxer, mirem archive_status i mirem si hi ha altres fitxers WAL. I també estem intentant descarregar WAL en paral·lel. Això proporciona un guany de rendiment important i redueix significativament la distància en el nombre de WAL no arxivats. Molts desenvolupadors de sistemes de còpia de seguretat creuen que aquest és un sistema tan arriscat perquè confiem en el nostre coneixement de la part interna del codi que no és l'API de PostgreSQL. PostgreSQL no ens garanteix la presència de la carpeta archive_status i no ens garanteix la semàntica, la presència de senyals de preparació per als fitxers WAL allà. No obstant això, estem estudiant el codi font, veiem que és així i estem intentant explotar-lo. I controlem la direcció en què s'està desenvolupant PostgreSQL; si de sobte aquest mecanisme es trenca, deixarem d'utilitzar-lo.
En la seva forma pura, el delta WAL basat en LSN requereix llegir qualsevol fitxer de clúster el temps de mode del qual al sistema de fitxers hagi canviat des de la còpia de seguretat anterior. Vam conviure amb això durant molt de temps, gairebé un any. I al final vam arribar a la conclusió que tenim deltes WAL.
Això vol dir que cada vegada que arxivem WAL al Mestre, no només el comprimim, el xifrem i l'enviem a la xarxa, sinó que també el llegim al mateix temps. Analitzem i llegim els registres que hi ha. Entenem quins blocs han canviat i recollim fitxers delta.
Un fitxer delta descriu un determinat rang de fitxers WAL, descriu informació sobre quins blocs s'han canviat en aquest rang de WAL. I després aquests fitxers delta també s'arxiven.
Aquí ens trobem davant del fet que ho hem paral·lelitzat tot amb força rapidesa, però no podem llegir una història seqüencial en paral·lel, perquè en un determinat segment podem trobar-nos amb el final del registre WAL anterior, amb el qual encara no tenim res a connectar, perquè la lectura paral·lela va fer que primer analitzem el futur, que encara no té passat.
Com a resultat, vam haver de posar peces incomprensibles en fitxers _delta_parcials. Com a resultat, quan tornem al passat, enganxarem les peces del registre WAL en una, després l'analitzarem i entendrem què hi ha canviat.
Si a l'historial de l'anàlisi de l'eix hi ha almenys un punt en què no entenem què estava passant, llavors, en conseqüència, durant la propera còpia de seguretat ens veurem obligats a llegir tot el clúster de nou, tal com vam fer amb un LSN normal. -basat en delta.
Com a resultat, tot el nostre patiment va portar al fet que vam crear de codi obert la biblioteca d'anàlisi WAL-G. Que jo sàpiga, encara no l'utilitza ningú, però si algú vol, escriu-la i utilitza, és de domini públic. (Enllaç actualitzat )
Com a resultat, tots els fluxos d'informació semblen força complicats. El nostre mestre arxiva l'eix i els fitxers delta. I la rèplica que fa la còpia de seguretat ha de rebre fitxers delta durant el temps que ha passat entre còpies de seguretat. En aquest cas, s'hauran d'afegir part de l'historial de manera massiva i analitzar-los, perquè no tot l'historial encaixa en grans segments. I només després d'això, la rèplica pot arxivar una còpia de seguretat delta completa.
Als gràfics tot sembla molt més senzill. Aquesta és una descàrrega d'un dels nostres clústers reals. Tenim basats en LSN, fets en un dia. I veiem que la còpia de seguretat delta basada en LSN funcionava des de les tres de la matinada fins a les cinc de la matinada. Aquesta és la càrrega en el nombre de nuclis de processador. WAL-delta ens va portar uns 20 minuts aquí, és a dir, es va fer molt més ràpid, però al mateix temps hi va haver un intercanvi més intens per la xarxa.
Com que tenim informació sobre quins blocs han canviat i en quin moment de l'historial de la base de dades, hem anat més enllà i hem decidit integrar la funcionalitat: una extensió PostgreSQL anomenada "pg_prefaulter".
Això vol dir que quan la base d'espera executa l'ordre de restauració, diu a WAL-G que recuperi el següent fitxer WAL. Entenem aproximadament a quins blocs de dades accedirà el procés de recuperació de WAL en un futur proper i iniciem una operació de lectura en aquests blocs. Això es va fer per augmentar el rendiment dels controladors SSD. Perquè el rotllo WAL arribarà a la pàgina que cal canviar. Aquesta pàgina està al disc i no es troba a la memòria cau de la pàgina. I esperarà de manera sincrònica que arribi aquesta pàgina. Però a prop hi ha WAL-G, que sap que en els propers centenars de megabytes de WAL necessitarem determinades pàgines i al mateix temps comença a escalfar-les. Inicia múltiples accessos al disc perquè s'executin en paral·lel. Això funciona bé a les unitats SSD, però, malauradament, no és absolutament aplicable a un disc dur, perquè només hi interferim amb les nostres indicacions.
Això és el que hi ha al codi ara.
Hi ha característiques que ens agradaria afegir.
Aquesta imatge mostra que WAL-delta triga un temps relativament curt. I això és llegir els canvis que es van produir a la base de dades durant el dia. Podríem fer WAL-delta no només de nit, perquè ja no és una font important de càrrega. Podem llegir WAL-delta cada minut perquè és barat. En un minut podem escanejar tots els canvis que s'han produït al clúster. I això es podria anomenar "WAL-delta instantani".
La qüestió és que quan restaurem el clúster, reduïm el nombre d'històries que hem d'enrotllar seqüencialment. És a dir, la quantitat de WAL que enrotlla PostgreSQL s'hauria de reduir, perquè requereix un temps important.
Però això no és tot. Si sabem que algun bloc es canviarà fins al punt de la consistència de la còpia de seguretat, no podem canviar-lo en el passat. És a dir, ara tenim l'optimització fitxer per fitxer del reenviament WAL-delta. Això vol dir que si, per exemple, un dimarts es va suprimir completament una taula o alguns fitxers es van suprimir completament de la taula, aleshores, quan el delta passi el dilluns i es restableixi el pg_basebackup del dissabte, ni tan sols crearem aquestes dades.
Volem estendre aquesta tecnologia al nivell de pàgina. És a dir, si una part del fitxer canvia dilluns, però se sobreescriurà dimecres, aleshores, quan es restaurà a un punt el dijous, no cal que escriguim les primeres versions de les pàgines al disc.
Però aquesta encara és una idea que s'està discutint activament dins nostre, però que encara no ha arribat al codi.
Volem fer una funció més a WAL-G. Volem fer-lo extensible perquè necessitem suportar diferents bases de dades i ens agradaria poder abordar la gestió de còpies de seguretat de la mateixa manera. Però el problema és que les API de MySQL són radicalment diferents. A MySQL, PITR no es basa en el registre WAL físic, sinó en el registre binari. I no tenim un sistema d'arxiu a MySQL que digui a algun sistema extern que aquest binlog està acabat i s'ha d'arxivar. Hem de situar-nos en algun lloc de cron amb la base de dades i comprovar si hi ha alguna cosa a punt?
I de la mateixa manera, durant una restauració de MySQL, no hi ha cap ordre de restauració que pugui dir al sistema que necessito tals o tals fitxers. Abans de començar a reconstruir el vostre clúster, heu de saber quins fitxers necessitareu. Vostè mateix ha d'endevinar quins fitxers necessitareu. Però aquests problemes es poden evitar d'alguna manera. (Aclariment: MySQL ja és compatible)
A l'informe també volia parlar d'aquells casos en què WAL-G no us convé.
Si no teniu una rèplica síncrona, WAL-G no garanteix que es preservi l'últim segment. I si l'arxiu queda endarrerit amb els últims segments de la història, això és un risc. Si no hi ha una rèplica síncrona, no recomanaria utilitzar WAL-G. Tot i així, està dissenyat principalment per a una instal·lació al núvol, la qual cosa implica una solució d'alta disponibilitat amb una rèplica síncrona, responsable de la seguretat dels últims bytes compromesos.
Sovint veig gent que intenta executar WAL-G i WAL-E alhora. Admetem la compatibilitat enrere en el sentit que WAL-G pot restaurar un fitxer de WAL-E i pot restaurar una còpia de seguretat feta a WAL-E. Però com que tots dos sistemes utilitzen wal-push paral·lel, comencen a robar fitxers l'un a l'altre. Si ho arreglem a WAL-G, encara romandrà a WAL-E. A WAL-E, mira l'estat de l'arxiu, veu els fitxers acabats i els arxiva, mentre que altres sistemes simplement no sabran que aquest fitxer WAL existia, perquè PostgreSQL no intentarà arxivar-lo una segona vegada.
Què arreglarem aquí al costat de WAL-G? No informarem a PostgreSQL que aquest fitxer s'ha transferit en paral·lel, i quan PostgreSQL ens demani que l'arxivem, ja sabrem que aquest fitxer amb aquest mode-time i amb aquest md5 ja s'ha arxivat i simplement direm PostgreSQL - D'acord, tot està preparat sense fer res.
Però és poc probable que aquest problema es solucioni al costat de WAL-E, de manera que actualment és impossible crear una ordre d'arxiu que arxivi el fitxer tant a WAL-G com a WAL-E.
A més, hi ha casos en què WAL-G no és adequat per a vostè ara, però definitivament ho solucionarem.
En primer lloc, actualment no tenim la verificació de còpia de seguretat integrada. No tenim verificació ni durant la còpia de seguretat ni durant la recuperació. Per descomptat, això s'implementa al núvol. Però això s'implementa simplement mitjançant una verificació prèvia, simplement restaurant el clúster. M'agradaria donar aquesta funcionalitat als usuaris. Però per verificació, suposo que a WAL-G serà possible restaurar el clúster i iniciar-lo, i executar proves de fum: pg_dumpall a /dev/null i verificació de l'índex amcheck.
Actualment a WAL-G no hi ha manera de posposar una còpia de seguretat de WAL. És a dir, donem suport a alguna finestra. Per exemple, emmagatzemar els darrers set dies, emmagatzemar les últimes deu còpies de seguretat, emmagatzemar les últimes tres còpies de seguretat completes. Molt sovint la gent ve i diu: "Necessitem una còpia de seguretat del que va passar l'any nou i volem mantenir-ho per sempre". WAL-G encara no pot fer-ho. (Nota: això ja s'ha solucionat. Més informació: opció de marca de còpia de seguretat a )
I no disposem de sumes de comprovació de pàgines i comprovacions d'integritat per a tots els segments d'eix quan validem PITR.
A partir de tot això vaig elaborar un projecte per a Google Summer of Code. Si coneixeu estudiants intel·ligents que els agradaria escriure alguna cosa a Go i obtenir milers de dòlars d'una empresa amb la lletra "G", recomaneu-los el nostre projecte. Faré de mentor d'aquest projecte, ells ho poden fer. Si no hi ha alumnes, l'agafaré i ho faré jo mateix a l'estiu.
I tenim molts altres petits problemes que poc a poc anem treballant. I passen coses força estranyes.
Per exemple, si doneu a WAL-G una còpia de seguretat buida, simplement caurà. Per exemple, si li dius que necessita fer una còpia de seguretat d'una carpeta buida. El fitxer pg_control no hi serà. I pensarà que no entén res. En teoria, en aquest cas cal escriure un missatge normal a l'usuari per explicar-li com utilitzar l'eina. Però això ni tan sols és una característica de la programació, sinó una característica d'un bon llenguatge intel·ligible.
No sabem com fer una còpia de seguretat fora de línia. Si la base de dades menteix, no podem fer-ne una còpia de seguretat. Però aquí tot és molt senzill. Demanem còpies de seguretat per LSN quan va començar. El LSN de la base subjacent s'ha de llegir des del fitxer de control. I aquesta és una característica tan no realitzada. Molts sistemes de còpia de seguretat poden fer una còpia de seguretat d'una base de dades subjacent. I és convenient.
Actualment no podem gestionar correctament la manca d'espai de còpia de seguretat. Perquè normalment treballem amb grans còpies de seguretat a casa. I no ho van aconseguir. Però si algú vol programar a Go ara mateix, afegiu la gestió d'errors fora d'espai al cub. Definitivament miraré la sol·licitud d'extracció.
I el que més ens preocupa és que volem tantes proves d'integració de docker com sigui possible que comprovin diferents escenaris. Ara mateix només estem provant escenaris bàsics. A cada commit, però volem comprovar commit per commit totes les funcionalitats que admetem. En particular, per exemple, tindrem prou suport per a PostgreSQL 9.4-9.5. Els donem suport perquè la comunitat admet PostgreSQL, però no comprovem commit-by-commit per assegurar-nos que no s'hagi trencat tot. I em sembla que això és un risc força greu.
Tenim WAL-G funcionant en més de mil clústers a la gestió de bases de dades Yandex. I fa una còpia de seguretat de diversos centenars de terabytes de dades cada dia.
Tenim moltes coses a fer al nostre codi. Si vols programar, vine, estem a l'espera de sol·licituds d'extracció, estem a l'espera de preguntes.
Les vostres preguntes
Bona nit! Gràcies! Suposo que si utilitzeu WAL-delta, probablement confieu molt en les escriptures de pàgina sencera. I si és així, vas fer proves? Has mostrat un gràfic preciós. Quant més bonic es torna si s'apaga FPW?
Les escriptures a pàgina sencera estan habilitades per a nosaltres, no hem intentat desactivar-les. És a dir, jo, com a desenvolupador, no he intentat desactivar-lo. Els administradors del sistema que han investigat probablement han investigat aquest problema. Però necessitem FPW. Gairebé ningú el desactiva, perquè en cas contrari és impossible fer una còpia de seguretat d'una rèplica.
Gràcies pel reportatge! Tinc dues preguntes. La primera pregunta és què passarà amb els tablespaces?
Estem esperant una sol·licitud d'extracció. Les nostres bases de dades viuen en discs SSD i NMVE i realment no necessitem aquesta funció. No estic disposat a passar un temps seriós ara mateix fent-ho bé. Defenso de tot cor que donem suport a això. Hi ha gent que ho va donar suport, però ho va donar suport d'una manera que els convingués. Van fer una bifurcació, però no fan sol·licituds d'extracció. (Afegit a la versió 0.2.13)
I la segona pregunta. Vostè va dir al principi que WAL-G suposa que funciona sol i que no calen embolcalls. Jo mateix faig servir embolcalls. Per què no s'han d'utilitzar?
Volem que sigui tan senzill com una balalaika. Això vol dir que no necessiteu res, excepte una balalaika. Volem que el sistema sigui senzill. Si teniu una funcionalitat que heu de fer en un script, veniu i digueu-nos-ho: ho farem a Go.
Bona nit! Gràcies pel reportatge! No hem pogut fer que WAL-G funcioni amb el desxifrat GPG. Xifra normalment, però no vol desxifrar. És una cosa que no ens ha funcionat? La situació és depriment.
Creeu un problema a GitHub i anem a resoldre'l.
És a dir, no us heu trobat amb això?
Hi ha una característica de l'informe d'error que quan WAL-G no entén quin tipus de fitxer és, pregunta: "Potser està xifrat?" Potser el problema no és el xifratge. Vull millorar el registre d'aquest tema. L'ha de desxifrar. Actualment estem treballant en aquest tema en el sentit que no ens agrada molt com està organitzat el sistema d'obtenció de claus públiques i privades. Perquè anomenem GPG extern perquè ens doni les seves claus. I després agafem aquestes claus i les transferim al GPG intern, que és PGP obert, que es compila per a nosaltres dins de WAL-G, i allà anomenem xifratge. En aquest sentit, volem millorar el sistema i volem donar suport al xifratge Libsodium (Afegit a la versió 0.2.15). Per descomptat, la descodificació hauria de funcionar, anem a esbrinar-ho: necessiteu més un símptoma que un parell de paraules. Pots reunir-te a la sala de l'altaveu en algun moment i mirar el sistema. (xifratge PGP sense GPG extern - v0.2.9)
Hola! Gràcies pel reportatge! Tinc dues preguntes. Tinc un desig estrany de fer la sessió pg_basebackup i WAL en dos proveïdors, és a dir, vull fer un núvol i un altre. Hi ha alguna manera de fer això?
Això no existeix ara, però és una idea interessant.
Simplement no confio en un proveïdor, vull tenir el mateix en un altre, per si de cas.
La idea és interessant. Tècnicament, això no és gens difícil d'implementar. Per evitar que es perdi la idea, puc demanar-vos que feu un problema a GitHub?
Sí, per descomptat.
I després, quan els alumnes vinguin a Google Summer of Code, els afegirem al projecte perquè hi hagi més feina per treure'n més profit.
I la segona pregunta. Hi ha un problema a GitHub. Crec que ja està tancat. Hi ha pànic durant la restauració. I per derrotar-lo, vau fer una assemblea a part. És correcte en els temes. I hi ha una opció per fer un entorn variable en un fil. I per això funciona molt lentament. I ens hem trobat amb aquest problema i encara no s'ha solucionat.
El problema és que per alguna raó l'emmagatzematge (CEPH) restableix la connexió quan hi arribem amb una alta concurrència. Què es pot fer al respecte? La lògica de reintentar té aquest aspecte. Estem intentant tornar a baixar el fitxer. En una passada, teníem una sèrie d'arxius no descarregats, en farem un segon per a tots aquells que no inicien sessió. I sempre que es carregui almenys un fitxer per iteració, repetim i repetim i repetim. Hem millorat la lògica del reintent: retrocés exponencial. Però no està del tot clar què fer amb el fet que la connexió simplement es trenqui al costat del sistema d'emmagatzematge. És a dir, quan pengem a un flux, no trenca aquestes connexions. Què podem millorar aquí? Tenim l'acceleració de la xarxa, podem limitar cada connexió pel nombre de bytes que envia. En cas contrari, no sé com fer front al fet que l'emmagatzematge d'objectes no ens permet descarregar-lo ni baixar-lo en paral·lel.
Sense SLA? No està escrit per a ells com es deixen turmentar?
La qüestió és que les persones que es plantegen aquesta pregunta solen tenir la seva pròpia volta. És a dir, ningú prové d'Amazon, Google Cloud o Yandex Object Storage.
Potser la pregunta ja no és per a tu?
La pregunta aquí en aquest cas no importa a qui. Si hi ha idees sobre com fer-ho, fem-ho a WAL-G. Però fins ara no tinc bones idees sobre com fer-ho. Hi ha alguns Object Storage que admeten les còpies de seguretat de llista de manera diferent. Els demaneu que llistin objectes i hi afegeixen una carpeta. WAL-G s'espanta per això: hi ha alguna cosa aquí que no és un fitxer, no el puc restaurar, la qual cosa significa que la còpia de seguretat no s'ha restaurat. És a dir, de fet, teniu un clúster completament restaurat, però us retorna un estat erroni perquè Object Storage ha retornat informació estranya que no entenia del tot.
Això és una cosa que passa al núvol de correu.
Si pots crear una reproducció...
Es reprodueix constantment...
Si hi ha una reproducció, crec que experimentarem amb estratègies de reintentar i descobrirem com tornar-ho a provar i entendre què ens requereix el núvol. Potser ens serà estable en tres connexions i no trencarà la connexió, aleshores arribarem amb cura a tres. Perquè ara deixem la connexió molt ràpidament, és a dir, si vam llançar una recuperació amb 16 fils, després del primer reintent hi haurà 8 fils, 4 fils, 2 fils i un. I després arrossegarà el fitxer en un sol flux. Si hi ha alguns valors màgics com 7,5 fils són els millors per bombar, llavors ens detenem en ells i intentarem fer altres 7,5 fils. Aquí tens una idea.
Gràcies pel reportatge! Com és un flux de treball complet per treballar amb WAL-G? Per exemple, en el cas estúpid quan no hi ha delta entre pàgines. I agafem i traiem la còpia de seguretat inicial, després arxivem l'eix fins que quedem blaus a la cara. Aquí, segons ho entenc, hi ha una ruptura. En algun moment haureu de fer una còpia de seguretat delta de les pàgines, és a dir, algun procés extern està impulsant això o com passa això?
L'API de còpia de seguretat delta és bastant senzilla. Hi ha un nombre: passos delta màxims, així s'anomena. Per defecte, és zero. Això vol dir que cada vegada que feu una còpia de seguretat, es descarrega una còpia de seguretat completa. Si el canvieu a qualsevol número positiu, per exemple, 3, la propera vegada que feu una còpia de seguretat-push, examinarà l'historial de còpies de seguretat anteriors. Veu que no superes la cadena de 3 deltes i fa un delta.
És a dir, cada vegada que iniciem WAL-G, intenta fer una còpia de seguretat completa?
No, executem WAL-G i intenta fer un delta si les vostres polítiques ho permeten.
A grans trets, si l'executeu amb zero cada vegada, es comportarà com pg_basebackup?
No, encara funcionarà més ràpid perquè utilitza compressió i paral·lelisme. Pg_basebackup posarà l'eix al teu costat. WAL-G assumeix que tens l'arxiu configurat. I emetrà un avís si no està configurat.
Pg_basebackup es pot executar sense eixos.
Sí, llavors es comportaran gairebé igual. Pg_basebackup còpies al sistema de fitxers. Per cert, tenim una nova característica que em vaig oblidar d'esmentar. Ara podem fer una còpia de seguretat al sistema de fitxers des de pg_basebackup. No sé per què és necessari, però hi és.
Per exemple, a CephFS. No tothom vol configurar l'emmagatzematge d'objectes.
Sí, probablement per això van fer una pregunta sobre aquesta funció perquè ho poguéssim fer. I ho vam fer.
Gràcies pel reportatge! Només hi ha una pregunta sobre la còpia al sistema de fitxers. Des de la caixa, ara admet la còpia a l'emmagatzematge remot, per exemple, si hi ha algun prestatge al centre de dades o alguna cosa més?
En aquesta formulació, aquesta és una pregunta difícil. Sí, donem suport, però aquesta funcionalitat encara no està inclosa en cap versió. És a dir, totes les versions prèvies ho admeten, però les versions de llançament no. Aquesta funcionalitat es va afegir a la versió 0.2. Definitivament es publicarà aviat, tan bon punt corregim tots els errors coneguts. Però ara mateix això només es pot fer en la versió prèvia. Hi ha dos errors a la versió prèvia. Problema amb la recuperació de WAL-E, no l'hem solucionat. I a la darrera versió prèvia es va afegir un error sobre la còpia de seguretat delta. Per tant, recomanem a tothom que utilitzi les versions de llançament. Tan bon punt no hi hagi més errors a la versió prèvia, podem dir que admetem Google Cloud, coses compatibles amb S3 i emmagatzematge de fitxers.
Hola, gràcies per l'informe. Segons tinc entès, WAL-G no és una mena de sistema centralitzat com els barmans? Teniu previst avançar en aquesta direcció?
El problema és que ens hem allunyat d'aquesta direcció. WAL-G viu a l'amfitrió base, a l'amfitrió del clúster i a tots els amfitrions del clúster. Quan ens vam traslladar a diversos milers de clústers, teníem moltes instal·lacions de barman. I cada vegada que alguna cosa s'esfondra en ells, és un gran problema. Com que s'han de reparar, cal entendre quins clústers ara no tenen còpies de seguretat. No penso desenvolupar WAL-G en la direcció del maquinari físic per a sistemes de còpia de seguretat. Si la comunitat vol alguna funcionalitat aquí, no m'importa gens.
Tenim equips responsables de l'emmagatzematge. I ens sentim tan bé que no som nosaltres, que hi ha gent especial que posa els nostres fitxers on els fitxers estan segurs. Hi fan tot tipus de codificació intel·ligent per suportar la pèrdua d'un cert nombre de fitxers. Són els responsables de l'ample de banda de la xarxa. Quan tens un cambrer, és possible que de sobte descobreixis que petites bases de dades amb molt trànsit s'han reunit al mateix servidor. Sembla que hi tens molt d'espai, però per alguna raó tot no encaixa a la xarxa. Pot resultar al revés. Hi ha moltes xarxes allà, hi ha nuclis de processador, però aquí no hi ha discs. I ens vam cansar d'aquesta necessitat de fer malabars amb alguna cosa, i vam passar al fet que l'emmagatzematge de dades és un servei independent, del qual són responsables diferents persones especials.
PS S'ha publicat una nova versió , en què podeu utilitzar el fitxer de configuració .walg.json, que es troba al directori inicial de postgres de manera predeterminada. Podeu abandonar els scripts bash. L'exemple .walg.json es troba en aquest problema
Vídeo:
Font: www.habr.com