Redis persistentligi: RDB yoki AOF va ma’lumotni yo‘qotmaslik

Qisqa javob: RDB, AOF va nimani tanlash

Redis ma’lumotlarni xotirada saqlaydi va diskka ikki usuldan biri bilan yozadi:

• RDB — butun bazaning ixcham binar faylga davriy snapshoti.
• AOF (Append Only File) — barcha yozish amallari jurnali, qayta ishga tushganda qaytadan bajariladi.

Qisqasi: kesh uchun persistentlikni ko‘pincha o‘chirib qo‘yish mumkin, sessiyalar, navbatlar va qayta yaratib bo‘lmaydigan har qanday ma’lumot uchun AOFni yoqing va zaxira uchun RDBni qoldiring.

RDB qanday ishlaydi

save qoidalariga ko‘ra Redis fork() chaqiradi: bola jarayon snapshotni diskka yozadi, asosiy jarayon esa mijozlarga xizmat qilishda davom etadi.

# 3600 s ichida kamida 1 o‘zgarish, 300 s ichida 100 ta
# yoki 60 s ichida 10000 ta o‘zgarish bo‘lsa snapshot
save 3600 1 300 100 60 10000
dbfilename dump.rdb

Nimani bilish muhim:

• Oxirgi snapshotdan keyin yozilgan hamma narsa nosozlikda yo‘qoladi.
• fork() copy-on-write mexanizmidan foydalanadi: snapshot vaqtida o‘zgargan xotira sahifalari nusxalanadi. Faol yozuvda serverga RAM zaxirasi kerak.
• Linuxda Redis hujjatlari vm.overcommit_memory = 1 ni tavsiya qiladi, aks holda fondagi saqlash muvaffaqiyatsiz tugashi mumkin.

AOF qanday ishlaydi va fsync siyosatlari

Har bir yozish buyrug‘i jurnalga qo‘shiladi. Jurnal diskka qanchalik tez-tez haqiqatan yozilishini appendfsync belgilaydi:

everysec — standart qiymat va ko‘pchilik vazifalar uchun oqilona murosa.

Jurnal doimiy o‘sib boradi, shuning uchun Redis uni vaqti-vaqti bilan ixcham shaklda qayta yozadi (BGREWRITEAOF), bu ham fork() orqali. Chastotani auto-aof-rewrite-percentage va auto-aof-rewrite-min-size belgilaydi.

Gibrid rejim

aof-use-rdb-preamble yes bo‘lganda qayta yozilgan AOF RDB formatidagi snapshot bilan boshlanadi, undan keyin faqat yangi buyruqlar keladi. Bu RDB kabi tez ishga tushish va AOF darajasidagi ishonchlilikni beradi. AOF yoqilgan bo‘lsa, Redis ishga tushganda ma’lumotlarni aynan undan tiklaydi.

Xotira va siqib chiqarish

maxmemory ma’lumotlar hajmini cheklaydi, maxmemory-policy esa limitga yetilganda nima qilishni hal qiladi:

• noeviction — yangi yozuvlar xato oladi, hech narsa o‘chirilmaydi;
• allkeys-lru / allkeys-lfu — barcha kalitlar orasidan uzoq vaqt yoki kam ishlatilganlari o‘chiriladi;
• volatile-lru / volatile-lfu / volatile-ttl — faqat TTL ga ega kalitlar o‘chiriladi;
• allkeys-random / volatile-random — tasodifiy kalitlar.

Asosiy jihat: siqib chiqarish ham ma’lumot yo‘qotishdir. Agar Redisda navbatlar saqlansa va siyosat allkeys-lru bo‘lsa, vazifalar xatosiz va server nosozligisiz yo‘qolib qolishi mumkin.

Nazorat ro‘yxati: Redis kesh sifatida

maxmemory 2gb
maxmemory-policy allkeys-lru
save ""
appendonly no

• Ilova bo‘sh kesh bilan ishlay olishi va uni asosiy bazadan to‘ldira olishi kerak.
• Kalitlarga TTL qo‘ying.
• Qayta ishga tushgandan keyingi sovuq start baza uchun juda og‘ir bo‘lsa, kam-kam RDB snapshotlarini qoldiring.

Nazorat ro‘yxati: Redis sessiya yoki navbatlar uchun asosiy ombor sifatida

appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
save 3600 1 300 100 60 10000
maxmemory 2gb
maxmemory-policy noeviction

• Navbatlar uchun noeviction majburiy; sessiyalar uchun, agar foydalanuvchining qayta kirishi maqbul narx bo‘lsa, volatile-lru ham bo‘ladi.
• Limit kutilmagan holatga aylanmasligi uchun xotira sarfi va yozish xatolarini kuzating.
• fork() uchun RAM zaxirasini saqlang.
• RDB fayllarini boshqa serverga yoki obyekt omboriga nusxalang. Replikatsiya zaxira nusxani almashtirmaydi: o‘chirilgan kalit replikadan ham darhol yo‘qoladi.
• Zaxiradan tiklashni test serverida muntazam tekshirib turing.
• Muhim ma’lumotlar uchun replika va avtomatik almashtirishni qo‘shing.