Redis noturība: RDB pret AOF un kas jums patiesībā vajadzīgs

Redis noturība (persistence) ir viens no tiem iestatījumiem, par kuriem neviens nedomā, līdz serveris restartējas un puse datu ir pazudusi – vai visi. Redis datu kopu glabā atmiņā, un tas, kas pārdzīvo avāriju, pilnībā atkarīgs no diviem mehānismiem: RDB momentuzņēmumiem un pievienošanas žurnāla (append-only file, AOF). Tie aizsargā pret dažādām lietām, maksā atšķirīgi, un noklusējumi var neatbilst tam, ko pieņem jūsu lietotne. Šis ceļvedis, balstoties uz Redis noturības dokumentāciju, izskaidro, ko katrs no tiem patiesībā garantē.

Četri varianti

• RDB: visas datu kopas momentuzņēmumi noteiktos intervālos.
• AOF: katras rakstīšanas komandas žurnāls, ko atskaņo startējot.
• RDB + AOF: abi vienā instancē.
• Bez noturības: dažreiz izmanto tīrām kešatmiņām.

Dokumentācijas ieteikums ir īss: izmantojiet abus, ja vēlaties datu drošību, kas salīdzināma ar PostgreSQL; tikai RDB, ja katastrofas gadījumā varat samierināties ar dažu minūšu datu zudumu. Tikai AOF tā neiesaka, jo laiku pa laikam izveidots RDB momentuzņēmums noder rezerves kopijām, ātrākiem restartiem un AOF dzinēja kļūdu gadījumā.

RDB momentuzņēmumi: kompakti, ātri restartējami, bet zaudējat minūtes

Ar RDB Redis izveido bērnprocesu (fork), bērns ieraksta datu kopu pagaidu failā, un šis fails atomāri aizstāj veco dump.rdb. Vecākprocess turpina apkalpot klientus un pats diskā neraksta. Noklusējuma konfigurācija izskatās šādi:

# defaults when no "save" line is given (redis.conf, Redis 7.4)
# save 3600 1 300 100 60 10000
dbfilename dump.rdb
stop-writes-on-bgsave-error yes

Bez skaidras save rindas Redis veido momentuzņēmumu pēc stundas, ja mainījusies vismaz 1 atslēga, pēc 5 minūtēm, ja mainījušās vismaz 100, un pēc 60 sekundēm, ja mainījušās vismaz 10 000. Klusā sistēmā tas var nozīmēt stundu starp momentuzņēmumiem. Viss, kas ierakstīts pēc pēdējā momentuzņēmuma, tiek zaudēts, ja Redis apstājas bez korektas izslēgšanas: avārija, OOM process nogalināšana, strāvas pārtraukums.

Kur RDB ir labs: viens kompakts fails, ideāls rezerves kopijām un kopēšanai uz citu vietu, un ar lielām datu kopām ātrāki restarti nekā ar AOF. Un detaļa, kas pārsteidz: noklusējums ir stop-writes-on-bgsave-error yes, tāpēc, ja momentuzņēmumi ir ieslēgti un pēdējā fona saglabāšana neizdevās (pilns disks, atļaujas), Redis pārtrauc pieņemt rakstīšanu. Tas ir apzināti, bet diska problēma pārvēršas lietotnes dīkstāvē.

fork() cena

Gan RDB momentuzņēmumi, gan AOF pārrakstīšana izmanto fork(). Dokumentācija brīdina, ka ar lielu datu kopu fork var aizņemt laiku un apturēt klientu apkalpošanu uz dažām milisekundēm vai pat uz sekundi, ja datu kopa ir ļoti liela un procesors lēns. Kopēšana pie rakstīšanas (copy-on-write) arī nozīmē, ka saglabāšanas laikā mainītās lapas tiek dublētas, tāpēc instancei ar daudz rakstīšanas momentuzņēmuma laikā vajadzīga atmiņas rezerve. Atmiņas pusi aplūkojam ceļvedī par Redis OOM un maxmemory. latest_fork_usec sadaļā INFO stats rāda, cik ilgi ilga pēdējais fork.

AOF: daudz noturīgāks, ar fsync izvēli

Ar appendonly yes katra komanda, kas maina datu kopu, tiek pievienota žurnālam. Galvenais iestatījums ir appendfsync:

• always: fsync pēc katras rakstīšanas partijas. Dokumentācija to sauc par "ļoti ļoti lēnu, ļoti drošu", lai gan tas grupē paralēlu klientu apstiprinājumus.
• everysec: fsync reizi sekundē fona pavedienā. Tas ir noklusējums un ieteicamā politika: ātri, un katastrofā var zaudēt apmēram vienu sekundi rakstīšanas.
• no: izvadi diskā atstāj operētājsistēmai. Ātrākais un vismazāk drošais; Linux parasti izvada ik pēc 30 sekundēm atkarībā no kodola iestatījumiem.

Tipiska AOF konfigurācija:

appendonly yes
appendfsync everysec          # default; alternatives: always, no
appenddirname "appendonlydir"
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-use-rdb-preamble yes
aof-load-truncated yes

Žurnāls aug ar katru rakstīšanu, tāpēc Redis to pārraksta fonā: auto-aof-rewrite-percentage 100 izraisa pārrakstīšanu, kad AOF kopš pēdējās pārrakstīšanas izaudzis par 100%, ja tas ir vismaz auto-aof-rewrite-min-size. To var sākt arī manuāli ar BGREWRITEAOF. Ar aof-use-rdb-preamble yes pārrakstītā bāze tiek glabāta RDB formātā, kas ielādējas ātrāk.

