Azt javaslom, hogy olvassa el Andrej Borodin 2019 eleji jelentésének átiratát „Biztonsági mentések a WAL-G-vel. Mi lesz 2019-ben?”
Sziasztok! A nevem Andrej Borodin. A Yandex fejlesztője vagyok. 2016 óta érdekel a PostgreSQL, miután beszéltem a fejlesztőkkel, és azt mondták, hogy minden egyszerű – veszed a forráskódot, összeállítod, és minden menni fog. Azóta pedig nem tudom abbahagyni – mindenfélét írok.
Az egyik dolog, amin dolgozom, egy tartalék rendszer. . Általánosságban elmondható, hogy a Yandexnél nagyon hosszú ideje dolgozunk a PostgreSQL biztonsági mentési rendszerein. Az interneten pedig egy hat jelentésből álló sorozatot találhat arról, hogyan készítünk biztonsági mentési rendszereket. És minden évben fejlődnek egy kicsit, fejlődnek egy kicsit és megbízhatóbbá válnak.
De ma a jelentés nem csak arról szól, amit tettünk, hanem arról is, hogy milyen egyszerű és mi az. Hányan nézték már meg a WAL-G-ről szóló riportjaimat? Még jó, hogy elég sokan nem nézték meg, mert a legegyszerűbb dologgal kezdem.
Ha hirtelen van egy PostgreSQL fürt, és szerintem mindenkinek van egy-két ilyen, és hirtelen még nincs biztonsági mentési rendszer, akkor be kell szerezni bármilyen S3 tárhelyet vagy Google Cloud kompatibilis tárhelyet.
Például eljöhet a standunkhoz, és átvehet egy promóciós kódot a Yandex Object Storage számára, amely S3-kompatibilis.
Ezután hozzon létre egy vödröt. Ez csak egy információs tároló.
Hozzon létre egy szolgáltatás felhasználót.
Hozzon létre egy hozzáférési kulcsot a szolgáltatás felhasználója számára: aws-s3-key.
Töltse le a WAL-G legújabb stabil kiadását.
Miben különböznek előzetes kiadásaink a kiadásainktól? Gyakran kérnek tőlem, hogy engedjem el hamarabb. És ha elegendő ideig, például egy hónapig, nincs hiba a verzióban, akkor kiengedem. Íme ez a novemberi kiadvány. Ez pedig azt jelenti, hogy minden hónapban találtunk valamilyen hibát, általában nem kritikus funkciókban, de még nem adtunk ki kiadást. Az előző verzió még csak november. Nincsenek benne általunk ismert hibák, vagyis a projekt előrehaladtával kerültek be a hibák.
Miután letöltötte a WAL-G-t, futtathat egy egyszerű „backup list” parancsot, amely átadja a környezeti változókat. És csatlakozik az Object Storage-hoz, és megmondja, milyen biztonsági másolatai vannak. Eleinte természetesen nem kellene biztonsági másolatot készítenie. Ennek a dianak az a lényege, hogy megmutassa, minden nagyon egyszerű. Ez egy konzolparancs, amely elfogadja a környezeti változókat és végrehajtja az alparancsokat.
Ezt követően elkészítheti az első biztonsági mentést. Mondja ki a „backup-push” kifejezést a WAL-G-ben, és adja meg a WAL-G-ben a fürt pgdata helyét. Valószínűleg a PostgreSQL azt fogja mondani, ha még nincs biztonsági mentési rendszere, hogy engedélyeznie kell az "archive-mode"-t.
Ez azt jelenti, hogy be kell lépnie a beállításokba, és be kell kapcsolnia az „archive_mode = on” funkciót, és hozzá kell adnia az „archive_command” parancsot, amely szintén egy alparancs a WAL-G-ben. De valamiért az emberek gyakran használnak bárszkripteket ebben a témában, és a WAL-G köré fonják. Kérlek, ne tedd ezt. Használja a WAL-G-ben található funkciókat. Ha valami hiányzik, írjon . A WAL-G feltételezi, hogy ez az egyetlen program, amely az archive_command fájlban fut.
A WAL-G-t főként egy magas rendelkezésre állású fürt létrehozására használjuk a Yandex adatbázis-kezelésben.
És általában egy Master topológiájában és több replikációban használják. Ezzel egyidejűleg biztonsági másolatot készít a Yandex Object Storage-ban.
A leggyakoribb forgatókönyvek a fürt másolatainak létrehozása az időben történő helyreállítás segítségével. De ebben az esetben a tartalék rendszer teljesítménye nem annyira fontos számunkra. Csak fel kell töltenünk egy új fürtöt a biztonsági mentésből.
Általában új csomópont hozzáadásakor szükségünk van tartalék rendszerteljesítményre. Miért fontos? Az emberek általában új csomópontot adnak a fürthöz, mert a meglévő fürt nem tudja kezelni az olvasási terhelést. Új replikát kell hozzáadniuk. Ha hozzáadjuk a pg_basebackup terhelést a Masterhez, akkor a Master összeomolhat. Ezért nagyon fontos volt számunkra, hogy gyorsan fel tudjunk tölteni egy új csomópontot az archívumból, minimális terhelést okozva a Master-nek.
És még egy hasonló helyzet. Ehhez újra kell indítani a régi mestert, miután átváltotta a fürtmestert abból az adatközpontból, amellyel megszakadt a kapcsolat.
- Ennek eredményeként a másolórendszer követelményeinek megfogalmazásakor rájöttünk, hogy a pg_basebackup nem alkalmas számunkra felhőben történő működés esetén.
- Szerettük volna tömöríteni az adatainkat. De a dobozban lévő kivételével szinte minden biztonsági mentési rendszer biztosítja az adattömörítést.
- Szerettünk volna mindent párhuzamosítani, mert a felhőben lévő felhasználó nagyszámú processzormagot vásárol. De ha néhány műveletben nincs párhuzamosságunk, akkor nagyszámú mag használhatatlanná válik.
- Titkosításra van szükségünk, mert az adatok gyakran nem a miénk, és nem tárolhatók tiszta szövegben. A WAL-G-hez való hozzájárulásunk egyébként a titkosítással kezdődött. Befejeztük a titkosítást WAL-G-ben, ami után megkérdezték tőlünk: „Talán valamelyikünk fejleszti a projektet?” És azóta több mint egy éve dolgozom a WAL-G-vel.
- Erőforrás-szabályozásra is szükségünk volt, mert a felhő használatával idővel rájöttünk, hogy az embereknek néha fontos élelmiszer rakományuk van éjszaka, és ezt a terhelést nem lehet megzavarni. Ezért adtuk hozzá az erőforrás-szabályozást.
- Valamint a listázás és a kezelés.
- És ellenőrzés.
Sokféle eszközt néztünk meg. Szerencsére hatalmas választékunk van a PostgreSQL-ben. És mindenhol hiányzott valami, hol egy kis funkció, hol egy kis funkció.
És miután megvizsgáltuk a meglévő rendszereket, arra a következtetésre jutottunk, hogy a WAL-G-t fejlesztjük. Akkor ez egy új projekt volt. A mentési rendszer felhő infrastruktúrája felé történő fejlődést meglehetősen könnyű volt befolyásolni.
A fő ideológia, amelyhez ragaszkodunk, hogy a WAL-G olyan egyszerű legyen, mint egy balalajka.
A WAL-G-nek 4 parancsa van. Ez:
WAL-PUSH – archiválja a tengelyt.
WAL-FETCH – vegyél egy tengelyt.
BACKUP-PUSH – biztonsági mentés készítése.
BACKUP-FETCH – készítsen biztonsági másolatot a biztonsági mentési rendszerből.
Valójában a WAL-G kezeli is ezeket a biztonsági mentéseket, azaz listázza és törölje a rekordokat és a jelenleg már nem szükséges biztonsági másolatokat a történelemben.
Számunkra az egyik fontos funkció a delta másolatok létrehozása.
A delta másolatok azt jelentik, hogy nem készítünk teljes biztonsági másolatot a teljes fürtről, hanem csak a fürtben lévő módosított fájlok megváltozott oldalairól. Úgy tűnik, hogy funkcionálisan ez nagyon hasonlít a WAL használatával történő helyreállítási képességhez. De párhuzamosan feltekerhetünk egy WAL egyszálú delta biztonsági mentést is. Ennek megfelelően, ha szombaton készítünk egy alapmentést, naponta delta biztonsági mentést, csütörtökön pedig meghiúsul, akkor 4 delta biztonsági mentést és 10 óra WAL-t kell felgöngyölítenünk. Körülbelül ugyanannyi időt vesz igénybe, mert a delta biztonsági mentések párhuzamosan gördülnek.
LSN-alapú delta - ez azt jelenti, hogy biztonsági másolat készítésekor minden oldalt össze kell kapcsolnunk, és ellenőriznünk kell az LSN-t az előző biztonsági mentés LSN-jével, hogy megértsük, hogy megváltozott. Minden olyan oldalnak, amely potenciálisan megváltozott adatokat tartalmazhat, jelen kell lennie a delta biztonsági mentésben.
Mint mondtam, elég nagy figyelmet fordítottak a párhuzamosságra.
De a PostgreSQL archívum API-ja konzisztens. A PostgreSQL egy WAL-fájlt archivál, és visszaállításkor egy WAL-fájlt kér. De amikor az adatbázis egy WAL-fájlt kér a "WAL-FETCH" paranccsal, akkor meghívjuk a "WAL-PREFETCH" parancsot, amely előkészíti a következő 8 fájlt az adatok párhuzamos lekérésére az objektumtárolóból.
És amikor az adatbázis egy fájl archiválását kéri, megnézzük az archive_status-t, és megnézzük, vannak-e más WAL-fájlok. És párhuzamosan próbáljuk letölteni a WAL-t is. Ez jelentős teljesítménynövekedést biztosít, és jelentősen csökkenti a távolságot az archiválatlan WAL-ok számában. Sok biztonsági mentési rendszer fejlesztője úgy gondolja, hogy ez egy olyan kockázatos rendszer, mert a nem PostgreSQL API-kódok belső tulajdonságaira támaszkodunk. A PostgreSQL nem garantálja számunkra az archive_status mappa jelenlétét, és nem garantálja a szemantikát, a WAL-fájlok készenléti jelzéseinek jelenlétét. Ennek ellenére tanulmányozzuk a forráskódot, látjuk, hogy ez így van, és megpróbáljuk kihasználni. És mi irányítjuk, hogy a PostgreSQL milyen irányba fejlődik; ha ez a mechanizmus hirtelen megszakad, abbahagyjuk a használatát.
Tiszta formájában az LSN-alapú WAL-delta megköveteli minden olyan fürtfájl olvasását, amelynek a fájlrendszer mód-ideje megváltozott az előző biztonsági mentés óta. Sokáig éltünk ezzel, majdnem egy évig. És végül arra a következtetésre jutottunk, hogy WAL-deltáink vannak.
Ez azt jelenti, hogy minden alkalommal, amikor a WAL-t archiváljuk a Master-en, nem csak tömörítjük, titkosítjuk és elküldjük a hálózatra, hanem egyúttal olvassuk is. Elemezzük és elolvassuk a benne található feljegyzéseket. Megértjük, hogy mely blokkok változtak, és delta fájlokat gyűjtünk.
A delta fájl a WAL-fájlok egy bizonyos tartományát írja le, és leírja, hogy mely blokkok változtak meg ebben a WAL-tartományban. Aztán ezek a delta fájlok is archiválva vannak.
Itt szembesülünk azzal a ténnyel, hogy elég gyorsan párhuzamba állítottunk mindent, de szekvenciális előzményeket nem tudunk párhuzamosan olvasni, mert egy bizonyos szegmensben az előző WAL rekord végével találkozhatunk, amihez még nincs mihez kötnünk, mert a párhuzamos olvasás oda vezetett, hogy először a jövőt elemezzük, amelynek még nincs múltja.
Ennek eredményeként érthetetlen darabokat kellett _delta_partial fájlba helyeznünk. Ennek eredményeként, amikor visszatérünk a múltba, a WAL-lemez darabjait összeragasztjuk, majd ezt követően elemezzük, és megértjük, mi változott benne.
Ha a tengelyelemzésünk történetében van legalább egy olyan pont, ahol nem értjük, mi történik, akkor ennek megfelelően a következő mentés során kénytelenek leszünk újra elolvasni a teljes klasztert, akárcsak egy normál LSN-nél. -alapú delta.
Ennek eredményeként minden szenvedésünk oda vezetett, hogy nyílt forráskódú WAL-G elemző könyvtárat készítettünk. Tudomásom szerint még senki nem használja, de ha valaki akarja, írja meg és használja, közkincs. (Frissített link )
Ennek eredményeként minden információáramlás meglehetősen bonyolultnak tűnik. Mesterünk archiválja az aknát és archiválja a delta fájlokat. A biztonsági másolatot készítő replikának pedig delta fájlokat kell kapnia a biztonsági mentések között eltelt idő alatt. Ebben az esetben az előzmények egyes részeit tömegesen kell hozzáadni és elemezni, mert nem a teljes előzmény fér bele nagy szegmensekbe. És csak ezután tud a replika archiválni a teljes delta biztonsági mentést.
A grafikonokon minden sokkal egyszerűbbnek tűnik. Ez egy letöltés az egyik valódi klaszterünkből. LSN alapú, egy nap alatt készült. És azt látjuk, hogy az LSN-alapú delta biztonsági mentés hajnali háromtól hajnali ötig futott. Ez a terhelés a processzormagok számában. A WAL-delta itt nagyjából 20 percet vett igénybe, vagyis lényegesen gyorsabb lett, ugyanakkor intenzívebb volt a hálózaton keresztüli adatcsere.
Mivel információnk van arról, hogy mely blokkok és mikor változtak meg az adatbázis történetében, továbbmentünk, és úgy döntöttünk, hogy integráljuk a funkcionalitást - egy PostgreSQL kiterjesztést, amelyet "pg_prefaulter"-nek hívnak.
Ez azt jelenti, hogy amikor a készenléti bázis végrehajtja a visszaállítási parancsot, utasítja a WAL-G-t a következő WAL-fájl lekérésére. Körülbelül tisztában vagyunk azzal, hogy a WAL helyreállítási folyamat mely adatblokkokhoz fog hozzáférni a közeljövőben, és olvasási műveletet kezdeményezünk ezeken a blokkon. Ez az SSD-vezérlők teljesítményének növelése érdekében történt. Mert a WAL tekercs eléri azt az oldalt, amit változtatni kell. Ez az oldal a lemezen van, és nincs az oldal gyorsítótárában. És szinkronban várja, hogy ez az oldal megérkezzen. De a közelben van a WAL-G, amely tudja, hogy a következő néhány száz megabájt WAL-ban szükségünk lesz bizonyos oldalakra, és egyúttal elkezdi felmelegíteni őket. Több lemezelérést kezdeményez, hogy azok párhuzamosan legyenek végrehajtva. Ez SSD meghajtókon jól működik, de merevlemezre sajnos abszolút nem alkalmazható, mert csak a promptjainkkal zavarjuk bele.
Ez most benne van a kódban.
Vannak olyan funkciók, amelyeket szeretnénk hozzáadni.
Ez a kép azt mutatja, hogy a WAL-delta viszonylag rövid ideig tart. Ez pedig az adatbázisban a nap folyamán bekövetkezett változások leolvasása. A WAL-deltát nem csak éjszaka csinálhatnánk, mert az már nem jelent jelentős terhelési forrást. Minden percben olvashatjuk a WAL-deltát, mert olcsó. Egy perc alatt átvizsgálhatjuk az összes változást, amely a klaszteren történt. És ezt nevezhetjük "azonnali WAL-deltának".
A lényeg az, hogy amikor visszaállítjuk a klasztert, csökkentjük azoknak a történeteknek a számát, amelyeket sorban kell felgöngyölítenünk. Azaz csökkenteni kell a PostgreSQL által gördített WAL mennyiségét, mert ez jelentős időt vesz igénybe.
De ez még nem minden. Ha tudjuk, hogy egy blokk a biztonsági mentés konzisztenciájáig módosul, akkor azt a múltban nem tudjuk megváltoztatni. Vagyis most már fájlonként optimalizáltuk a WAL-delta továbbítást. Ez azt jelenti, hogy ha például kedden egy táblát teljesen töröltek, vagy egyes fájlokat teljesen töröltek a táblából, akkor a delta átfutásakor hétfőn és a szombati pg_basebackup visszaállítása során nem is hozzuk létre ezeket az adatokat.
Ezt a technológiát szeretnénk kiterjeszteni az oldal szintjére. Vagyis ha a fájl egy része hétfőn megváltozik, de szerdán felülírják, akkor csütörtöki pontra való visszaállításkor nem kell lemezre írnunk az oldalak első néhány verzióját.
De ez még mindig egy olyan ötlet, amit bennünk is aktívan vitatnak, de még nem jutott el a kódig.
Még egy funkciót szeretnénk létrehozni a WAL-G-ben. Bővíthetővé szeretnénk tenni, mert különböző adatbázisokat kell támogatnunk, és szeretnénk, ha a biztonsági mentések kezelését is ugyanúgy tudnánk megközelíteni. De a probléma az, hogy a MySQL API-k gyökeresen különböznek egymástól. A MySQL-ben a PITR nem a fizikai WAL-naplón, hanem a binlogon alapul. És nincs olyan archiváló rendszerünk a MySQL-ben, amely azt mondaná valamilyen külső rendszernek, hogy ez a binlog befejeződött, és archiválni kell. Valahol cron kell állnunk az adatbázissal és ellenőriznünk kell, hogy készen van-e valami?
És ugyanígy a MySQL-visszaállítás során nincs olyan visszaállítási parancs, amely megmondaná a rendszernek, hogy ilyen és ehhez hasonló fájlok kellenek. Mielőtt elkezdené a fürt újjáépítését, tudnia kell, milyen fájlokra lesz szüksége. Önnek magának kell kitalálnia, milyen fájlokra lesz szüksége. De ezeket a problémákat valahogy ki lehet kerülni. (Egyéb: a MySQL már támogatott)
A riportban azokról az esetekről is szerettem volna beszélni, amikor a WAL-G nem megfelelő az Ön számára.
Ha nem rendelkezik szinkron replikával, a WAL-G nem garantálja, hogy az utolsó szegmens is megmarad. És ha az archiválás elmarad a történelem utolsó néhány szegmensétől, az kockázatot jelent. Ha nincs szinkron replika, nem javaslom a WAL-G használatát. Ennek ellenére elsősorban felhőtelepítésre tervezték, ami magas rendelkezésre állású megoldást jelent szinkron replikával, amely az utolsó lekötött bájtok biztonságáért felelős.
Gyakran látok embereket, akik egyszerre próbálják futtatni a WAL-G-t és a WAL-E-t. Támogatjuk a visszamenőleges kompatibilitást abban az értelemben, hogy a WAL-G vissza tud állítani egy fájlt a WAL-E-ből, és vissza tudja állítani a WAL-E-ben készült biztonsági másolatot. De mivel mindkét rendszer párhuzamos wal-push-t használ, elkezdenek lopni egymástól fájlokat. Ha a WAL-G-ben javítjuk, akkor is WAL-E-ben marad. A WAL-E-ben megnézi az archívum állapotát, látja a kész fájlokat és archiválja azokat, míg más rendszerek egyszerűen nem fognak tudni, hogy ez a WAL fájl létezett, mert a PostgreSQL nem próbálja meg másodszor archiválni.
Mit fogunk itt javítani a WAL-G oldalon? Nem tájékoztatjuk a PostgreSQL-t arról, hogy ez a fájl párhuzamosan került átvitelre, és amikor a PostgreSQL kéri, hogy archiváljuk, akkor már tudjuk, hogy egy ilyen fájl ezzel a mód-idővel és ezzel az md5-tel már archiválásra került, és egyszerűen azt mondjuk, hogy PostgreSQL - OK, minden készen áll anélkül, hogy lényegében bármit is tenne.
Ezt a problémát azonban nem valószínű, hogy megoldják a WAL-E oldalon, ezért jelenleg lehetetlen olyan archiválási parancsot létrehozni, amely archiválja a fájlt a WAL-G és a WAL-E fájlokban is.
Ráadásul vannak olyan esetek, amikor a WAL-G most nem megfelelő az Ön számára, de mindenképpen kijavítjuk.
Először is, jelenleg nincs beépített biztonsági másolat-ellenőrzésünk. Nincs ellenőrzésünk sem a biztonsági mentés, sem a helyreállítás során. Természetesen ez a felhőben valósul meg. De ez egyszerűen előzetes ellenőrzéssel, egyszerűen a fürt visszaállításával valósítható meg. Ezt a funkciót szeretném átadni a felhasználóknak. Az ellenőrzéssel azonban feltételezem, hogy a WAL-G-ben lehetséges lesz a fürt visszaállítása és elindítása, valamint füsttesztek futtatása: pg_dumpall a /dev/null-ba és amcheck indexellenőrzés.
Jelenleg a WAL-G-ben nincs mód egy biztonsági mentés elhalasztására a WAL-ról. Vagyis támogatunk valamilyen ablakot. Például az utolsó hét nap tárolása, az utolsó tíz biztonsági másolat tárolása, az utolsó három teljes biztonsági másolat tárolása. Gyakran jönnek az emberek, és azt mondják: „Szükségünk van egy biztonsági másolatra az újévi eseményekről, és meg akarjuk őrizni örökre.” A WAL-G még nem tudja, hogyan kell ezt megtenni. (Megjegyzés - Ezt már javítottuk. Bővebben - Biztonsági mentési lehetőség be )
És nem minden tengelyszegmenshez oldal-ellenőrző összegeket és integritás-ellenőrzéseket alkalmazunk a PITR érvényesítésekor.
Mindebből összeállítottam egy projektet a Google Summer of Code számára. Ha ismer olyan okos diákokat, akik szeretnének Go-ba írni valamit, és több ezer dollárt kapni egy cégtől „G” betűvel, akkor ajánljuk nekik projektünket. Mentorként fogok működni ebben a projektben, ők meg tudják csinálni. Ha nincs diák, akkor elviszem és nyáron magam is megcsinálom.
És sok más apró problémánk is van, amelyeken fokozatosan dolgozunk. És elég furcsa dolgok történnek.
Például, ha üres biztonsági másolatot ad a WAL-G-nek, az egyszerűen leesik. Például, ha azt mondja neki, hogy biztonsági másolatot kell készítenie egy üres mappáról. A pg_control fájl nem lesz ott. És azt fogja hinni, hogy valamit nem ért. Elméletileg ebben az esetben egy normál üzenetet kell írnia a felhasználónak, hogy elmagyarázza neki, hogyan kell használni az eszközt. De ez még csak nem is a programozás, hanem egy jó, érthető nyelv sajátossága.
Nem tudjuk, hogyan készítsünk offline biztonsági mentést. Ha az adatbázis hazudik, nem tudunk róla biztonsági másolatot készíteni. De itt minden nagyon egyszerű. Az LSN-en keresztül biztonsági mentéseket hívunk, amikor elindult. A mögöttes bázis LSN-jét be kell olvasni a vezérlőfájlból. És ez egy olyan meg nem valósult funkció. Számos biztonsági mentési rendszer képes biztonsági másolatot készíteni egy mögöttes adatbázisról. És kényelmes.
Jelenleg nem tudjuk megfelelően kezelni a tartalék hely hiányát. Mert általában nagy mentésekkel dolgozunk otthon. És nem értek hozzá. De ha valaki most Go-ban szeretne programozni, adjon hozzá a helykihagyásos hibák kezelését a vödörhöz. Mindenképpen megvizsgálom a lehívási kérelmet.
És a fő dolog, ami aggaszt bennünket, hogy a lehető legtöbb docker-integrációs tesztet szeretnénk, amely különféle forgatókönyveket ellenőriz. Jelenleg csak az alapvető forgatókönyveket teszteljük. Minden véglegesítésnél, de szeretnénk commit-onként ellenőrizni az általunk támogatott összes funkciót. Különösen például a PostgreSQL 9.4-9.5 támogatása lesz elegendő. Támogatjuk őket, mert a közösség támogatja a PostgreSQL-t, de nem ellenőrizzük commit-by-commit-ot, hogy megbizonyosodjunk arról, hogy minden nem hibás. És számomra úgy tűnik, hogy ez meglehetősen komoly kockázatot jelent.
A WAL-G több mint ezer klaszteren fut a Yandex adatbázis-kezelésben. És minden nap több száz terabájt adatról készít biztonsági másolatot.
Nagyon sok TEENDŐ van a kódunkban. Ha szeretnél programozni, gyere, várunk húzó kéréseket, várunk kérdéseket.
kérdések
Jó estét! Köszönöm! Feltételezem, hogy ha WAL-deltát használsz, valószínűleg nagymértékben az egész oldalas írásokra támaszkodik. És ha igen, csináltál teszteket? Gyönyörű grafikont mutattál. Mennyivel lesz szebb, ha az FPW ki van kapcsolva?
Nálunk az egész oldalas írás engedélyezve van, nem próbáltuk letiltani. Vagyis én, mint fejlesztő, nem próbáltam kikapcsolni. A kutatást végző rendszergazdák valószínűleg kutakodtak ebben a kérdésben. De szükségünk van FPW-re. Szinte senki sem tiltja le, mert különben lehetetlen másolatot készíteni a replikáról.
Köszönöm a beszámolót! Két kérdésem van. Az első kérdés az, hogy mi lesz az asztalterekkel?
Várjuk húzási kérést. Adatbázisaink SSD és NMVE lemezeken élnek, és erre a funkcióra nincs igazán szükségünk. Nem állok készen arra, hogy most komoly időt fordítsak arra, hogy jól csináljam. Szívből támogatom, hogy ezt támogassuk. Vannak, akik támogatták, de a nekik megfelelő módon támogatták. Csináltak egy villát, de nem kérnek húzást. (Hozzáadva a 0.2.13-as verzióhoz)
És a második kérdés. A legelején azt mondtad, hogy a WAL-G azt feltételezi, hogy egyedül működik, és nincs szükség csomagolóanyagra. Magam is használok wrappereket. Miért ne lehetne őket használni?
Azt akarjuk, hogy olyan egyszerű legyen, mint egy balalajka. Ez azt jelenti, hogy nincs szüksége semmire, csak egy balalajára. Azt akarjuk, hogy a rendszer egyszerű legyen. Ha rendelkezik olyan funkciókkal, amelyeket meg kell tennie egy szkriptben, akkor jöjjön el és mondja el nekünk – mi megtesszük a Go-ban.
Jó estét! Köszönjük a beszámolót! Nem tudtuk elérni, hogy a WAL-G működjön GPG visszafejtéssel. Normálisan titkosít, de nem akarja visszafejteni. Ez valami nem jött be nekünk? A helyzet lehangoló.
Hozzon létre egy problémát a GitHubon, és találjuk ki.
Vagyis nem találkoztál ezzel?
A hibajelentésnek van egy olyan funkciója, hogy amikor a WAL-G nem érti, hogy milyen fájlról van szó, megkérdezi: "Talán titkosítva van?" Talán egyáltalán nem a titkosítással van a probléma. Szeretném javítani a naplózást ebben a témában. Neki kell megfejteni. Jelenleg ezen a témán dolgozunk abból a szempontból, hogy nem igazán szeretjük a nyilvános és privát kulcsok megszerzésére szolgáló rendszer felépítését. Mert külső GPG-nek hívjuk, hogy az adja a kulcsait. Aztán ezeket a kulcsokat átvisszük a belső GPG-be, ami egy nyílt PGP, amit a WAL-G-n belül fordítanak le nekünk, és ott titkosításnak hívjuk. Ezzel kapcsolatban szeretnénk fejleszteni a rendszert, és támogatni kívánjuk a Libsodium titkosítást (Hozzáadva a 0.2.15-ös verzióhoz). Természetesen a dekódolásnak működnie kell, találjuk ki – több kell egy tünet, mint néhány szó. Valamikor összegyűlhetsz a hangszóró szobájában, és megnézheted a rendszert. (PGP titkosítás külső GPG nélkül – v0.2.9)
Helló! Köszönöm a beszámolót! Két kérdésem van. Furcsa vágyam van, hogy pg_basebackup-ot és WAL-t csináljak két szolgáltatónál, vagyis egy felhőt és egy másikat szeretnék csinálni. Van erre valami mód?
Ez most nem létezik, de érdekes ötlet.
Egyszerűen nem bízom az egyik szolgáltatóban, azt szeretném, ha egy másikban is ugyanaz lenne, minden esetre.
Az ötlet érdekes. Technikailag ezt egyáltalán nem nehéz megvalósítani. Az ötlet elvesztésének elkerülése érdekében megkérhetlek, hogy tegyen egy problémát a GitHubon?
Igen, természetesen.
Aztán amikor a diákok megjelennek a Google Summer of Code szolgáltatásban, hozzáadjuk őket a projekthez, hogy több munka álljon rendelkezésükre, hogy többet hozhassanak ki belőlük.
És a második kérdés. Probléma van a GitHubon. Szerintem már le van zárva. A helyreállítás során pánik van. És ennek legyőzéséhez külön szerelvényt készítettél. A kérdésekben igaz. És van lehetőség egy változó környezet létrehozására egy szálban. És ezért nagyon lassan működik. És találkoztunk ezzel a problémával, és még nem javították ki.
A probléma az, hogy valamilyen oknál fogva a tároló (CEPH) alaphelyzetbe állítja a kapcsolatot, amikor nagy egyidejűséggel érünk hozzá. Mit lehet tenni ez ellen? Az újrapróbálkozás logikája így néz ki. Megpróbáljuk újra letölteni a fájlt. Egy menetben számos fájlt nem töltöttünk le, azoknak készítünk egy másodikat, akik nem jelentkeztek be. És amíg legalább egy fájl betöltődik iterációnként, ismételjük, ismételjük és ismételjük. Javítottuk az újrapróbálkozás – exponenciális visszalépés – logikáját. De nem teljesen világos, hogy mit kezdjünk azzal, hogy a kapcsolat egyszerűen megszakad a tárolórendszer oldalán. Vagyis amikor feltöltünk egy adatfolyamba, az nem szakítja meg ezeket a kapcsolatokat. Mit javíthatunk itt? Hálózati szabályozásunk van, az egyes kapcsolatokat korlátozhatjuk az általuk küldött bájtok számával. Egyébként nem tudom, hogyan kezeljem azt, hogy az objektumtárolás nem teszi lehetővé, hogy párhuzamosan töltsünk vagy töltsünk le róla.
Nincs SLA? Nincs rájuk írva, hogyan hagyják magukat gyötörni?
A lényeg az, hogy azoknak, akik felvetik ezt a kérdést, általában saját páncélszekrényük van. Vagyis senki sem jön az Amazontól vagy a Google Cloud-tól vagy a Yandex Object Storage-tól.
Lehet, hogy a kérdés már nem neked szól?
A kérdés itt ebben az esetben nem mindegy, hogy kinek. Ha vannak ötletek, hogyan kezeljük ezt, tegyük meg a WAL-G-ben. De egyelőre nincsenek jó ötleteim, hogyan kezeljem ezt. Vannak olyan objektumtárolók, amelyek eltérő módon támogatják a biztonsági mentések listázását. Megkéred őket, hogy listázzák ki az objektumokat, és hozzáadják a mappát. A WAL-G ettől megijed – van itt valami, ami nem fájl, nem tudom visszaállítani, ami azt jelenti, hogy a biztonsági másolatot nem sikerült visszaállítani. Ez valójában egy teljesen visszaállított fürttel rendelkezik, de hibás állapotot ad vissza, mert az Object Storage furcsa információkat adott vissza, amelyeket nem értett meg teljesen.
Ez egy olyan dolog, ami a Mail felhőben történik.
Ha tudsz reprodukálni...
Következetesen reprodukálható...
Ha van reprodukálás, akkor azt hiszem, kísérletezzünk újrapróbálkozási stratégiákkal, és kitaláljuk, hogyan próbáljuk újra, és megértsük, mit kíván tőlünk a felhő. Talán három kapcsolaton stabil lesz számunkra, és nem szakítja meg a kapcsolatot, akkor óvatosan elérjük a hármat. Mert most nagyon gyorsan megszakítjuk a kapcsolatot, vagyis ha 16 szálas helyreállítást indítottunk, akkor az első újrapróbálkozás után 8 szál, 4 szál, 2 szál és egy lesz. Ezután egy adatfolyamba fogja húzni a fájlt. Ha vannak olyan mágikus értékek, mint például a 7,5 szál a legjobb a pumpáláshoz, akkor ezeken fogunk elidőzni, és megpróbálunk további 7,5 szálat készíteni. Itt van egy ötlet.
Köszönöm a beszámolót! Hogyan néz ki egy teljes munkafolyamat a WAL-G-vel való munkavégzéshez? Például abban a hülye esetben, amikor nincs delta az oldalak között. És vesszük és eltávolítjuk a kezdeti biztonsági másolatot, majd archiváljuk a tengelyt, amíg elkékül az arcunk. Itt, ha jól értem, törés van. Valamikor delta biztonsági másolatot kell készítenie az oldalakról, azaz valamilyen külső folyamat hajtja ezt, vagy hogyan történik ez?
A delta backup API meglehetősen egyszerű. Van egy szám – max delta lépések, így hívják. Alapértelmezésben nulla. Ez azt jelenti, hogy minden alkalommal, amikor biztonsági másolatot készít, letölt egy teljes biztonsági másolatot. Ha bármilyen pozitív számra módosítja, például 3-ra, akkor a következő biztonsági mentéskor a korábbi biztonsági mentések előzményeit tekinti meg. Látja, hogy nem léped túl a 3 delta láncot, és deltát csinál.
Vagyis minden alkalommal, amikor elindítjuk a WAL-G-t, megpróbál teljes biztonsági másolatot készíteni?
Nem, mi futtatjuk a WAL-G-t, és megpróbál deltát csinálni, ha a házirendek lehetővé teszik.
Durván szólva, ha minden alkalommal nullával futtatod, akkor úgy fog viselkedni, mint a pg_basebackup?
Nem, továbbra is gyorsabban fog futni, mert tömörítést és párhuzamosságot használ. A Pg_basebackup melléd helyezi a tengelyt. A WAL-G feltételezi, hogy beállította az archiválást. És figyelmeztetést ad, ha nincs konfigurálva.
A Pg_basebackup tengelyek nélkül is futtatható.
Igen, akkor szinte ugyanúgy fognak viselkedni. A Pg_basebackup a fájlrendszerbe másolja. Egyébként van egy új funkciónk, amit elfelejtettem megemlíteni. Most már tudunk biztonsági másolatot készíteni a fájlrendszerbe a pg_basebackup fájlból. Nem tudom miért van erre szükség, de van.
Például a CephFS-en. Nem mindenki akarja konfigurálni az objektumtárolót.
Igen, valószínűleg ezért tettek fel kérdést erről a funkcióról, hogy meg tudjuk csinálni. És megcsináltuk.
Köszönöm a beszámolót! Csak egy kérdés van a fájlrendszerbe másolással kapcsolatban. A dobozból most már támogatja a távoli tárhelyre másolást, például ha van polc az adatközpontban vagy valami más?
Ebben a megfogalmazásban ez nehéz kérdés. Igen, támogatjuk, de ez a funkció még nem szerepel egyetlen kiadásban sem. Vagyis minden előzetes verzió támogatja ezt, de a kiadási verziók nem. Ez a funkció a 0.2-es verzióban került hozzáadásra. Hamarosan biztosan megjelenik, amint kijavítjuk az összes ismert hibát. De ezt jelenleg csak a kiadás előtti állapotban lehet megtenni. A kiadás előtti verzióban két hiba található. Probléma a WAL-E helyreállításával, nem javítottuk. A legújabb kiadás előtt pedig egy hiba is bekerült a delta-backuphoz. Ezért mindenkinek javasoljuk a kiadási verziók használatát. Amint nincs több hiba a kiadás előtt, kijelenthetjük, hogy támogatjuk a Google Cloud-ot, az S3-kompatibilis dolgokat és a fájltárolást.
Helló, köszönöm a beszámolót. Ha jól értem, a WAL-G nem valamiféle központosított rendszer, mint a csaposok? Tervez-e elmozdulni ebbe az irányba?
A probléma az, hogy eltávolodtunk ettől az iránytól. A WAL-G az alap gazdagépen, a fürt gazdagépen és a fürt összes gazdagépén él. Amikor több ezer klaszterbe költöztünk, sok csapos üzemünk volt. És minden alkalommal, amikor valami szétesik bennük, az nagy probléma. Mivel javításra szorulnak, meg kell értenie, hogy jelenleg mely fürtök nem rendelkeznek biztonsági másolattal. Nem tervezem a WAL-G fejlesztését a mentési rendszerek fizikai hardverének irányába. Ha a közösség valami funkcionalitást akar itt, egyáltalán nem bánom.
Vannak csapataink, amelyek a tárolásért felelősek. És olyan jól érezzük magunkat, hogy nem mi vagyunk, hogy vannak különleges emberek, akik a fájljainkat olyan helyre teszik, ahol azok biztonságban vannak. Ott mindenféle okos kódolást végeznek, hogy ellenálljanak bizonyos számú fájl elvesztésének. Ők felelősek a hálózati sávszélességért. Ha van egy csapos, hirtelen rájöhet, hogy nagy forgalmú kis adatbázisok gyűltek össze ugyanazon a szerveren. Úgy tűnik, sok hely van rajta, de valamiért nem fér át minden a hálózaton. Lehet, hogy fordítva is kiderül. Ott sok a hálózat, vannak processzormagok, de itt nincsenek lemezek. És belefáradtunk abba, hogy valamivel zsonglőrködni kell, és áttértünk arra, hogy az adattárolás egy külön szolgáltatás, amiért külön speciális emberek felelősek.
PS Megjelent egy új verzió , amelyben használhatja a .walg.json konfigurációs fájlt, amely alapértelmezés szerint a postgres kezdőkönyvtárában található. A bash szkripteket elhagyhatja. A .walg.json példa ebben a számban található
videók:
Forrás: will.com