1. Eessõna
Hiljuti on Redis'i kasutatud projektis vahemäluna, et hõlbustada andmete jagamist mitme äriprotsessi vahel. Kuna Redis'i andmed salvestatakse mällu, siis kui püsivus ei ole seadistatud, kaob kõik andmed pärast redis'i taaskäivitust, seega tuleb lubada redis'i püsivuse funktsioon, et andmed kettale salvestada, ning kui redis taaskäivitatakse, saad andmeid kettalt taastada. Redis pakub kahte viisi püsimiseks: RDB püsivus (põhimõte on Reidsi andmebaasikirjete mälus salvestamine RDB püsivusele kettal) ja teine on AOF püsivus (põhimõte on kirjutada Reidsi operatsioonilogid faili lisana). Mis siis on nende kahe püsivuse meetodi ja kuidas seda muuta? Enamik asju, mida internetis loen, tutvustab, kuidas neid kahte meetodit konfigureerida ja kasutada, kuid puudub sissejuhatus nende kahe erinevuse kohta ega rakenduste stsenaariumites.
2. Erinevus nende kahe vahel
RDB püsivus tähendab andmestiku mälus oleva hetktõmmise kirjutamist kettale kindla ajavahemiku jooksul ning tegelik tööprotsess on alamprotsessi haruline, esmalt andmestiku ajutiseks failiks kirjutamine, seejärel eelmise faili asendamine pärast kirjutamise õnnestumist ja selle salvestamist binaarse tihendamisega.
AOF püsivus salvestab kõik serveri poolt töödeldavad kirjutamis- ja kustutamisoperatsioonid logi kujul ning päringutoimingut ei salvestata, vaid see salvestatakse tekstina ning saate faili avada, et näha üksikasjalikku operatsioonikirjet.
3. Nende kahe eelised ja puudused
Millised on RDB eelised?
1). Kui see on kasutatud, sisaldab kogu sinu Redis andmebaas ainult ühte faili, mis sobib ideaalselt failide varundamiseks. Näiteks võid soovida arhiveerida viimased 24 tundi iga tunni järel ja ka viimased 30 päeva iga päev. Sellise varundusstrateegiaga saame süsteemi katastroofilise rikke korral kergesti taastuda.
2). RDB on väga hea valik katastroofide taastamise jaoks. Sest me saame ühe faili lihtsalt tihendada ja selle teisele salvestusmeediumile üle kanda.
3). Maksimeeri jõudlust. Redis teenuse protsessi puhul piisab püsivuse alustamisel ainult alamprotsesside harutamine ning seejärel lõpetavad need püsivuse ülesanded, mis võib oluliselt takistada teenuseprotsessi IO-toimingute sooritamist.
4). Võrreldes AOF mehhanismiga, kui andmestik on suur, on RDB käivitamise efektiivsus kõrgem.
Millised on RDB puudused?
1). Kui soovid tagada andmete kõrge kättesaadavuse, st vältida andmekadu maksimaalsel määral, siis RDB ei ole hea valik. Sest kui süsteem enne planeeritud püsivust välja läheb, kaovad eelnevalt kettale kirjutatud andmed.
2). Kuna RDB aitab andmete püsivust fork-alamprotsesside kaudu, võib suur andmekogum põhjustada kogu serveri teenuse peatamise sadadeks millisekunditeks või isegi üheks sekundiks.
Millised on AOF-i eelised?
1). See mehhanism võib tuua suurema andmete turvalisuse, st andmete püsivuse. Redis'is on kolm sünkroniseerimisstrateegiat: sünkroniseerimine sekundis, sünkroniseerimine modifikatsiooni kohta ja desünkroniseerimine. Tegelikult toimub sünkroniseerimine sekundis samuti asünkroonselt ning selle efektiivsus on samuti väga kõrge, erinevus seisneb selles, et kui süsteem läheb rivist välja, kaovad muudetud andmed selle sekundi jooksul. Iga kord, kui muudatus sünkroniseeritakse, võib seda pidada sünkroniseerimise püsivuseks, st iga andmemuutus salvestatakse kohe kettale. On näha, et see meetod on kõige vähem efektiivne. Mis puudutab sünkroniseerimise puudumist, siis pole vaja rohkem öelda, arvan, et kõik saavad sellest õigesti aru.
2). Kuna mehhanism võtab kasutusele lisarežiimi logifailide kirjutamiseks, siis isegi kui kirjutamisprotsessi ajal tekib seisaku, ei hävita logifailis juba olemasolevat sisu. Kui aga kirjutame ainult poole andmetest ja süsteem seekord kokku jookseb, siis ärge muretsege, saame kasutada redis-check-aof tööriista, et aidata lahendada andmete järjepidevuse probleemi enne järgmist Redis'i algust.
3). Kui logi on liiga suur, saab Redis automaatselt ümberkirjutamismehhanismi sisse lülitada. See tähendab, et Redis kirjutab pidevalt muudatused vanale kettafailile lisarežiimis ning Redis loob ka uue faili, et salvestada, millised muudatuskäsklused selle perioodi jooksul täidetakse. Seetõttu saab andmete turvalisust paremini tagada, kui vahetada ümberkirjutuste vahel.
4). AOF sisaldab selget ja lihtsasti mõistetavat logifaili, mis salvestab kõik muudatused. Tegelikult saame andmete rekonstrueerimise ka selle faili kaudu lõpule viia.
Millised on OV-i puudused?
1). Sama arvu andmekogumite puhul on OF-failid tavaliselt suuremad kui RDB failid. RDB taastab suuri andmekogumeid kiiremini kui AOF.
2). Sõltuvalt sünkroniseerimisstrateegiast kipub AOF olema jooksmise efektiivsuse poolest aeglasem kui RDB. Lühidalt öeldes on sünkroniseerimispoliitika efektiivsus sekundis suhteliselt kõrge ning sünkroonse keelamise poliitika efektiivsus sama tõhus kui RDB oma.
Kriteeriumid nende kahe valikul on, kas süsteem on valmis ohverdama osa jõudlusest kõrgema vahemälu järjepidevuse (AOF) nimel, või kas ta on valmis mitte lubama varukoopiaid suurema jõudluse nimel, kui kirjutamistoimingud on sagedased, ning seejärel tegema varukoopiaid (RDB) salvestuse käsitsi käivitamisel. RDB-l on lõplikum järjepidev tähendus. Kuid tootmiskeskkond on tegelikult pigem nende kahe kombinatsioon.
4. Levinud konfiguratsioonid
RDB püsivuse konfiguratsioon
Redis viskab andmestiku hetktõmmise dump.rdb faili. Lisaks saame muuta Redis serveri dump-piltide sagedust konfiguratsioonifaili kaudu, pärast 6379.conf faili avamist otsime salvestust ja näeme järgmist konfiguratsiooniinfot:
AOF püsikonfiguratsioon
Redis profiilis on sünkroniseerimiseks kolm viisi:
Täielik konfiguratsioon:
Testkataloogi all luuakse uus fail "appendonly.aof" järgmiselt:
|
Postitatud 04.02.2021 13:47:27
|
|
|
|
Üürileandja|
Postitatud 08.02.2021 11:45:25
|
Postitatud 22.09.2021 20:26:16