הגדרת שמירת נתונים ב-Redis: RDB ו-AOF לעמידות בתקלות

כברירת מחדל, Redis היא מסד נתונים בזיכרון. בעת הפעלה מחדש, כל הנתונים אובדים. ברוב התרחישים, זה בסדר אם Redis משמש רק כקאש. אבל אם Redis מאחסן תורי משימות, סשנים, מונים, או נתונים אחרים שלא ניתן לאבד—אתה צריך persistence. נתקלנו בזה כמעט בכל פרויקט שני: ללא RDB או AOF, לקוחות איבדו נתונים תפעוליים ונאלצו לשחזר ידנית מגיבויים. לדוגמה, בפרויקט עם תורי משימות, איבדנו עד 5 דקות של נתונים בין צילומי RDB, מה שהוביל להזמנות כפולות. לאחר יישום AOF עם everysec, ההפסדים ירדו לשנייה אחת. הגדרת Redis Persistence היא משימה בסיסית לכל שירות production עם דרישות עמידות נתונים. בואו נבחן את שני המנגנונים ואת השימוש המשולב שלהם.

ישנם שני מנגנונים: RDB (צילומי מצב) ו-AOF (קובץ append-only). ניתן להשתמש בהם בנפרד או יחד. הגדרה נכונה היא הבסיס לשחזור אמין עם אובדן נתונים של שנייה אחת לכל היותר.

איך RDB עובד

RDB שומר צילום מלא של הנתונים לקובץ בינארי dump.rdb. הגדרה באמצעות הוראת save:

save 900 1 save 300 10 save 60 10000 

זה אומר: שמור אם לפחות מפתח אחד השתנה ב-900 שניות, או 10 מפתחות ב-300 שניות, או 10000 מפתחות ב-60 שניות. בעת הפעלה מחדש, Redis טוען את dump.rdb האחרון.

החיסרון העיקרי של RDB הוא אובדן נתונים בין צילומי מצב. אם Redis קורס 5 דקות לפני צילום המצב הבא, אתה מאבד 5 דקות של שינויים. זה קריטי בפרויקטים עם עומס גבוה.

לפי התיעוד הרשמי של Redis, צילום מצב מבוצע באמצעות fork()—תהליך ילד כותב נתונים לדיסק בזמן שההורה ממשיך לטפל בבקשות. במהלך fork(), Redis עלול לחוות עליות חביון קלות—במערך נתונים גדול (10+ GB) זה יכול להיות מספר שניות. קריטי עבור יישומים עם חביון נמוך.

צילום ידני ללא חסימה: BGSAVE. עם חסימה (לגיבוי): SAVE.

מה זה AOF?

AOF כותב כל פקודת כתיבה לקובץ לוג. בעת הפעלה מחדש, Redis משחזר את כל ה-AOF כדי לשחזר נתונים.

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb"}

Wait, the original had "no-appendfsync-on-rewrite no" as a single token? Actually it's a directive with value "no". But the flattened line has "no-appendfsync-on-rewrite no" which is directive and value. Similarly "auto-aof-rewrite-percentage 100" and "auto-aof-rewrite-min-size 64mb". So each directive on its own line. Also "appendonly yes" etc. So I'll put each directive on its own line. The original had spaces between directives. So I'll split on spaces but careful: "appendfilename "appendonly.aof"" has a quoted string with space? No, it's "appendonly.aof" no space. So splitting on spaces works. But there is "no-appendfsync-on-rewrite no" - that's two tokens. So each directive is a key-value pair. So I'll put each pair on its own line. The original had "appendonly yes appendfilename ..." so I'll break after each value. So lines:

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