Kopš Redis 7.0 AOF vairs nav viens fails. Tā ir direktorija (pēc noklusējuma appendonlydir) ar vienu bāzes failu, vienu vai vairākiem inkrementāliem failiem un manifestu, kas tos sasaista. Tas ir svarīgi rezerves kopijām, skatīt zemāk. Dokumentācija divas izmaksas min tikai versijām pirms 7.0: pārrakstīšanas laikā ienākošā rakstīšana tika buferēta atmiņā un diskā rakstīta divreiz.

Kad AOF ir bojāts

Ja Redis avarēja rakstīšanas vidū vai disks piepildījās, pēdējā komanda AOF var būt nogriezta. Ar aof-load-truncated yes (noklusējums) Redis nepilnīgo komandu atmet, ieraksta brīdinājumu žurnālā un startē. Ja fails ir bojāts vidū, Redis atsakās startēt. Dokumentācija iesaka izveidot kopiju un vispirms palaist redis-check-aof bez --fix, lai redzētu, kur ir problēma: ļaujot rīkam to salabot, var tikt atmests viss no bojātās daļas līdz faila beigām.

Vēl viena noderīga īpašība: ja kāds kļūdas pēc izpilda FLUSHALL un kopš tā nav notikusi pārrakstīšana, varat apturēt serveri, izņemt pēdējo komandu no AOF un startēt Redis no jauna ar neskartiem datiem. Tas darbojas tikai tad, ja rīkojaties pirms nākamās pārrakstīšanas.

Pāreja no RDB uz AOF bez datu zaudēšanas

Šeit cilvēki zaudē datus. Ja vienkārši iestatāt appendonly yes failā redis.conf un restartējat, Redis startē ar ieslēgtu AOF, un, kad AOF ir ieslēgts, tas ielādē AOF, nevis RDB failu, jo AOF tiek uzskatīts par pilnīgāko. Dokumentācija skaidri brīdina, ka procedūras neievērošana "var izraisīt datu zudumu". Drošais veids strādājošā serverī:

1. Izveidojiet jaunākā dump.rdb rezerves kopiju un nokopējiet to drošā vietā.
2. Ieslēdziet AOF strādājošā serverī un ļaujiet tam izveidot AOF no atmiņas:

   redis-cli CONFIG SET appendonly yes
   redis-cli INFO persistence    # wait: aof_rewrite_in_progress:0, aof_last_bgrewrite_status:ok
   redis-cli CONFIG REWRITE      # make the change survive a restart

3. Pārliecinieties, ka redis.conf atbilst darbojošajai konfigurācijai. Ja to izlaižat, nākamais restarts atgriezīs veco konfigurāciju.
4. Pirms jebkura restarta pārbaudiet, ka AOF pārrakstīšana ir pabeigta (aof_rewrite_in_progress un aof_rewrite_scheduled ir 0, aof_last_bgrewrite_status ir ok). Pēc restarta salīdziniet atslēgu skaitu ar iepriekšējo.

Rezerves kopijas un monitorings

• RDB failus var droši kopēt, kamēr Redis darbojas, jo pabeigts RDB nekad netiek mainīts, un jaunais tiek atomāri pārdēvēts savā vietā. Dokumentācija iesaka kopijas katru stundu un katru dienu, vecās dzēšot ar ieplānotu uzdevumu, un vismaz vienu momentuzņēmumu dienā pārsūtīt ārpus datu centra vai vismaz ārpus mašīnas.
• AOF rezerves kopijām kopš 7.0 vajadzīga uzmanība. AOF direktorijas kopēšana pārrakstīšanas laikā var dot nederīgu kopiju. Dokumentētā pieeja: iestatīt auto-aof-rewrite-percentage 0, pārliecināties, ka pārrakstīšana nenotiek, nokopēt (vai izveidot cietās saites) AOF direktorijas failus un pēc tam atjaunot iepriekšējo vērtību.
• Redis 8.10 pievieno BACKUP komandu saimi (BACKUP START, SEAL, LIST, CLEANUP), kas izveido atjaunojamu bāzes un inkrementa kopiju bez manuālas AOF pārrakstīšanas apturēšanas. Ja izmantojat vecāku versiju vai Valkey, pārbaudiet, kuras komandas jūsu serveris patiesībā atbalsta.
• Pārbaudiet atjaunošanu. Momentuzņēmums, ko neviens nav ielādējis, ir cerība. Mūsu ceļvedis par rezerves kopiju un atjaunošanas testēšanu attiecas arī uz Redis.

Monitoringam šie INFO lauki ir tie, par kuriem jābrīdina:

redis-cli INFO persistence | grep -E \
  'rdb_last_bgsave_status|rdb_last_save_time|rdb_changes_since_last_save|aof_enabled|aof_last_write_status|aof_last_bgrewrite_status'
redis-cli INFO stats | grep latest_fork_usec

Ja rdb_last_bgsave_status vai aof_last_write_status nav ok vai ja rdb_last_save_time ir tālu pagātnē, kamēr rdb_changes_since_last_save turpina augt, jūsu noturība nedara to, ko domājat.