A Redis egy fejlett kulcs-érték adatbázis. Hasonló a memcachedhez, de az adatok tartósak, és az adattípusok gazdagok. Vannak láncsorok, összekapcsolt listák, halmazok és rendezett gyűjtemények. Támogatja a gyűjtemények összegzésének, metsződésének és egymást kiegészítő (különbségének) kiszámítását a szerver oldalon, valamint különféle rendezési függvényeket is támogat. Tehát a Redis adatszerkezeti szerverként is tekinthető.
Minden Redis adatot memóriában tárolnak, majd időnként aszinkron módon tárolják a lemezre (ezt "félig állandó módnak" nevezik); Minden adatváltozást beírhatsz egy csak Append Only fájlba (AOF) (ezt "teljes kitartósági módnak" hívják).
Az első módszer a filesnapshotting: Az alapértelmezett redis snapshot formájában (bináris fájl, dump.rdb, ez a fájlnév megadható) marad a lemezre, és a konfigurációs fájl formátuma a következő: mentsük N M azt jelenti, hogy N másodpercen belül a redis snapshotot készít a lemezre, ha legalább M módosítás történik a redisben. Természetesen manuálisan is végrehajthatjuk a mentést vagy bgsave (aszinkron) módot, hogy pillanatképeket készítsünk.
Íme egy rövid bevezetés a működésbe: Ha Redisnek kitartó kellene, Redis elángolja a gyerekeljárást; A gyermek folyamat egy ideiglenes RDB fájlba írja az adatokat a lemezen; Amikor az alfolyamat befejezi az ideiglenes fájl megírását, lecseréli az eredeti RDB-t, amelynek előnye a másolás az íráson
Van egy persistence módszer is: Appendonly:filesnapshotting módszer. Ha a redis rendellenesen halott, akkor a legfrissebb adatok elvesznek (az elveszett adatok mennyisége a mentési szabályzat konfigurációjától függ), így ez a legnagyobb hátránya: amikor az üzleti forgalom nagy, az elveszett adatok sok. A csak kiegészítő módszer képes minden adatvesztést elérni, de a redis teljesítménye rosszabb. Az AOF a folyamat során fennmaradhat, csak a konfigurációs fájlban kell bekapcsolni (alapértelmezett nem), csak appendonly igen. Az AOF engedélyezése után minden alkalommal, amikor a redis végrehajt egy adatmódosítási parancsot, hozzáadódik az aof fájlhoz, és amikor újraindítják, az az AOF fájl "újrajátszás" módjára olvasható, hogy visszaállítsa az utolsó pillanatig a redis bezárása előtt.
NAPLÓ újraírás Ahogy az AOF fájl egyre nagyobb lesz az adatok módosításával, sok ilyen rekord kulcsban változik. Ezért a redis érdekes tulajdonsággal rendelkezik: az AOF fájl háttérben rekonstruálható anélkül, hogy befolyásolná a kliensoldali műveletet. A BGREWRITEAOF parancs bármikor végrehajtása a legrövidebb parancssort írja le a jelenlegi memóriában a lemezre, és ezek a parancsok teljesen felépíthetik az aktuális adathelyzetet felesleges változtatások nélkül (például állapotváltozások, számlálók stb.), csökkentve az AOF fájl méretét. Tehát OF-kor a redis a BGREWRITEAOF használatát is javasolja.
Az AOF fájl frissítésének három módja van, lásd az appendfsync konfigurációs paramétert: appendfsync mindig fsync-et hív, hogy minden módosítási parancs beküldésekor az AOF fájlhoz kerüljön, ami nagyon-nagyon lassú, de ugyanakkor nagyon biztonságos; az appendfsync every Sec másodpercenként fsync-et hív, hogy gyorsan eljuttassa az AOF fájlba, de egy másodpercen belül adatvesztést okozhat; Az appendfsync no az operációs rendszerre támaszkodik a frissítéshez, a redis nem frissíti aktívan az OV-t, ami a leggyorsabb, de a biztonság gyenge. Alapértelmezés szerint ajánlott a másodpercenkénti frissítés, hogy mind a sebesség, mind a biztonság figyelembe vegye.
Lehet, hogy rendszeri okokból van az AOF megsérült, a redis már nem tudja betölteni ezt az OV-t, az alábbi lépéseket követheted a javításhoz: Először készíts biztonsági mentést az AOF fájlról, és másold át egy másik helyre; Javítsd ki az eredeti OF fájlt, hajtsd végre: $redis-check-aof –fix; A diff –u parancsot használhatod, hogy megnézd, hol vannak a fájlok konzisztens a javítás előtt és után. Indítsd újra a Redis szolgáltatást.
Hogyan működik a LOG Rewrite: Ugyanez a másolás-írás módját használja: először a Redis elágazik egy gyermekfolyamatot; A gyermek folyamat a legutóbbi AOF-t írja egy ideiglenes fájlba; A szülőfolyamat fokozatosan írja le a legutóbb végrehajtott módosításokat a memóriába (ekkor még a régi AOF van írva, és ha meghibásodik, biztonságos újraírni); Amikor a gyermek folyamat befejezi az ideiglenes fájl újraírását, a szülőfolyamat jelet kap, és a memória korábbi inkrementális módosításait az ideiglenes fájl végére írja. Redis átnevezi a régi OF fájlt, átnevezi az ideiglenes fájlt, és elkezd írni az új OF-nak.
Végül, csak arra az esetre (gép összeomlik vagy lemez), ne felejtsd el rendszeresen menteni a *rdb *.aof fájlt, amelyet filesnapshotting vagy csak Append-only segítségével generált a távoli gépre. Félóránként crontabot használok SCP-hez. Nem használtam a redis master-slave funkcióját, mert fél órás biztonsági mentés rendben lesz, és úgy érzem, ez egy kicsit pazarlás a gép számára, ha master-slave-ed van. Ez végső soron a jelentkezéstől függ.
|
Közzétéve 2017. 08. 24. 16:37:45
|
|
|
