1. Predgovor
V zadnjem času se Redis uporablja kot predpomnilnik v projektu za lažje deljenje podatkov med več poslovnimi procesi. Ker so Redis podatki shranjeni v pomnilniku, če persistence ni nastavljena, bodo vsi podatki izgubljeni po ponovnem ponovnem zagonu Redisa, zato morate omogočiti funkcijo persistence v Redisu, da shrani podatke na disk, in ko se Redis ponovno zažene, lahko podatke obnovite z diska. Redis ponuja dva načina za obstojnost: RDB persistence (načelo je, da se zapisi Reidsove podatkovne baze v pomnilnik v RDB persistence na disk) in drugo je AOF persistence (načelo je zapisovanje Reidsovih operacijskih dnevnikov v datoteko v obliki priloge). Kakšna je torej razlika med tema dvema metodama obstojnosti in kako se odločiti za spremembo? Večina stvari, ki sem jih prebral na internetu, razlaga, kako konfigurirati in uporabljati ti dve metodi, vendar ni uvoda v razliko med njima in v katerih aplikacijskih scenarijih uporabiti.
2. Razlika med obema
Obstojnost RDB se nanaša na zapisovanje posnetka podatkovnega nabora v pomnilniku na disk v določenem časovnem intervalu, pri čemer je dejanski postopek delovanja fork podprocesa, najprej zapiše podatkovni nabor v začasno datoteko, nato po uspešnem zapisovanju zamenja prejšnjo datoteko in jo shrani z binarno kompresijo.
AOF zabeleži vsako operacijo pisanja in brisanja, ki jo strežnik obdela, v obliki dnevnika, poizvedba pa ne bo zabeležena, ampak bo zapisana v besedilu, datoteko pa lahko odprete in si ogledate podroben zapis operacije.
3. Prednosti in slabosti obeh
Kakšne so prednosti RDB?
1). Ko je to uporabljeno, bo celotna vaša Redis baza vsebovala le eno datoteko, kar je idealno za varnostne kopije datotek. Na primer, morda boste želeli arhivirati zadnjih 24 ur vsako uro in tudi zadnjih 30 dni vsak dan. S takšno strategijo varnostnega kopiranja se lahko v primeru katastrofalne okvare sistema enostavno obnovimo.
2). RDB je zelo dobra izbira za obnovo po nesrečah. Ker lahko enostavno stisnemo eno datoteko in jo prenesemo na drug pomnilniški medij.
3). Maksimirati zmogljivost. Za Redis storitveni proces je edino, kar mora storiti ob začetku persistence, razdeliti podprocese, nato pa bodo podprocesi opravili te naloge persistence, kar lahko močno prepreči, da servisni proces izvaja IO operacije.
4). V primerjavi z mehanizmom AOF bo zagonska učinkovitost RDB, če je podatkovna zbirka velika, višja.
Kakšne so slabosti RDB?
1). Če želite zagotoviti visoko razpoložljivost podatkov, torej se čim bolj izogniti izgubi podatkov, potem RDB ne bo dobra izbira. Ker ko sistem preneha delovati pred načrtovano vztrajnostjo, se podatki, ki so bili prej zapisani na disk, izgubijo.
2). Ker RDB pomaga pri ohranjanju podatkov prek fork podprocesov, lahko ob veliki podatkovni zbirki povzroči, da celoten strežnik ustavi storitev za več sto milisekund ali celo za eno sekundo.
Kakšne so prednosti AOF?
1). Ta mehanizem lahko prinese večjo varnost podatkov, torej obstojnost podatkov. V Redisu so na voljo 3 strategije sinhronizacije: sinhronizacija na sekundo, sinhronizacija na spremembo in desinhronizacija. Pravzaprav je sinhronizacija na sekundo prav tako asinhrona, njena učinkovitost pa je zelo visoka, razlika je v tem, da ko sistem preneha delovati, se spremenjeni podatki izgubijo v tej sekundi. In vsakič, ko je sprememba sinhronizirana, jo lahko razumemo kot vztrajnost sinhronizacije, torej je vsaka sprememba podatkov takoj zabeležena na disk. Predvidljivo je, da je ta metoda najmanj učinkovita. Kar zadeva odsotnost sinhronizacije, ni treba več razlagati, mislim, da jo lahko vsi pravilno razumejo.
2). Ker mehanizem uporablja način dodajanja za zapisovanje dnevniških datotek, tudi če med pisanjem pride do izpada, vsebina, ki že obstaja v dnevniku, ne bo uničena. Če pa zapišemo le polovico podatkov in sistem tokrat crkne, brez skrbi, lahko uporabimo orodje redis-check-aof, da rešimo problem konsistentnosti podatkov pred naslednjim zagonom Redisa.
3). Če je dnevnik prevelik, lahko Redis samodejno omogoči mehanizem prepisovanja. To pomeni, da Redis neprekinjeno zapisuje podatke o spremembah v staro diskovno datoteko v načinu dodajanja, Redis pa ustvari tudi novo datoteko za beleženje, katere ukaze za spreminjanje se izvajajo v tem obdobju. Zato je varnost podatkov bolje zagotovljena pri preklapljanju med prepisi.
4). AOF vsebuje jasno, lahko razumljivo datoteko dnevnika, ki beleži vse spremembe. Pravzaprav lahko rekonstrukcijo podatkov dokončamo tudi preko te datoteke.
Kakšne so slabosti OV?
1). Za enako število podatkovnih nizov so OF datoteke običajno večje od RDB datotek. RDB obnovi velike podatkovne zbirke hitreje kot AOF.
2). Glede na strategijo sinhronizacije je AOF običajno počasnejši od RDB glede učinkovitosti izvajanja. Skratka, učinkovitost politike sinhronizacije na sekundo je razmeroma visoka, učinkovitost politike sinhronega onemogočanja pa je enako učinkovita kot pri RDB.
Kriteriji za izbiro obeh so, ali je sistem pripravljen žrtvovati del zmogljivosti v zameno za večjo konsistentnost predpomnilnika (AOF) ali pa je pripravljen ne omogočiti varnostnih kopij v zameno za boljšo zmogljivost, ko so zapisovalne operacije pogoste, in nato izvajati varnostne kopije (RDB) ob ročnem zagonu shranjevanja. RDB ima bolj dokončen in dosleden pomen. Vendar pa je produkcijsko okolje pravzaprav bolj kombinacija obeh.
4. Pogoste konfiguracije
Konfiguracija obstojnosti RDB
Redis v datoteko dump.rdb naloži posnetek podatkovnega nabora. Poleg tega lahko spreminjamo tudi pogostost posnetkov izpisovanja Redis strežnika skozi konfiguracijsko datoteko; po odprtju datoteke 6379.conf iščemo shranjeno datoteko in vidimo naslednje podatke o konfiguraciji:
Trajna konfiguracija AOF
V profilu Redis obstajajo trije načini sinhronizacije:
Popolna konfiguracija:
Nova datoteka "appendonly.aof" bo ustvarjena v testni mapi, kot sledi:
|
Objavljeno na 4. 02. 2021 13:47:27
|
|
|
|
Najemodajalec|
Objavljeno na 8. 02. 2021 11:45:25
|
Objavljeno na 22. 09. 2021 20:26:16