Ju lutem, njihuni me përmbledhjen e referatit të fillimit të vitit 2020 nga Georgy Rylov "WAL-G: mundësi të reja dhe zgjerimi i komunitetit"
Maintainerët e open-source përballen me shumë probleme ndërsa rriten. Si të shkruajmë më shumë funksione të kërkuara, të zgjidhim më shumë issues dhe të përballim më shumë pull requestë? Në shembullin e WAL-G (mjeti i backup-it për PostgreSQL), do t'ju tregoj si i zgjidhëm këto probleme duke filluar një kurs për zhvillimin Open-source në universitet, çfarë arritëm dhe ku do shkojmë më pas.
Përsëri përshëndetje të gjithëve! Unë jam zhvillues në Yandex nga Ekaterinburg. Dhe sot do t'u flas për WAL-G.
Në titullin e referatit nuk u tha se është diçka në lidhje me backup-et. A ka ndonjë që nuk e di çfarë është WAL-G? Apo të gjithë e dinë? Ngriheni dorën nëse nuk e dini. Wow, erdhët në referat dhe nuk e dini për çfarë është.
Le të flas për atë që do të ndodhë sot. Rasti është i tillë që ekipi ynë është angazhuar prej shumë kohësh në backup-ing. Dhe ky është një tjetër referat në serinë ku ne flasim për mënyrat se si ruajmë të dhënat në një mënyrë të sigurt, të besueshme, të lehtë dhe efektive.
Në seritë e mëparshme ka pasur shumë referate nga Andrey Borodin, Vladimir Leskov. Ne ishim shumë. Dhe të gjithë kemi folur për WAL-G për shumë vite.
clck.ru/F8ioz â
clck.ru/Ln8Qw â
Ky referat do të distingojë pak nga të tjerët, sepse atje kishte për më shumë pjesën teknike, ndërsa këtu do të tregoj për problemet që përballëm lidhur me rritjen e komunitetit. Dhe si u mendua një ide e vogël që na ndihmon të përballojmë këtë.
Disa vite më parë, WAL-G ishte një projekt mjaft i vogël, që na erdhi nga Citus Data. Dhe ne e morëm atë. Dhe dikush e zhvillonte vetëm.
Dhe vetëm në WAL-G mungonte:
- Backup-i nga replika.
- Nuk kishte backup-e inkrementale.
- Nuk kishte backup-e WAL-Delta.
- Dhe kishte shumë më tepër që mungonte.
Në këto disa vite, WAL-G është rritur shumë.
Dhe deri në vitin 2020, gjithçka e përmendur më sipër kishte dalë. Dhe për këtë është shtuar se tani kemi:
- Më shumë se 1,000 yje në GitHub.
- 150 fork-e.
- Rreth 15 PR të hapur.
- Dhe shumë kontribues të tjerë.
- Dhe issues të hapura vazhdimisht. Dhe kjo ndodh kur ne përditë bazojmë, bëjmë diçka me këtë.
Dhe ne erdhëm në përfundimin se ky projekt kërkon më shumë vëmendjen tonë, madje edhe kur ne vetë nuk na nevojitet të realizojmë diçka për shërbimin tonë Managed Databases në Yandex.
Dhe diku në vjeshtën e vitit 2018, na erdhi një ide. Zakonisht, ekipi ka disa mënyra për të zhvilluar disa veçori, për të riparuar gabimet, nëse nuk keni mjaft njerëz. Për shembull, mund të punësoni një zhvillues të ri dhe t'i paguani atij para. Ose mund të merrni një praktikant për një periudhë kohe dhe gjithashtu t'i paguani atij një pagë. Por ka gjithashtu një grup të madh njerëzish, disa prej të cilëve tashmë dinë të shkruajnë kod. Thjesht nuk e dini gjithmonë se çfarë cilësie ka ky kod.
Ne menduam dhe vendosĂ«m tĂ« pĂ«rpiqemi tĂ« tĂ«rheqim studentĂ«. Por studentĂ«t nuk do tĂ« marrin pjesĂ« nĂ« gjithçka. Ata do tĂ« bĂ«jnĂ« vetĂ«m njĂ« pjesĂ« tĂ« punĂ«s. Dhe, pĂ«r shembull, do tĂ« shkruajnĂ« teste, do tĂ« riparojnĂ« gabimet, do tĂ« realizojnĂ« veçori qĂ« nuk prekin funksionalitetin kryesor. Funkcionaliteti kryesor Ă«shtĂ« krijimi i kopjeve rezervĂ« dhe rikthimi i kopjeve rezervĂ«. NĂ«se lejohet njĂ« gabim nĂ« krijimin e njĂ« kopje rezervĂ«, do tĂ« kemi humbje tĂ« tĂ« dhĂ«nave. Dhe askush nuk do tĂ« dĂ«shironte qĂ« kjo tĂ« ndodhte. TĂ« gjithĂ« duan qĂ« gjithçka tĂ« jetĂ« shumĂ« e besueshme. Prandaj, ne sigurisht qĂ« nuk dĂ«shirojmĂ« tĂ« lejojmĂ« kodin qĂ« i besojmĂ« mĂ« pak se tonin tonĂ« tĂ« hyjĂ« atje. Pra, çdo kod jo kritik â Ă«shtĂ« ajo qĂ« do tĂ« dĂ«shironim tĂ« merrnim nga duar tĂ« tjera tĂ« punĂ«s.
Nën cilat kushte pranohet PR i studentëve
- Ata janë të detyruar të mbulojnë kodin e tyre me teste. Gjithçka duhet të kalojë në CI.
- Dhe gjithashtu kalojmë 2 rishikime. Një nga Andrei Borodin dhe një nga unë.
- Dhe përveç kësaj, për të kontrolluar se kjo nuk do të prishë asgjë në shërbimin tonë, unë ngarkoj veçmas një ndërtim me këtë angazhim. Dhe ne kontrollojmë në testet end-to-end, që asgjë nuk dështonte.
Kurs i veçantë për Open Source
Pak për atë se përse është e nevojshme dhe pse kjo, më duket, është një ide e shkëlqyer.
Për ne, përfitimi është i qartë:
- Ne marrim duar të tjera.
- Dhe kërkojmë kandidatë për ekip nga studentë të zellshëm që shkruajnë kod të zellshëm.
Cili është përfitimi për studentët?
Ata mund të jenë më pak të dukshëm, sepse studentët, të paktën, nuk marrin para për kodin që shkruajnë, por vetëm nota në regjistrin e tyre.
I pyeta rreth kësaj. Dhe sipas fjalëve të tyre:
- Përvoja e kontribuesit në Open Source.
- Të marrin një rresht në CV.
- Të shpërthejnë veten dhe të kalojnë një intervistë në Yandex.
- Të bëhen pjesëmarrës të GSoC.
- +1 kurs i veçantë për ata që duan të shkruajnë kod.
Nuk do të flas për mënyrën se si ishte organizuar kursi. Sidoqoftë, do të them se WAL-G ishte projekti kryesor. Po ashtu, në këtë kurs përfshimë projekte si Odyssey, PostgreSQL dhe ClickHouse.
Dhe ne kemi dhënë detyra jo vetëm në këtë kurs, por kemi ndarë edhe diploma dhe punë më projekte.
Dhe çfarë përfitimi ka për përdoruesit?
Tani le tĂ« kalojmĂ« nĂ« pjesĂ«n qĂ« me siguri ju intereson. ĂfarĂ« pĂ«rfitoni ju nga kjo? PĂ«rfitimi Ă«shtĂ« se studentĂ«t kanĂ« rregulluar shumĂ« bugs. Dhe kanĂ« bĂ«rĂ« kĂ«rkesa pĂ«r veçori qĂ« i kishit kĂ«rkuar.
Dhe le të flas për gjëra që ju i keni dëshiruar prej një kohe të gjatë dhe që janë realizuar.
Mbështetje për tablespaces. Mbështetja për tablespaces në WAL-G ka pritur ndoshta që nga momenti i lëshimit të WAL-G, sepse WAL-G është pasuesi i një instrumenti tjetër backup, WAL-E, ku ishin mbështetur kopjet rezervë të bazave të të dhënave me tablespaces.
Lehtësisht t'ju kujtoj se çfarë është dhe pse është e nevojshme. Në rregull, të gjitha të dhënat e Postgres zakonisht zënë një katalog të vetëm në sistemin e skedarëve, që quhet katalogu bazë. Ky katalog tashmë përmban të gjitha skedarët dhe nënkatalogët e nevojshëm për Postgres.
Tablespaces janë katalogë ku ndodhen të dhënat e Postgres, por ato nuk ndodhen jashtë katalogut bazë. Në slajd duket se tablespacet janë përtej katalogut bazë.
Si duket kjo për Postgres-in vetë? Në katalogun bazë ka një nënkatalog të veçantë pg_tblspc. Në të ndodhen lidhjet simbolike për katalogët ku realisht ndodhen të dhënat e Postgres jashtë katalogut bazë.
Kur e përdorni të gjithë këtë, komandat mund të duken kështu për ju. Kështu, krijoni një tabelë në ndonjë tablespace të specifikuar dhe shikoni se ku ndodhet tani. Këto dy rreshta të fundit, dy komandat e fundit të thirrura. Dhe aty duket se ka një rrugë. Por në të vërtetë, kjo nuk është një rrugë e vërtetë. Kjo është një rrugë me prefiks nga katalogu bazë te tablespace. Dhe nga aty ajo është lidhur me një lidhje simbolike, që çon te të dhënat tuaja reale.
Të gjitha këto nuk përdoren në ekipin tonë, por ato janë përdorur nga shumë përdorues të tjerë të WAL-E, që na kanë shkruar se donin të migronin në WAL-G, por kjo i ka penguar. Tani mbështetet.
Një veçori tjetër që na solli kursi ynë special është catchup. Njohin catchup ata që ndoshta kanë punuar më shumë me Oracle sesa me Postgres.
Në përmbledhje, çfarë është kjo. Një topologji e zakonshme e një klasteri në shërbimin tonë mund të duket kështu. Ne kemi një master. Ka një replikë që transmeton nga ai log-un përpara shkrimit. Dhe reprika i thotë masterit se në cilin LSN është aktualisht. Dhe ndonjëherë, paralelisht me këtë, mund të arkivohet journal. Përveç arkivimit të journal-it, ndodhen dhe backup-et në cloud. Po ashtu dërgohen dhe delta-backup-et.
Cila mund tĂ« jetĂ« problemi? Kur keni njĂ« bazĂ« tĂ« madhe, mund tĂ« ndodhĂ« qĂ« replikĂ«s tâi mungojĂ« shumĂ« pas masterit. Dhe ajo vonohet aq shumĂ«, saqĂ« kurrĂ« nuk mund ta arrijĂ«. KĂ«tĂ« problem shpeshherĂ« duhet ta zgjidhni siç duhet.
Dhe mĂ«nyra mĂ« e thjeshtĂ« â Ă«shtĂ« tĂ« hiqni replikĂ«n dhe ta rivendosni atĂ« nga e para, sepse ajo kurrĂ« nuk do ta arrijĂ«, ndersa me problemin duhet tĂ« merremi. Por kjo Ă«shtĂ« shumĂ« e gjatĂ«, sepse rikthimi i njĂ« backup tĂ« plotĂ« tĂ« njĂ« baze prej 10 TB merr shumĂ«, shumĂ« kohĂ«. Dhe na pĂ«lqen ta bĂ«jmĂ« kĂ«tĂ« sa mĂ« shpejt tĂ« jetĂ« e mundur, nĂ«se ndodhin kĂ«to probleme. Dhe pĂ«r kĂ«tĂ« Ă«shtĂ« e destinuar catchup.
Catchup lejon përdorimin e delta-backup-eve, që ruajnë në cloud në këtë mënyrë. Ju thoni se në cilin LSN ndodhet tani replikat e prapambetur dhe e tregoni atë në komandën catchup për të krijuar një delta-backup midis atij LSN dhe LSN ku ndodhet aktualisht klasteri juaj. Dhe pas kësaj, e riktheni këtë backup në replikën që ishte prapambetur.
Baza të tjera
NjĂ«kohĂ«sisht, studentĂ«t na sollĂ«n shumĂ« karakteristika. SĂ« bashku me tĂ«, ne nĂ« Yandex rregullojmĂ« jo vetĂ«m Postgres, por gjithashtu kemi MySQL, MongoDB, Redis, ClickHouse, kĂ«shtu qĂ« nĂ« njĂ« moment na nevojitej qĂ« tĂ« mund tĂ« bĂ«nim backup me rikthim nĂ« kohĂ« pĂ«r MySQL, dhe qĂ« tĂ« kishte mundĂ«si pĂ«r tâi ngarkuar ato nĂ« cloud.
Dhe doja të bëja këtë në një mënyrë të ngjashme me atë që bën WAL-G. Dhe vendosëm të eksperimentojmë dhe të shohim se si do të dukej gjithçka.
Në fillim, pa e ndarë logjikën, shkruam kodin në një fork. E pamë se kishim një model funksional dhe kjo mund të avancojë. Më pas menduam se bashkësia jonë kryesore është PostgreSQL-istët, ata përdorin WAL-G. Prandaj duhet ndarë disa pjesë. Pra, kur përmirësojmë kodin për Postgres, nuk dëmtojmë MySQL-në, kur përmirësojmë MySQL-në, nuk dëmtojmë Postgres-in.
Ideja e parë për të ndarë këtë ishte të përdorej i njëjti qasje siç përdoret në zgjerimet PostgreSQL. Në thelb, për të bërë një backup MySQL, ju duhej të instalonit një bibliotekë dinamike.
Por këtu menjëherë duket asimetri e këtij qasjeje. Kur bëni backup për Postgres, ju vendosni një backup tool normal për Postgres dhe gjithçka shkon mirë. Por për MySQL, rezulton se vendosni një backup tool për Postgres dhe pastaj për të vendosni një bibliotekë dinamike për MySQL. Duket disi e çuditshme. Ne gjithashtu menduam kështu dhe vendosëm se kjo nuk ishte zgjidhja që na nevojitej.
Ndryshme ndërtimet për Postgres, MySQL, MongoDB, Redis
Por kjo na lejoi, siç duket, tĂ« arrijmĂ« nĂ« njĂ« zgjidhje tĂ« saktĂ« â tĂ« veçojmĂ« ndĂ«rtimet e ndryshme pĂ«r baza tĂ« ndryshme. Kjo lejonte izolimin e logjikĂ«s sĂ« lidhur me backup-et e bazave tĂ« ndryshme tĂ« tĂ« dhĂ«nave, tĂ« cilat do tĂ« qasen nĂ« njĂ« API tĂ« pĂ«rbashkĂ«t qĂ« realizon WAL-G.
Kjo Ă«shtĂ« ajo pjesĂ« qĂ« e shkruam vetĂ« â pĂ«rpara se t'u jepnim studentĂ«ve detyra. Pra, kjo Ă«shtĂ« pikĂ«risht ajo pjesĂ« ku ata mund tĂ« bĂ«nin ndonjĂ« gjĂ« jo tĂ« drejtĂ«, prandaj vendosĂ«m qĂ« Ă«shtĂ« mĂ« mirĂ« ta bĂ«jmĂ« ne diçka kĂ«shtu qĂ« gjithçka do tĂ« ishte nĂ« rregull.
Pas kësaj u dhamë detyra. Menjëherë u morën ato. Nga studentët kërkohej të mbështesin tre baza.
Kjo është MySQL, të cilën e bëjmë backup me WAL-G në këtë mënyrë për më shumë se një vit.
Dhe tashmë MongoDB po i afrohet prodhimit, aty po e rafinojnë me dorë. Në thelb, ne shkruam skeletin për të gjithë këtë. Më pas studentët shkruan disa gjëra funksionale. Dhe pastaj ne i çojmë ato në një gjendje të tillë që mund t'i pranojmë në prodhimin tonë.
Këto detyra nuk dukeshin si të nevojitej për studentët të shkruanin mjete të plota backup për secilën prej këtyre bazave. Ne nuk kishim një problem të tillë. Problemi ynë ishte se donim rikuperim pikë në kohë dhe donim të bënim backup në cloud. Dhe iu kërkuam studentëve të shkruanin ndonjë kod që do ta zgjidhte këtë. Studentët përdorën mjete ekzistuese backup, të cilat në një farë mënyre marrin backup-e, dhe pastaj e lidhën gjithçka me WAL-G, e cila e dërgonte gjithçka në cloud. Po ashtu, e shtuan rikuperimin pikë në kohë.
ĂfarĂ« tjetĂ«r sollĂ«n studentĂ«t? Ata sollĂ«n nĂ« WAL-G mbĂ«shtetje pĂ«r enkriptimin Libsodium.
Po ashtu, ne kemi krijuar politika për ruajtjen e backup-eve. Tani backup-et mund të shënjohen si përhershëm. Dhe ndoshta është më e lehtë për shërbimin tuaj të automatizoni procesin e ruajtjes së tyre.
ĂfarĂ« arriti ky eksperiment nĂ« fund tĂ« fundit?
Fillimisht, mbi 100 njerëz u regjistruan në kurs. Në fillim nuk e thashë që universiteti në Ekaterinburg është Universiteti Federal i Urals. Aty e shpallëm gjithçka. 100 njerëz u regjistruan. Në të vërtetë, shumë më pak filluan të bëjnë diçka, rreth 30 njerëz.
Kursin e mbyllën edhe më pak njerëz, sepse atje duhej të shkruhen teste për kodet që ishin tashmë në dispozicion. Dhe gjithashtu të rregullohej ndonjë bug ose të bëhej një funksionalitet. Disa studentë e mbyllën gjithsesi kursin.
Aktualisht, për këtë kurs studentët kanë rregulluar rreth 14 issues, kanë krijuar 10 funksionalitete të ndryshme. Dhe, sipas mendimit tim, kjo është një zëvendësim i plotë për një ose dy zhvillues.
PĂ«rveç gjithçkaje, ne lĂ«shuam diploma dhe punĂ« kursi. 12 prej tyre morĂ«n diplomat. 6 prej tyre u mbrojtĂ«n me nota â5â. PĂ«r tĂ« tjerĂ«t, mbrojtjet ende nuk janĂ« bĂ«rĂ«, por mendoj se gjithashtu do t'u shkojĂ« mirĂ«.
Planet për të ardhmen
Cilat janë planet tona për të ardhmen?
Të paktën, ato kërkesa për funksionalitete që tashmë kemi dëgjuar nga përdoruesit dhe duam t'i realizojmë. Këto janë:
- Monitorimi i saktësisë së gjurmimit të linearit në arkiv të kopjeve rezervë të klasterit HA. Me ndihmën e WAL-G, kjo mund të bëhet. Dhe, mendoj se do të gjejmë studentë që do ta marrin atë punë.
- Për transferimin e kopjeve rezervë dhe WAL-it midis reve, ne tashmë kemi një person përgjegjës.
- Dhe së fundmi, ne publikuan idenë se mund ta përshpejtojmë akoma më shumë WAL-G-në përmes shfletimit të kopjeve rezervë inkrementale pa rinovimin e faqeve dhe optimizimin e arkivave që i dërgojmë atje.
Mund të ndani ato këtu
PĂ«r çfarĂ« ishte ky raport? PĂ«r faktin se tani, pĂ«rveç nesh 4 individĂ«ve qĂ« mbĂ«shtesin kĂ«tĂ« projekt, kemi duar shtesĂ«, tĂ« cilat janĂ« mjaft tĂ« shumta. Sidomos nĂ«se u shkruani nĂ« mesazh privat. Dhe nĂ«se ju po e back-up-oni tĂ« dhĂ«nat tuaja dhe po e bĂ«ni kĂ«tĂ« me ndihmĂ«n e WAL-G ose do tĂ« donit tĂ« kaloni nĂ« WAL-G, dĂ«shirat tuaja ne mund tâi marrim mjaft lehtĂ« parasysh.
Ky është një kod qr dhe një lidhje. Mund të kaloni përmes tyre dhe të shkruani të gjitha dëshirat tuaja. Për shembull, ndoshta ne nuk e rregullojmë një bug. Ose ndonjë funksionalitet që e doni shumë, por për ndonjë arsye nuk është ende në asnjë nga kopjet rezervë, përfshirë tonën. Sigurohuni ta bëni të ditur këtë.
Pyetje
Përshëndetje! Faleminderit për raportin! Kam një pyetje për WAL-G, por jo për Postgres. WAL-G bëni backup MySQL dhe thërret backup ekstra. Në qoftë se merrni instalime moderne në CentOS dhe nëse bëni yum install MySQL, do të instalohet MariaDB. Që nga versione 10.3, backup ekstra nuk mbështetet, por mbështetet backup-i i MariaDB. Si e keni këtë gjë?
Në këtë moment nuk kemi provuar të bëjmë backup për MariaDB. Kishim kërkesa për mbështetje për FoundationDB, por në përgjithësi, nëse ka një kërkesë të tillë, mund të gjejmë njerëz që do ta bëjnë. Nuk është shumë e gjatë dhe aq e komplikuar sa mendoj.
Mirëdita! Faleminderit për raportin! Kam një pyetje për potencialisht karakteristika të reja. A jeni të gatshëm ta bëni WAL-G të funksionojë me banda, që të mund të bëni backup në banda?
Duket se po flisni për backup në ruajtjen me banda?
Po.
Atje është Andrei Borodin, i cili mund të përgjigjet më mirë se unë për këtë pyetje.
(Andrei) Po, faleminderit për pyetjen! Kemi pasur një kërkesë për transferimin e backup-it në bandë nga ruajtja në re. Dhe për këtë transferimi midis reve. Sepse transferimi midis reve është një version i përgjithësuar i transferimit në bandë. Për më tepër, kemi një arkitekturë të zgjerueshme në pjesën e Storages. Nga ana tjetër, shumë nga storaget janë shkruar nga studentët. Dhe nëse shkruani një Storage për banda, ai sigurisht do të mbështetet. Jemi të gatshëm të shqyrtojmë pull request. Aty duhet të regjistrohet një skedar, të lexohet një skedar. Nëse këto gjëra bëhen në Go, zakonisht rezulton në 50 rreshta kodi. Dhe atëherë në WAL-G do të mbështetet banda.
Faleminderit për raportin! Procesi i zhvillimit është interesant. Backup është një pjesë serioze e funksionalitetit që duhet të mbulohet mirë me teste. Kur ju e realizuat funksionalitetin për baza të reja, a të gjitha testet u shkruan gjithashtu nga studentët apo ju i shkruat testet dhe pastaj ua dhatë studentëve implementimin?
Testet i shkruan gjithashtu studentĂ«t. Por studentĂ«t shkruan mĂ« shumĂ« pĂ«r karakteristika tĂ« tilla si bazat e reja. Ata shkruan teste integruese. Dhe ata shkruan teste unit. NĂ«se testet integruese kalojnĂ«, dmth pĂ«r momentin â Ă«shtĂ« njĂ« skenar qĂ« ju e ejecutoni me duar ose e bĂ«n cron, pĂ«r shembull. DMTH, atje skenari Ă«shtĂ« shumĂ« i kuptueshĂ«m.
Studentët nuk kanë shumë eksperiencë. Sa kohë shpenzohet për rishikimin?
Po, rreth rishikimeve po kalon shumë kohë. Z. e. zakonisht, kur vijnë disa kontribuues menjëherë dhe thonë që kam bërë këtë, kam bërë atë, duhet të mendoj dhe të rezervoj diku gjysmë ditë për t'u marrë me atë që ata kanë shkruar. Sepse kodi duhet lexuar me kujdes. Ata nuk kanë kaluar intervistën. Ne nuk i njohim shumë mirë, prandaj kjo merr një kohë të konsiderueshme.
Faleminderit për raportin! Më parë, Andrei Borodin shpalli se archive_command në WAL-G duhet të thirret drejtpërdrejt. Por në rast të një klasteri patron, na nevojitet logjikë shtesë për të përcaktuar nodin nga e cila të dërgojmë vallet. Si e zgjidhni ju këtë problem?
Cila është problemit tuaj këtu? Le të themi, a keni një replikë sinkrone nga e cila merrni backup? Apo çfarë?
(Andrei) Problemi është se vërtet WAL-G supozon përdorimin pa lidhur me skriptet e shell. Nëse diçka mungon, atëherë le t'i shtojmë logjikën që duhet të jetë brenda WAL-G. Në lidhje me atë nga e cila duhet të bëhet arkivimi, ne mendojmë se arkivimi duhet të bëhet nga mjeshtri aktual në klaster. Arkivimi nga replika është një ide e keqe. Janë të mundshme skenarë të ndryshëm me probleme. Në veçanti, problemet me arkivimin e kronologjive dhe informacionit të tjera të shtesë. Faleminderit për pyetjen!
(Sqarim: Jemi liruar nga lidhja me skriptet e shell) )
Mirëmbrëma! Faleminderit për raportin! Më interesoi karakteristika catchup, për të cilën keni folur. Takoheshit me një situatë ku replika vonohej dhe nuk mund të kapte dot. Dhe në WAL-G nuk gjeta përshkrimin e kësaj karakteristike në dokumentacion.
Catchup u shfaq në të vërtetë në mesin e 20: ditëve të janarit 2020. Me dokumentacionin, ndoshta duhet të punoni më mirë. Ne vetë e shkruajmë dhe nuk jemi duke e bërë atë për të qenë super-shkëlqyeshëm. Dhe ndoshta, duhet filluar të kërkojmë nga studentët që ta shkruajnë.
A është ajo tashmë në lëshim?
Pull request-in e kam shqyrtuar tani, pra e kam kontrolluar. E kam provuar atë në klasterin testues. Deri tani nuk kemi pasur ndonjë situatë kur mund ta verifikonim këtë në një shembull në produksion.
Kur të pritet?
Nuk e di. Prisni një muaj, do ta verifikojmë me siguri.
Burimi: habr.com
