הגדרת Redis Sentinel: מעבר אוטומטי ללא אובדן נתונים

port 26379
daemonize yes
logfile /var/log/redis/sentinel.log
sentinel monitor mymaster redis-primary.internal 6379 2
sentinel auth-pass mymaster your-redis-password
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

quorum — שם ה-master (שרירותי), כתובת, פורט, ו-sentinel1.internal:26379 sentinel2.internal:26379 sentinel3.internal:26379 | +--> redis-primary.internal:6379 +--> redis-replica.internal:6379 — כמה Sentinels חייבים להסכים שה-master מושבת. עם שלושה Sentinels ו-port 26379 daemonize yes logfile /var/log/redis/sentinel.log sentinel monitor mymaster redis-primary.internal 6379 2 sentinel auth-pass mymaster your-redis-password sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 60000 sentinel parallel-syncs mymaster 1 , failover מתחיל אם 2 מתוך 3 Sentinels אינם יכולים להגיע ל-Primary.

sentinel monitor mymaster redis-primary.internal 6379 2 — לאחר 5 שניות ללא תגובה, Sentinel מחשיב את ה-Primary כמושבת subjectively (SDOWN). כאשר קוורום של Sentinels מסכים, הוא הופך ל-objectively down (ODOWN) ו-failover מתחיל.

quorum — זמן מקסימלי ל-failover. אם לא הושלם תוך 60 שניות, ה-failover נחשב ככושל.

quorum 2 — כמה replicas מסונכרנים עם ה-Primary החדש במקביל לאחר failover. עם down-after-milliseconds 5000, הם מסונכרנים ברצף, מה שבטוח יותר עבור כמויות נתונים גדולות.

הגדרת Redis עבור Sentinel

על שני ה-Primary וה-Replica ב-failover-timeout 60000:

requirepass your-redis-password masterauth your-redis-password 

שתי הסיסמאות חייבות להתאים — זו הסיסמה עבור replication ועבור Sentinel. כאשר Replica מקודם ל-Primary במהלך failover, הוא חייב להיות מסוגל לאמת replicas חדשים.

על ה-Replica, בנוסף:

replicaof redis-primary.internal 6379 replica-read-only yes 

כיצד אפליקציות מתחברות דרך Sentinel

האפליקציה אינה מתחברת ישירות לכתובת IP של Redis. במקום זאת, היא מתחברת ל-Sentinel, מבקשת את הכתובת הנוכחית של ה-Primary, ולאחר מכן עובדת איתו. לדוגמה, בפייתון:

from redis.sentinel import Sentinel

sentinel = Sentinel([
    ('sentinel1.internal', 26379),
    ('sentinel2.internal', 26379),
    ('sentinel3.internal', 26379)
], socket_timeout=0.5, password='your-redis-password')

master = sentinel.master_for('mymaster', socket_timeout=0.5)
replica = sentinel.slave_for('mymaster', socket_timeout=0.5)

master.set('key', 'value')
value = replica.get('key')

במהלך failover, ספריית הלקוח מעדכנת אוטומטית את כתובת ה-Primary דרך Sentinel. זמן ההשבתה עבור האפליקציה במהלך failover הוא בדרך כלל 10–30 שניות, מה שמפחית אובדן הכנסות פוטנציאלי של אלפי דולרים לכל תקרית.

בעיות נפוצות ופתרונות

Split-brain. אם ה-Primary מבודד מה-Sentinels (אך עדיין נגיש לחלק מהלקוחות), Sentinel יתחיל failover ויקדם Replica. כעת ישנם שני Primaries. הגנה: הגדר parallel-syncs 1 על ה-Primary — אם ה-Primary אינו רואה replicas מסונכרנים, הוא מסרב לכתיבות. השתמש גם ב-1.

במקרה לקוח אמיתי, התרחשה סערת רשת: ה-master היה מבודד, Sentinel קידם replica חדש, אך עקב קוורום שגוי (quorum=2 עם 3 Sentinels), ל-failover היה עיכוב של 20 שניות. לאחר הביקורת שלנו, הגדרנו quorum=2 ו-min-replicas-to-write=1, מה שמנע split-brain.

Sentinel אינו מפעיל failover בעת אתחול מחדש. אם ה-Primary קורס וחוזר תוך 5 שניות, Sentinel עדיין לא הגיב. זו התנהגות נורמלית. אך האפליקציה חייבת להיות מסוגלת לנסות שוב בקשות על redis.conf. הגדרת Sentinel נכונה משתלמת לאחר ה-failover האוטומטי הראשון, ומונעת אובדן של אלפי בקשות.

מדוע Sentinel עדיף על Keepalived עבור Redis

בניגוד ל-Keepalived, שפשוט מעביר כתובת IP וירטואלית, Sentinel מבין את מצב ה-replication של Redis. הוא לא יקדם replica שנמצא בפיגור (replication לא הושלם). זה מפחית את הסיכון לאובדן נתונים. לפי המדידות שלנו, Sentinel מספק RPO של פחות משנייה אחת, שהוא פי 10 טוב יותר מ-Keepalived, שיכול לאבד עשרות שניות של נתונים.

תהליך ולוח זמנים

התקנת Sentinel שלב אחר שלב

1. ביקורת תשתית Redis קיימת: גרסאות, טופולוגיה, עומס.
2. עיצוב טופולוגיה תוך התחשבות במיקום פיזי של צמתים.
3. פריסת שלושה Sentinels, הגדרת Primary ו-Replica עם סיסמאות.
4. בדיקת failover מאולץ דרך requirepass your-redis-password masterauth your-redis-password .
5. עדכון מחרוזות חיבור של האפליקציה לעבודה דרך Sentinel.
6. ניטור מדדי Sentinel ב-Prometheus + Grafana.

תוצרים

לוחות זמנים משוערים

מומחיות החברה

עם ניסיון של למעלה מ-10 שנים בסביבות ייצור, למעלה מ-40 פרויקטים בעומס גבוה, ו-5 שנים בשוק, אנו מביאים אמינות שאין שני לה לתשתית ה-Redis שלך. השקעה בהתקנת Redis Sentinel משתלמת בכשל הראשון, ומונעת אובדן של מיליוני בקשות ושעות של השבתה. Failover תוך 10 שניות במקום שעה של שחזור ידני — הבדל של מאות מונים. הימנע מעלויות של עד $10,000 לשעת השבתה. צור קשר להערכה חינמית של התשתית שלך. בקש ייעוץ מהנדס לקבלת הערכת עלות עבור הטופולוגיה שלך.