Ech proposéieren Iech den Transkript vum Bericht vum Ufank vum 2019 vum Andrey Borodin "Backups mat WAL-G. Wat ass do am Joer 2019?"
Moien alleguer! Mäin Numm ass Andrey Borodin. Ech sinn en Entwéckler bei Yandex. Ech sinn zënter 2016 u PostgreSQL interesséiert, nodeems ech mat den Entwéckler geschwat hunn a si soten datt alles einfach ass - Dir huelt de Quellcode a baut et, an alles funktionnéiert. An zënterhier kann ech net ophalen - ech schreiwen all aner Saachen.
Eng vun de Saachen un deenen ech schaffen ass e Backupsystem. . Am Allgemengen, bei Yandex hu mir fir eng ganz laang Zäit u Backupsystemer am PostgreSQL geschafft. An Dir fannt um Internet eng Serie vu sechs Berichter iwwer wéi mir Backupsystemer maachen. An all Joer entwéckelen se e bëssen, entwéckelen e bëssen, a ginn méi zouverlässeg.
Mee haut geet et am Rapport net nëmmen ëm dat wat mir gemaach hunn, mee och ëm wéi einfach et ass a wat ass. Wéi vill vun iech hu scho meng Berichter iwwer WAL-G gekuckt? Et ass gutt, datt eng ganz Rei Leit net gekuckt hunn, well ech fänken un mat deem einfachsten.
Wann Dir op eemol e PostgreSQL-Cluster hutt, an ech mengen datt jiddereen e puer vun hinnen mat hinnen huet, an op eemol gëtt et nach kee Backup-System, da musst Dir all S3-Speicher oder Google Cloud-kompatibel Späichere kréien.
Zum Beispill kënnt Dir op eise Stand kommen an e Promotiounscode fir Yandex Object Storage huelen, wat S3 kompatibel ass.
Dann erstellt en Eemer. Et ass just e Container fir Informatioun.
Erstellt e Service Benotzer.
Erstellt en Zougangsschlëssel fir de Service Benotzer: aws-s3-key.
Luet déi lescht stabil Verëffentlechung vu WAL-G erof.
Wéi sinn eis Pre-Releases anescht wéi Releases? Ech ginn dacks gefrot fir fréi ze befreien. A wann et kee Feeler an der Versioun fir eng genuch Zäit ass, zum Beispill e Mount, da verëffentlechen ech et. Hei ass dës Verëffentlechung vum November. An dëst bedeit datt mir all Mount eng Aart vu Käfer fonnt hunn, normalerweis an net-kritescher Funktionalitéit, awer mir hunn nach keng Verëffentlechung verëffentlecht. Déi viregt Versioun ass nëmmen November. Et gi keng Bugs bekannt fir eis an et, dat heescht Bugs goufen dobäi wéi de Projet Fortschrëtt.
Wann Dir WAL-G erofgelueden hutt, kënnt Dir en einfachen "Backup Lëscht" Kommando lafen, an d'Ëmfeldvariablen passéieren. An et wäert mat Object Storage verbannen an Iech soen wéi eng Backups Dir hutt. Am Ufank, natierlech, sollt Dir keng Backups hunn. De Punkt vun dëser Rutsch ass ze weisen datt alles ganz einfach ass. Dëst ass e Konsolbefehl deen Ëmfeldvariablen acceptéiert an Ënnerbefehle ausféiert.
Duerno kënnt Dir Ären éischte Backup maachen. Sot "Backup-Push" am WAL-G a spezifizéiert am WAL-G d'Pgdata-Plaz vun Ärem Cluster. A wahrscheinlech wäert PostgreSQL Iech soen, wann Dir net schonn e Backup-System hutt, datt Dir "Archivmodus" aktivéiere musst.
Dëst bedeit datt Dir an d'Astellunge gitt an "archive_mode = on" ausschalten an "archive_command" addéieren, wat och en Ënnerkommando am WAL-G ass. Awer aus e puer Grënn benotzen d'Leit dacks Bar Scripten iwwer dëst Thema a wéckelen et ëm WAL-G. Maacht dat w.e.g. net. Benotzt d'Funktionalitéit déi am WAL-G fonnt gëtt. Wann Dir eppes vermësst, schreift Iech un . WAL-G gëtt ugeholl datt et deen eenzege Programm ass deen am archive_command leeft.
Mir benotzen WAL-G haaptsächlech fir en High Availability Cluster am Yandex Datebankmanagement ze kreéieren.
An et gëtt normalerweis an enger Topologie vun engem Master a verschidde Replikatiounen benotzt. Zur selwechter Zäit mécht et eng Backupkopie an Yandex Object Storage.
Déi heefegst Szenarie sinn d'Erstelle vun Kopien vun engem Stärekoup mat Hëllef vun der Zäit Erhuelung. Awer an dësem Fall ass d'Performance vum Backup-System net sou wichteg fir eis. Mir brauche just en neie Stärekoup aus dem Backup eropzelueden.
Typesch brauche mir d'Backup-Systemleistung wann Dir en neien Node bäidréit. Firwat ass et wichteg? Typesch fügen d'Leit en neien Node un e Cluster bäi, well de existente Cluster d'Lieslaascht net handhaben kann. Si mussen eng nei Replika derbäisetzen. Wa mir d'Laascht vum pg_basebackup zum Master addéieren, da kann de Master zesummeklappen. Dofir war et ganz wichteg fir eis datt mir séier en neien Node aus dem Archiv eropluede konnten, a minimal Belaaschtung op de Master erstellen.
An eng aner ähnlech Situatioun. Dëst ass de Besoin fir den alen Master nei ze starten nodeems de Cluster Master aus dem Data Center gewiesselt gouf, mat deem d'Konnektivitéit verluer ass.
- Als Resultat, wann Dir d'Ufuerderunge fir de Kopiesystem formuléiert, hu mir gemierkt datt pg_basebackup net gëeegent ass fir eis wann Dir an der Wollek funktionnéiert.
- Mir wollten eis Donnéeë kënnen kompriméieren. Awer bal all Backup System anescht wéi dat wat an der Këscht kënnt, gëtt Datekompressioun.
- Mir wollten alles paralleliséieren, well e Benotzer an der Wollek eng grouss Zuel vu Prozessorkäre kaaft. Awer wa mir keng Parallelismus an enger Operatioun hunn, da gëtt eng grouss Zuel vu Kären nëtzlos.
- Mir brauche Verschlësselung well dacks sinn d'Donnéeën net eis a kënnen net am Kloertext gespäichert ginn. Eise Bäitrag zu WAL-G huet iwwregens mat der Verschlësselung ugefaang. Mir hunn d'Verschlësselung am WAL-G ofgeschloss, duerno goufe mir gefrot: "Vläicht wäert ee vun eis de Projet entwéckelen?" An zënterhier schaffen ech fir méi wéi engem Joer mat WAL-G.
- Mir hunn och d'Ressource-Throttling gebraucht, well mat der Zäit mat der Wollek hu mir erausfonnt datt heiansdo d'Leit eng wichteg Epicerie an der Nuecht hunn an dës Belaaschtung net kann gestéiert ginn. Dofir hu mir Ressource Drossel bäigefüügt.
- Souwéi Oplëschtung a Gestioun.
- An d'Verifikatioun.
Mir hunn vill verschidden Tools gekuckt. Glécklech hu mir eng rieseg Auswiel am PostgreSQL. An iwwerall hu mir eppes gefeelt, eng kleng Funktioun, eng kleng Feature.
An déi bestehend Systemer iwwerpréift, si mir zu der Conclusioun komm, datt mir WAL-G entwéckelen. Et war deemools en neie Projet. Et war ganz einfach d'Entwécklung Richtung Cloud Infrastruktur vum Backup System ze beaflossen.
D'Haaptideologie déi mir halen ass datt WAL-G sou einfach wéi eng Balalaika soll sinn.
WAL-G huet 4 Kommandoen. Dëst:
WAL-PUSH - archivéiert de Schaft.
WAL-FETCH - kritt e Schaft.
BACKUP-PUSH - maacht e Backup.
BACKUP-FETCH - kritt e Backup vum Backup System.
Tatsächlech huet WAL-G och d'Gestioun vun dëse Backups, dh records a Backups an der Geschicht oplëschten an ze läschen, déi am Moment net méi gebraucht ginn.
Eng vun de wichtege Funktiounen fir eis ass d'Funktioun fir Delta Kopien ze kreéieren.
Delta-Kopie bedeit datt mir net e komplette Backup vum ganze Cluster erstellen, awer nëmmen déi geännert Säiten vun de geännerten Dateien am Cluster. Et géif schéngen datt dëst funktionell ganz ähnlech ass mat der Fäegkeet fir mat WAL ze recuperéieren. Awer mir kënnen e WAL Single-threaded Delta Backup parallel oprollen. Deementspriechend, wa mir e Samschdeg Basis Backup gemaach hunn, Delta-Backups all Dag, an en Donneschdeg versoen, da musse mir 4 Delta-Backups an 10 Stonnen WAL oprollen. Et wäert ongeféier déiselwecht Zäit daueren well d'Delta-Backups parallel rullen.
LSN-baséiert Deltas - dëst bedeit datt wann Dir e Backup erstellt, mir all Säit musse kombinéieren a seng LSN mam LSN vum fréiere Backup kontrolléieren fir ze verstoen datt et geännert huet. All Säit, déi potenziell geännert Donnéeën enthalen kéint, sollt am Delta-Backup präsent sinn.
Wéi gesot, ganz vill Opmierksamkeet gouf op Parallelismus bezuelt.
Awer d'Archiv API am PostgreSQL ass konsequent. PostgreSQL archivéiert eng WAL-Datei a beim Restauréieren freet se eng WAL-Datei. Awer wann d'Datebank eng WAL-Datei mat dem Kommando "WAL-FETCH" freet, ruffe mir de Kommando "WAL-PREFETCH", deen déi nächst 8 Dateie virbereet fir Daten aus dem Objektgeschäft parallel ze sichen.
A wann d'Datebank eis freet eng Datei ze archivéieren, kucken mir op archive_status a kucken ob et aner WAL Dateien gëtt. A mir probéieren och WAL parallel erofzelueden. Dëst bitt e wesentleche Leeschtungsgewënn a reduzéiert d'Distanz wesentlech an der Unzuel vun unarchivéierten WALs. Vill Backup System Entwéckler gleewen datt dëst esou e riskante System ass well mir op eist Wëssen iwwer d'Internal vum Code vertrauen, deen net de PostgreSQL API ass. PostgreSQL garantéiert net d'Präsenz vum archive_status Dossier fir eis a garantéiert net d'Semantik, d'Präsenz vu Bereetschaftssignaler fir WAL Dateien do. Trotzdem studéiere mir de Quellcode, mir gesinn datt dëst esou ass a mir probéieren et auszenotzen. A mir kontrolléieren d'Richtung an där PostgreSQL sech entwéckelt; wann op eemol dëse Mechanismus gebrach ass, stoppen mir et ze benotzen.
A senger reiner Form erfuerdert LSN-baséiert WAL Delta all Clusterdatei ze liesen, deem seng Moduszäit am Dateiesystem zënter dem fréiere Backup geännert huet. Mir gelieft mat dëser fir eng laang Zäit, bal engem Joer. An um Enn si mir zu der Conclusioun komm, datt mir WAL Deltas hunn.
Dëst bedeit datt all Kéier wann mir WAL op de Master archivéieren, mir kompriméieren et net nëmmen, verschlësselen et an d'Netzwierk schécken, awer mir liesen et och zur selwechter Zäit. Mir analyséieren a liesen d'Records an et. Mir verstinn wéi eng Blocks geännert hunn a sammelen Delta Dateien.
Eng Delta-Datei beschreift eng bestëmmte Gamme vu WAL-Dateien, beschreift Informatiounen iwwer wéi eng Blöcke an dëser Gamme vu WAL geännert goufen. An da ginn dës Delta-Dateien och archivéiert.
Hei si mir konfrontéiert mat der Tatsaach, datt mir alles relativ séier paralleliséiert hunn, awer mir kënnen eng sequenziell Geschicht net parallel liesen, well mir an engem bestëmmte Segment d'Enn vum fréiere WAL-Rekord begéinen, mat deem mir nach näischt ze verbannen hunn, well Parallelliesen huet dozou gefouert, datt mir als éischt d'Zukunft analyséieren, déi nach keng Vergaangenheet huet.
Als Resultat hu mir onverständlech Stécker an _delta_partial Dateien missen setzen. Als Resultat, wa mir zréck an d'Vergaangenheet zréckkommen, wäerte mir d'Stécker vum WAL-Rekord an een pechen, duerno wäerte mir et parséieren a verstoen wat dran geännert huet.
Wann et an der Geschicht vun eisem Schachtparsing op d'mannst ee Punkt ass, wou mir net verstinn wat geschitt ass, da wäerte mir deementspriechend während dem nächste Backup gezwongen sinn de ganze Cluster erëm ze liesen, sou wéi mir et mat engem normale LSN gemaach hunn. -baséiert Delta.
Als Resultat hunn all eis Leed zu der Tatsaach gefouert datt mir d'WAL-G Parsingbibliothéik opgemaach hunn. Souwäit ech weess, benotzt nach keen et, awer wann iergendeen et wëllt, schreiwen a benotzen, ass et am Domaine public. (Update Link )
Als Resultat gesinn all Informatiounsfloss zimlech komplizéiert aus. Eise Master archivéiert de Schaft an archivéiert Deltadateien. An d'Replique, déi d'Backupkopie mécht, muss Delta-Dateien während der Zäit kréien, déi tëscht de Backups vergaang ass. An dësem Fall mussen Deeler vun der Geschicht a Mass dobäigesat ginn a parséiert ginn, well net déi ganz Geschicht a grouss Segmenter passt. An nëmmen duerno kann d'Replika e vollen Delta-Backup archivéieren.
Op de Grafike gesäit alles vill méi einfach aus. Dëst ass en Download vun engem vun eise richtege Cluster. Mir hunn LSN-baséiert, an engem Dag gemaach. A mir gesinn datt den LSN-baséierten Delta-Backup vun dräi moies bis fënnef moies leeft. Dëst ass d'Laascht an der Unzuel vun de Prozessorkären. D'WAL-Delta huet eis hei ongeféier 20 Minutten gedauert, dat heescht, et gouf däitlech méi séier, awer gläichzäiteg gouf et méi intensiven Austausch iwwer d'Netz.
Well mir Informatioun hunn iwwer wéi eng Blocks geännert hunn a wéi eng Zäit an der Geschicht vun der Datebank, si mir méi wäit gaang an hu beschloss Funktionalitéit z'integréieren - eng PostgreSQL Extensioun genannt "pg_prefaulter"
Dëst bedeit datt wann d'Stand-by-Basis de Restauratiounskommando ausféiert, seet et WAL-G fir déi nächst WAL-Datei ze sichen. Mir verstinn ongeféier wéi eng Dateblocken de WAL Erhuelungsprozess an der nächster Zukunft zougräifen an eng Liesoperatioun op dëse Blocken initiéieren. Dëst gouf gemaach fir d'Performance vun SSD Controller ze erhéijen. Well d'WAL Roll wäert d'Säit erreechen déi geännert muss ginn. Dës Säit ass op Disk an ass net am Säit Cache. An hie wäert synchron op dës Säit waarden fir ze kommen. Awer an der Géigend ass WAL-G, dee weess datt mir an den nächste puer honnert Megabyte vu WAL verschidde Säite brauchen a gläichzäiteg ufänkt se ze waarm ze ginn. Initiéiert verschidde Disk-Zougäng sou datt se parallel ausgefouert ginn. Dëst funktionnéiert gutt op SSD-Laufwerke, awer, leider, ass et absolut net uwendbar fir eng Festplack, well mir nëmmen mat eise Prompts stéieren.
Dëst ass wat elo am Code steet.
Et gi Funktiounen déi mir gären derbäisetzen.
Dëst Bild weist datt WAL-Delta relativ kuerz Zäit dauert. An dëst liest d'Ännerungen, déi am Dag an der Datebank geschitt sinn. Mir kéinten WAL-Delta net nëmmen an der Nuecht maachen, well et net méi eng bedeitend Belaaschtungsquell ass. Mir kënnen all Minutt WAL-Delta liesen well et bëlleg ass. An enger Minutt kënne mir all d'Ännerungen scannen, déi am Cluster geschitt sinn. An dëst kéint "Instant WAL-Delta" genannt ginn.
De Punkt ass datt wa mir de Stärekoup restauréieren, mir d'Zuel vun de Geschichten reduzéieren déi mir sequenziell musse rullen. Dat ass, d'Quantitéit u WAL déi PostgreSQL rullt soll reduzéiert ginn, well et bedeitend Zäit brauch.
Mä dat ass net alles. Wa mir wëssen datt e puer Block op de Punkt vun der Backupkonsistenz geännert gëtt, kënne mir et an der Vergaangenheet net änneren. Dat ass, elo hu mir Datei-vun-Datei Optimiséierung vum WAL-Delta Forwarding. Dëst bedeit datt wann zum Beispill en Dënschdeg en Dësch komplett geläscht gouf oder e puer Dateie ganz aus dem Dësch geläscht goufen, da wann Delta um Méindeg a Samschdeg de pg_basebackup restauréiert gëtt, wäerte mir dës Donnéeën net emol erstellen.
Mir wëllen dës Technologie op de Säitniveau verlängeren. Dat ass, wann en Deel vun der Datei e Méindeg ännert, awer e Mëttwoch iwwerschriwwe gëtt, dann, wann Dir en Donneschdeg op e Punkt restauréiert, brauche mir net déi éischt puer Versioune vu Säiten op Disk ze schreiwen.
Awer dëst ass nach ëmmer eng Iddi déi aktiv an eis diskutéiert gëtt, awer et ass nach net de Code erreecht.
Mir wëllen eng méi Feature am WAL-G maachen. Mir wëllen et erweiderbar maachen, well mir verschidde Datenbanken ënnerstëtzen a gäre fäeg sinn d'Backupmanagement op déiselwecht Manéier unzegoen. Awer de Problem ass datt d'MySQL APIs radikal anescht sinn. Am MySQL baséiert PITR net op de kierperleche WAL Log, mee um Binlog. A mir hu keen Archivsystem an MySQL, deen e puer externe System soen datt dëse Binlog fäerdeg ass a muss archivéiert ginn. Mir mussen iergendwou am Cron mat der Datebank stoen a kucken ob et eppes prett ass?
An déiselwecht Manéier, während enger MySQL Restauratioun, gëtt et kee Restauratiounskommando, deen dem System kéint soen datt ech esou an esou Dateien brauch. Ier Dir ufänkt Äre Stärekoup nei opzebauen, musst Dir wësse wéi eng Dateien Dir braucht. Dir musst selwer roden wat fir Dateien Dir braucht. Awer dës Probleemer kënnen iergendwéi ëmgoen. (Klärung: MySQL gëtt scho ënnerstëtzt)
Am Bericht wollt ech och iwwer déi Fäll schwätzen, wou WAL-G Iech net gëeegent ass.
Wann Dir keng Synchron-Replique hutt, garantéiert WAL-G net datt de leschte Segment erhale bleift. A wann d'Archivéierung hannert de leschte Segmenter vun der Geschicht bleift, ass dat e Risiko. Wann et keng synchron Replika ass, géif ech net recommandéieren WAL-G ze benotzen. Trotzdem ass et haaptsächlech fir eng Cloudinstallatioun entworf, wat eng High Availability-Léisung mat enger synchroner Replik implizéiert, déi verantwortlech ass fir d'Sécherheet vun de leschten engagéierte Bytes.
Ech gesinn dacks Leit déi probéieren souwuel WAL-G wéi och WAL-E zur selwechter Zäit ze lafen. Mir ënnerstëtzen Réckkompatibilitéit am Sënn datt WAL-G e Fichier vu WAL-E restauréiere kann an e Backup aus WAL-E restauréiere kann. Awer well béid vun dëse Systemer parallel Wal-Push benotzen, fänken se un Dateie vuneneen ze klauen. Wa mir et am WAL-G fixéieren, bleift et nach ëmmer am WAL-E. A WAL-E kuckt en den Archivstatus, gesäit déi fäerdeg Dateien an archivéiert se, während aner Systemer einfach net wëssen datt dës WAL Datei existéiert, well PostgreSQL probéiert se net eng zweete Kéier ze archivéieren.
Wat wäerte mir hei op der WAL-G Säit fixéieren? Mir wäerten PostgreSQL net informéieren datt dës Datei parallel transferéiert gouf, a wann PostgreSQL eis freet se ze archivéieren, wësse mer schonn datt esou e Fichier mat dëser Moduszäit a mat dëser md5 scho archivéiert gouf a mir soen einfach PostgreSQL - OK, alles ass prett ouni wesentlech eppes ze maachen.
Awer dëse Problem ass onwahrscheinlech op der WAL-E Säit fixéiert ze ginn, sou datt et am Moment onméiglech ass en Archivbefehl ze kreéieren deen d'Datei souwuel a WAL-G a WAL-E archivéiert.
Zousätzlech ginn et Fäll wou WAL-G elo net fir Iech gëeegent ass, awer mir wäerten et definitiv fixéieren.
Als éischt hu mir de Moment keng agebaute Backupverifikatioun. Mir hu keng Verifizéierung weder beim Backup oder Erhuelung. Natierlech gëtt dëst an der Wollek ëmgesat. Awer dëst gëtt einfach duerch Pre-Check ëmgesat, einfach andeems Dir de Cluster restauréiert. Ech wéilt dës Funktionalitéit un d'Benotzer ginn. Awer duerch Verifizéierung huelen ech un datt et am WAL-G méiglech ass de Stärekoup ze restauréieren an ze starten, a lafen Damptester: pg_dumpall zu /dev/null an amcheck Indexverifikatioun.
De Moment am WAL-G gëtt et kee Wee fir ee Backup vu WAL auszestellen. Dat ass, mir ënnerstëtzen e puer Fënster. Zum Beispill, déi lescht siwen Deeg späicheren, déi lescht zéng Backups späicheren, déi lescht dräi voll Backups späicheren. Ganz dacks kommen d'Leit a soen: "Mir brauchen e Backup vun deem wat am Neie Joer geschitt ass a mir wëllen et fir ëmmer halen." WAL-G kann dat nach net maachen. (Note - Dëst ass scho fixéiert. Weiderliesen - Backup-Mark Optioun an )
A mir hu keng Säitchecksummen an Integritéitschecken fir all Schaftsegmenter wann Dir PITR validéiert.
Vun all deem hunn ech e Projet fir Google Summer of Code zesummegesat. Wann Dir schlau Studenten kennt, déi gären eppes am Go schreiwen an e puer dausend Dollar vun enger Firma mam Bréif "G" kréien, da empfeelt hinnen eise Projet. Ech wäert als Mentor fir dëse Projet handelen, si kënnen et maachen. Wann et keng Schüler sinn, da wäert ech et huelen an et selwer am Summer maachen.
A mir hu vill aner kleng Problemer, un déi mir no an no schaffen. An e puer flott komesch Saachen geschéien.
Zum Beispill, wann Dir WAL-G en eidele Backup gëtt, da wäert et einfach falen. Zum Beispill, wann Dir him sot datt hien en eidelen Dossier muss backen. D'pg_control Datei wäert net do sinn. An hie wäert mengen datt hien eppes net versteet. An der Theorie, an dësem Fall musst Dir e normale Message un de Benotzer schreiwen fir him z'erklären wéi een den Tool benotzt. Awer dëst ass net emol eng Feature vun der Programméierung, mee eng Feature vun enger gudder, verständlecher Sprooch.
Mir wëssen net wéi een offline Backup mécht. Wann d'Datebank läit, kënne mir se net backen. Awer hei ass alles ganz einfach. Mir ruffen Backups vun LSN wann et ugefaang. Den LSN vun der Basisdaten Basis muss aus der Kontrolldatei gelies ginn. An dëst ass sou eng onrealiséiert Feature. Vill Backupsystemer kënnen eng Basisdatenbank backen. An et ass bequem.
Mir kënnen am Moment de Mangel u Backupplatz net richteg handhaben. Well mir schaffen normalerweis mat grousse Backups doheem. A si hunn et net ëmkomm. Awer wann iergendeen elo am Go programméiere wëllt, füügt Handhabung fir ausserhalb-Raumfehler un den Eemer. Ech wäert definitiv d'Pull Ufro kucken.
An d'Haapt Saach, déi eis Suergen ass, ass datt mir sou vill wéi méiglech Docker Integratiounstester wëllen, déi verschidde Szenarie kontrolléieren. De Moment testen mir nëmmen Basisszenarien. Op all Verpflichtung, awer mir wëllen eng Verpflichtung-fir-Verpflichtung all d'Funktionalitéit kontrolléieren déi mir ënnerstëtzen. Besonnesch, zum Beispill, wäerte mir genuch Ënnerstëtzung fir PostgreSQL 9.4-9.5 hunn. Mir ënnerstëtzen se well d'Communautéit PostgreSQL ënnerstëtzt, awer mir iwwerpréiwen net commit-by-commit fir sécher ze stellen datt alles net gebrach ass. An et schéngt mir, datt dëst en zimlech eeschte Risiko ass.
Mir hunn WAL-G op méi wéi dausend Stärekéip am Yandex Datebankmanagement lafen. An et mécht all Dag e puer honnert Terabytes vun Daten zréck.
Mir hu vill TODO an eisem Code. Wann Dir wëllt programméiere, kommt, mir waarden op Pull-Ufroen, mir waarden op Froen.
Är Froen
Gudden Owend! Merci! Meng roden ass datt wann Dir WAL-Delta benotzt, vertrauen Dir wahrscheinlech staark op voll Säit Schreiwen. A wa jo, hutt Dir Tester gemaach? Du hues eng schéin Grafik gewisen. Wéi vill méi schéin gëtt et wann FPW ausgeschalt ass?
Voll Säit Schreiwen ass fir eis aktivéiert, mir hunn net probéiert et auszeschalten. Dat ass, ech, als Entwéckler, hunn net probéiert et auszeschalten. System Administrateuren déi recherchéiert hunn hu wahrscheinlech dëst Thema recherchéiert. Mee mir brauchen FPW. Bal keen deaktivéiert et, well soss ass et onméiglech fir e Backup vun enger Replika ze huelen.
Merci fir de Bericht! Ech hunn zwou Froen. Déi éischt Fro ass wat geschitt mat Tablespaces?
Mir waarden op eng Pull Ufro. Eis Datenbanken liewen op SSD an NMVE Disken a mir brauchen dës Feature net wierklech. Ech sinn net prett fir seriös Zäit elo ze verbréngen fir et gutt ze maachen. Ech plädéiere ganz härzlech fir datt mir dat ënnerstëtzen. Et gi Leit, déi et ënnerstëtzt hunn, awer et op eng Manéier ënnerstëtzt hunn, déi hinnen passt. Si hunn eng Gabel gemaach, awer si maachen keng Pull-Ufroen. (An der Versioun 0.2.13 bäigefüügt)
An déi zweet Fro. Dir sot ganz am Ufank datt WAL-G dovun ausgoen datt et eleng funktionnéiert a keng Wrappers gebraucht ginn. Ech benotzen wrappers selwer. Firwat sollten se net benotzt ginn?
Mir wëllen datt et sou einfach ass wéi eng Balalaika. Dëst bedeit datt Dir guer näischt braucht ausser eng Balalaika. Mir wëllen datt de System einfach ass. Wann Dir Funktionalitéit hutt déi Dir an engem Skript maache musst, da kommt a sot eis - mir maachen et am Go.
Gudden Owend! Merci fir de Bericht! Mir konnten WAL-G net kréien fir mat GPG Entschlësselung ze schaffen. Et verschlësselt normalerweis, awer wëllt net entschlësselen. Ass et eppes wat fir eis net geklappt huet? D'Situatioun ass depriméierend.
Erstellt en Thema op GitHub a loosst eis et erausfannen.
Dat ass, Dir hutt dëst net begéint?
Et gëtt eng Feature vum Feelerbericht datt wann WAL-G net versteet wéi eng Datei et ass, freet se: "Vläicht ass et verschlësselt?" Vläicht ass de Problem guer net Verschlësselung. Ech wëll de Logbicher iwwer dëst Thema verbesseren. Hie muss et entzifferen. Mir schaffen am Moment un dësem Thema am Sënn datt mir net wierklech gär hunn wéi de System fir ëffentlech a privat Schlësselen ze kréien organiséiert ass. Well mir nennen extern GPG sou datt et eis seng Schlësselen gëtt. An dann huelen mir dës Schlësselen an iwwerdroen se op den internen GPG, deen oppe PGP ass, dee fir eis am WAL-G kompiléiert ass, an do nennen mir Verschlësselung. An dëser Hisiicht wëlle mir de System verbesseren a wëlle Libsodium Verschlësselung ënnerstëtzen (Addéiert an der Versioun 0.2.15). Natierlech soll d'Dekodéierung funktionnéieren, loosst eis et erausfannen - Dir braucht méi e Symptom wéi e puer Wierder. Dir kënnt iergendwann am Speakerzëmmer versammelen an de System kucken. (PGP Verschlësselung ouni extern GPG - v0.2.9)
Hallo! Merci fir de Bericht! Ech hunn zwou Froen. Ech hunn e komeschen Wonsch pg_basebackup an WAL aloggen zwee Provider ze maachen, dh ech wëll eng Wollek an aner maachen. Gëtt et e Wee fir dëst ze maachen?
Dëst gëtt et elo net, awer et ass eng interessant Iddi.
Ech vertrauen just net engem Provider, Ech wëll déi selwecht an engem aneren hunn, just am Fall.
D'Iddi ass interessant. Technesch ass dëst guer net schwéier ze realiséieren. Fir ze vermeiden datt d'Iddi verluer geet, kann ech Iech froen en Thema op GitHub ze maachen?
Jo natierlech.
An dann, wann d'Studenten op Google Summer of Code kommen, wäerte mir se an de Projet bäidroen, fir datt et méi Aarbecht gëtt fir méi aus hinnen ze kréien.
An déi zweet Fro. Et gëtt en Thema op GitHub. Ech mengen et ass scho zou. Et gëtt Panik wärend der Restauratioun. A fir et ze besiegen, hutt Dir eng separat Versammlung gemaach. Et ass richteg an Themen. An et gëtt eng Optioun fir e variabelt Ëmfeld an engem Fuedem ze maachen. An dofir funktionnéiert et ganz lues. A mir hunn dëse Problem begéint, an et ass nach net fixéiert ginn.
De Problem ass datt aus irgendege Grënn d'Späichere (CEPH) d'Verbindung zrécksetzen wa mir mat héijer Konkurrenz kommen. Wat kann iwwer dëst gemaach ginn? D'Retry Logik gesäit esou aus. Mir probéieren d'Datei nach eng Kéier erofzelueden. An engem Pass hate mir eng Rei Dateien net erofgelueden, mir maachen eng zweet fir all déi déi net ageloggt hunn. A soulaang op d'mannst eng Datei pro Iteratioun gelueden ass, widderhuelen mir a widderhuelen a widderhuelen. Mir hunn d'Logik vum Retry verbessert - exponentiell Réckzuch. Awer et ass net ganz kloer wat mat der Tatsaach ze maachen datt d'Verbindung einfach op der Säit vum Späichersystem brécht. Dat ass, wa mir op ee Stream eroplueden, brécht et dës Verbindungen net. Wat kënne mir hei verbesseren? Mir hunn Netzwierk Throttling, mir kënnen all Verbindung limitéieren duerch d'Zuel vun de Bytes déi se schéckt. Soss weess ech net wéi ech mat der Tatsaach këmmeren datt d'Objetspäicherung eis net erlaabt et parallel erofzelueden oder erofzelueden.
Keng SLA? Gëtt et net fir si geschriwwen, wéi si sech erlabe loossen?
De Punkt ass datt Leit, déi mat dëser Fro kommen, normalerweis hiren eegene Vault hunn. Dat ass, keen kënnt vun Amazon oder Google Cloud oder Yandex Object Storage.
Vläicht ass d'Fro net méi fir Iech?
D'Fro hei an dësem Fall ass egal wiem. Wann et Iddie gëtt wéi een domat ëmgeet, loosst eis et am WAL-G maachen. Mee bis elo hunn ech keng gutt Iddien wéi ech domat ëmgoen. Et ginn e puer Object Storage déi d'Lëscht vun Backups anescht ënnerstëtzen. Dir frot hinnen Objekter ze lëschten, a si addéieren Dossier do. WAL-G mécht Angscht virun dësem - et gëtt eng Aart vun Saach hei déi keng Datei ass, ech kann et net restauréieren, dat heescht datt de Backup net restauréiert gouf. Dat ass, tatsächlech, Dir hutt e komplett restauréierte Stärekoup, awer et gëtt Iech e falsche Status zréck well Object Storage e puer komesch Informatioun zréckginn huet, déi et net ganz verstanen huet.
Dëst ass eng Saach déi an der Mail Cloud geschitt.
Wann Dir eng Reproduktioun bauen kënnt ...
Et gëtt konsequent reproduzéiert ...
Wann et e Reproduktioun gëtt, da mengen ech, mir wäerten experimentéieren mat Retry-Strategien an erauszefannen wéi een erëm probéiert a verstoen wat d'Wollek vun eis erfuerdert. Vläicht wäert et fir eis op dräi Verbindungen stabil sinn a wäert d'Verbindung net briechen, da wäerte mir virsiichteg dräi erreechen. Well elo fale mir d'Verbindung ganz séier erof, dat heescht wa mir eng Erhuelung mat 16 Threads lancéiert hunn, da gëtt et nom éischte Versuch 8 Threads, 4 Threads, 2 Threads an een. An da zitt et d'Datei an ee Stroum. Wann et e puer magesch Wäerter sinn wéi 7,5 Threads sinn déi bescht fir ze pumpen, da bleiwe mir op hinnen a probéieren eng aner 7,5 Threads ze maachen. Hei ass eng Iddi.
Merci fir de Bericht! Wéi gesäit e komplette Workflow fir mat WAL-G ze schaffen aus? Zum Beispill, am domme Fall wann et keen Delta iwwer Säiten ass. A mir huelen an ewechhuelen den initialen Backup, dann archivéieren de Schaft bis mir blo am Gesiicht sinn. Hei, wéi ech et verstinn, gëtt et en Decompte. Irgendwann musst Dir en Delta-Backup vu Säiten maachen, dh e puer externe Prozess féiert dëst oder wéi geschitt dat?
D'Delta Backup API ass ganz einfach. Et gëtt eng Zuel do - max Delta Schrëtt, dat ass wat et genannt gëtt. Et ass Standard op Null. Dëst bedeit datt all Kéier wann Dir e Backup-Push maacht, e komplette Backup eroflueden. Wann Dir et op eng positiv Zuel ännert, zum Beispill 3, dann déi nächst Kéier wann Dir e Backup-Push maacht, kuckt d'Geschicht vu fréiere Backups. Hie gesäit datt Dir d'Kette vun 3 Deltas net iwwerschreift a mécht en Delta.
Dat ass, all Kéier wann mir WAL-G starten, probéiert et e komplette Backup ze maachen?
Nee, mir lafen WAL-G, an et probéiert en Delta ze maachen wann Är Politik et erlaabt.
Grof geschwat, wann Dir et all Kéier mat Null leeft, wäert et sech wéi pg_basebackup behuelen?
Nee, et wäert ëmmer méi séier lafen well et Kompressioun a Parallelismus benotzt. Pg_basebackup wäert de Schaft nieft Iech setzen. WAL-G gëtt ugeholl datt Dir d'Archivéierung konfiguréiert hutt. An et wäert eng Warnung erausginn wann et net konfiguréiert ass.
Pg_basebackup kann ouni shafts lafen.
Jo, dann behuelen se sech bal d'selwecht. Pg_basebackup kopéiert an de Dateiesystem. Mir hunn iwwregens eng nei Feature déi ech vergiess hunn ze ernimmen. Mir kënnen elo Backupsatellit op de Fichier System aus pg_basebackup. Ech weess net firwat dat gebraucht gëtt, awer et ass do.
Zum Beispill, op CephFS. Net jiddereen wëll Object Storage konfiguréieren.
Jo, dat ass méiglecherweis firwat se eng Fro iwwer dës Feature gestallt hunn fir datt mir et kéinte maachen. A mir hunn et gemaach.
Merci fir de Bericht! Et gëtt just eng Fro iwwer d'Kopie an de Dateiesystem. Aus der Këscht, ënnerstëtzt Dir elo Kopie op Fernspeicherung, zum Beispill, wann et e Regal am Rechenzentrum ass oder soss eppes?
An dëser Formuléierung ass dëst eng schwiereg Fro. Jo, mir ënnerstëtzen, awer dës Funktionalitéit ass nach net an enger Verëffentlechung abegraff. Dat ass, all Pre-Releases ënnerstëtzen dëst, awer d'Verëffentlechungsversionen net. Dës Funktionalitéit gouf an der Versioun 0.2 bäigefüügt. Et wäert definitiv geschwënn verëffentlecht ginn, soubal mir all bekannte Bugs fixéieren. Awer de Moment kann dëst nëmmen a Pre-Release gemaach ginn. Et ginn zwee Bugs an der Pre-Release. Problem mat WAL-E Erhuelung, mir hunn et net fixéiert. An an der leschter Pre-Release gouf e Feeler iwwer Delta-Backup bäigefüügt. Dofir empfeelen mir jiddereen d'Verëffentlechungsversioune ze benotzen. Soubal et keng Bugs méi an der Pre-Release sinn, kënne mir soen datt mir Google Cloud, S3-kompatibel Saachen an Dateilagerung ënnerstëtzen.
Moien, merci fir de Bericht. Wéi ech et verstinn, ass WAL-G net eng Zort zentraliséierte System wéi Barmen? Wëllt Dir an dës Richtung plënneren?
De Problem ass, datt mir vun dëser Richtung ewech geplënnert sinn. WAL-G lieft um Basishost, um Clusterhost, an op all Hosten am Cluster. Wéi mir op e puer dausend Cluster geplënnert sinn, hu mir vill Bartenderinstallatiounen. An all Kéier wann eppes an hinnen auserneen fällt, ass et e grousse Problem. Well se musse reparéiert ginn, musst Dir verstoen wéi eng Cluster elo keng Backups hunn. Ech plangen net WAL-G a Richtung kierperlech Hardware fir Backup Systemer z'entwéckelen. Wann d'Communautéit hei e puer Funktionalitéit wëll, da geet et mir guer net.
Mir hunn Équipë déi fir Stockage responsabel sinn. A mir fille sou gutt, datt et net mir sinn, datt et speziell Leit sinn, déi eis Dateie setzen, wou d'Dateie sécher sinn. Si maachen do all Zorte vu clever Kodéierung fir de Verloscht vun enger gewësser Zuel vu Fichieren ze widderstoen. Si si verantwortlech fir d'Netzbandbreedung. Wann Dir e Bartender hutt, kënnt Dir op eemol erausfannen datt kleng Datenbanken mat vill Traffic um selwechte Server gesammelt hunn. Dir schéngen vill Plaz op et ze hunn, mee fir e puer Grënn passt alles net duerch d'Netz. Et kann ëmgedréint ginn. Et gi vill Netzwierker do, et gi Prozessorkären, awer et gi keng Disken hei. A mir sinn midd vun dësem Besoin fir eppes ze jongléieren, a mir sinn op d'Tatsaach geplënnert datt Datelagerung e separaten Service ass, fir deen separat speziell Leit verantwortlech sinn.
PS Eng nei Versioun ass verëffentlecht ginn , an deem Dir d'Konfiguratiounsdatei .walg.json benotze kënnt, déi als Standard am postgres Heemverzeechnes läit. Dir kënnt Bash Scripten opginn. Beispill .walg.json ass an dëser Ausgab
Video:
Source: will.com