That's it. No indentation needed. So JSON code string with 
.<｜end▁of▁thinking｜>{"code": "appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

appendfsync הוא הפרמטר המרכזי:

• always – fsync לאחר כל פקודה. אמינות מקסימלית, מהירות מינימלית.
• everysec – fsync כל שנייה. אובדן נתונים מקסימלי של שנייה אחת במקרה של כשל. איזון בין אמינות וביצועים.
• no – fsync נקבע על ידי מערכת ההפעלה. מהיר, אבל אובדן נתונים לא צפוי.

everysec היא הבחירה הנכונה ברוב המקרים.

AOF גדל עם הזמן. auto-aof-rewrite-percentage 100 אומר: כאשר הקובץ מכפיל את עצמו ביחס לגודלו לאחר השכתוב האחרון, הפעל BGREWRITEAOF, שיוצר AOF קומפקטי רק עם הפקודות הנוכחיות (ללא SET/DEL ביניים של אותו מפתח).

למה להשתמש בשני המנגנונים יחד?

כאשר שני המנגנונים מופעלים, בעת הפעלה מחדש Redis משתמש ב-AOF (מדויק יותר). RDB נשאר כצילום מצב מהיר לגיבויים.

save 900 1 appendonly yes appendfsync everysec 

זו ההגדרה המומלצת ל-production שבו עמידות נתונים חשובה. אנו משתמשים בזה ב-80% מהפרויקטים שלנו, כולל שירותים עם עומס גבוה.

איך לבחור בין RDB ל-AOF?

השווה פרמטרים מרכזיים:

מותאם לתרחישים ספציפיים:

לתרחיש קאש טהור

אם Redis הוא קאש טהור וניתן לחמם נתונים בעת הפעלה מחדש:

save "" appendonly no 

בטל את כל מנגנוני ה-persistence. Redis יהיה מהיר יותר (ללא I/O לדיסק), ו-fork() לצילומי מצב לא יגרום לעליות חביון. חיסכון ב-CPU וב-RAM – עד 30% בהתאם לעומס.

איך אנו מגדירים Redis Persistence מקצה לקצה

התהליך אורך 2 עד 3 ימים בהתאם לנפח הנתונים ולדרישות עמידות התקלות:

1. ניתוח עומס ומיפוי תרחישים – קביעה אם יש צורך ב-persistence, בחירת מנגנונים.
2. הגדרה – קביעת מרווחי save, פרמטרי AOF, שכתוב, fsync.
3. בדיקת שחזור – סימולציית כשל, אימות שחזור נתונים בזמן הצפוי.
4. ניטור – הוספת מדדים (משך RDB, שכתוב AOF, חביון fork) ל-Prometheus/Grafana.
5. תיעוד והדרכה – תיעוד runbook לצוות התמיכה.

מה כלול בעבודה

• הגדרת RDB ו-AOF באמצעות Ansible (Terraform).
• בדיקות ביצועים ושחזור (תוצאות בדוח).
• ניטור: לוחות מחוונים של Grafana, התראות על חביון fork.
• תיעוד runbook: איך לבדוק, להפעיל מחדש, לפתור תקלות.
• הדרכת צוות: מפגש מקוון של שעה עם הדגמה.

טעויות הגדרה נפוצות

• שימוש ב-appendfsync always שלא לצורך – גורם לירידה של פי 10 ב-IOPS.
• save תכוף מדי (כל 60 שניות עם 10k שינויים) – עומס יתר על הדיסק.
• שכחת שכתוב AOF – הקובץ גדל לעשרות גיגה-בייט.
• הגדרת stop-writes-on-bgsave-error no – סיכון לאובדן נתונים במקרה של כשל בצילום.

הבטחות וניסיון

עלות ההגדרה מחושבת באופן אישי בהתאם למורכבות הארכיטקטורה. אנו מבטיחים שחזור נתונים בתוך ה-RTO/RPO שצוין בתנאי שהלוגים שלמים. עם ניסיון של למעלה מ-5 שנים ב-Redis ו-50+ פרויקטי production מוצלחים, אנו מספקים persistence אמין. כדי להעריך את הפרויקט שלך, צור קשר – נבחר את ההגדרה האופטימלית ונבדוק אותה בסביבת ה-staging שלך. קבל ייעוץ היום.

הזמן הגדרת Redis Persistence ממהנדסים מנוסים – הבטח עמידות תקלות לשירות שלך.