Redis או Valkey: אותו פרוטוקול לא מבטיח קובץ גיבוי תואם

Valkey היא אפשרות מעשית ליישום שמשתמש בעיקר בפקודות הבסיסיות של Redis, אבל חיבור מוצלח של הלקוח אינו מוכיח שאפשר לשחזר בו גיבוי. מדריך ההגירה של Valkey קובע שקובצי RDB ו־AOF של Redis OSS עד גרסה 7.2 תואמים, ואילו קובצי נתונים שנוצרו ב־Redis Community Edition מגרסה 7.4 אינם תואמים לטעינה ישירה.

ההחלטה אם להישאר עם Redis או לעבור ל־Valkey מתחילה בגרסת המקור ובמה שהיישום עושה בפועל. פרוטוקול RESP משותף מאפשר ללקוחות רבים להמשיך להתחבר, אך אינו פותר תלות בפקודות שהתפתחו אחרי הפיצול, במודול מסוים או בפורמט ההתמדה. אם קיימת תלות כזאת, צריך לבחור מסלול להעברת הנתונים ולתכנן גם כיצד חוזרים למקור במקרה של כשל.

גרסת המקור קובעת את מסלול הנתונים

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

כאשר קובץ המקור נמצא בטווח התואם, אפשר לנסות טעינה של snapshot עדכני בסביבת Valkey מבודדת. לפני העברה לייצור צריך להביא בחשבון כתיבות שמתרחשות בזמן יצירת העותק, זמן טעינת הנתונים והגדרות ההתמדה ביעד. אם AOF מופעל ביעד, למשל, מדריך ההגירה מנחה לכבות אותו בהפעלה הראשונה של Valkey בעת ייבוא RDB מועתק, כדי שהשרת אכן יטען את ה־snapshot.

כאשר קובץ המקור נוצר בענף המאוחר שאינו תואם, העתקתו לשרת החדש אינה מסלול הגירה. העתקה לוגית באמצעות קריאת ערכים וכתיבתם מחדש, או כתיבה כפולה ברמת היישום לתקופת מעבר, הן אפשרויות שיש לתכנן ולבדוק לפי טיפוסי הנתונים והיקף הכתיבות. גם פקודה שמעבירה מפתח בין שרתים אינה תחליף אוטומטי לבדיקה: יש לוודא שהייצוג שהיא שולחת מתקבל בגרסת היעד.

יש גם פרט שעלול להטעות בזיהוי השרת. מטעמי תאימות Valkey עשויה להציג בשדה redis_version של INFO את הערך 7.2.4; השדות server_name ו־valkey_version מזהים את המנוע ואת גרסתו. בשירות מנוהל כדאי להשוות את הפלט גם לגרסה ולמנוע שהוגדרו במוצר הענן, לפני שבוחרים דרך שחזור.

רישוי, פקודות ומודולים משנים את ההחלטה

השוואת Redis מציגה את Valkey ברישיון BSD 3-Clause ואת Redis 8 עם בחירה בין AGPLv3, RSALv2 ו־SSPLv1. זהו שיקול נפרד מתאימות נתונים: רישיון מתירני עשוי להיות סיבה לבחור ב־Valkey, אך הוא אינו מקצר העברה של יישום שתלוי ביכולות ייחודיות ל־Redis. מי שמפעיל שירות מסחרי או משנה את קוד השרת צריך לבחון את תנאי הרישיון שיחולו על צורת השימוש שלו.

בצד היישום, הכינו רשימה של הפקודות שהקוד, סקריפטים ופעולות התחזוקה שולחים בפועל. בדיקת SET ו־GET בלבד לא תגלה שימוש בפקודות חיפוש, בתפוגה של שדות או בפעולות שנוספו לאחר הפיצול. Redis משלבת בהפצה שלה JSON, סדרות זמן וחיפוש; Valkey מציעה יכולות מסוימות, ובהן JSON וחיפוש, דרך מודולים. לכן שם דומה של יכולת אינו מספיק: בדקו את הפקודה, טיפוס הנתון, תגובת השרת וההתנהגות במקרה של שגיאה.

אותה בדיקה דרושה למודול שכבר מותקן במקור. Valkey מכירה בממשק RedisModule_ של מודולים שנכתבו עבור Redis OSS, אך מכאן אי אפשר להסיק שכל מהדורה של מודול, כל פקודה שלו וכל נתון ששמר יפעלו ביעד המסוים. רשמו את גרסאות המודולים, טענו נתוני בדיקה בגרסת היעד והריצו מולם את פעולות היישום. תלות מהותית שאין לה מענה ב־Valkey יכולה להפוך את ההישארות ב־Redis לבחירה המעשית יותר.

בשירות ענן בוחרים מוצר, לא רק מנוע

שירות מנוהל מוסיף תנאים משלו למנוע שמפעיל אותו. לפני מעבר בררו איזו גרסה זמינה במסלול הרצוי, האם הספק מאפשר את המודולים והפקודות הדרושים, ואילו דרכי ייבוא, גיבוי ושחזור הוא מציע. שירות שמקבל את פקודות היישום עשוי עדיין לדרוש דרך אחרת להכנסת הנתונים הקיימים; גם כתובת חיבור תואמת אינה מבטיחה שאפשר להעלות אליה קובץ גיבוי.

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

מעבר בטוח צריך גם מסלול חזרה

למקור עם קובץ תואם, שחזרו תחילה עותק בסביבה מבודדת והשוו את מספר המפתחות, הערכים וזמני התפוגה לצפוי. אחר כך הריצו את בדיקות היישום מול היעד, וקבעו כיצד עוצרים כתיבות, יוצרים עותק אחרון ומחליפים תעבורה. אם בוחרים בשכפול כדי לצמצם השבתה, בדקו את מצב הסנכרון לפני שקובעים ש־Valkey הוא יעד הכתיבה.

למקור שאינו יכול למסור קובץ תואם דרושה בדיקת ערכים לאחר העברה לוגית, ולא רק ספירת מפתחות. בכתיבה כפולה הגדירו איזה צד הוא מקור האמת, מה קורה כשכתיבה מצליחה רק בצד אחד ואיך מאתרים פערים. שמרו עותק נתונים תקין ותוכנית להפניית היישום חזרה לפני החלפת החיבור; כתיבות שבוצעו רק ביעד החדש לא יופיעו מעצמן במקור הישן.

רשימת ההחלטה קצרה אך מחייבת תשובה לכל רכיב: גרסת המקור ופורמט ההתמדה, פקודות שנוספו לאחר בסיס הקוד המשותף, מודולים וטיפוסי נתונים, יכולות שירות הענן ותהליך חזרה אחרי כתיבות חדשות. אם רכיב מרכזי אינו עובר בדיקה בסביבת היעד המדויקת, חיבור מוצלח של הלקוח עדיין אינו אישור להעברת המערכת.

ביצועים מודדים עם פקודות ונתונים מייצגים

השוואת ביצועים מתחילה באותו תמהיל פקודות ובתנאים דומים בשני היעדים. תיעוד valkey-benchmark מפרט בחירה של פקודות, מספר חיבורים, עומק pipelining, גודל ערך ומרחב מפתחות. השאירו גם את חומרת השרת, הרשת והגדרות ההתמדה דומות ככל האפשר; אחרת ההבדל הנמדד עשוי לנבוע מסביבת הבדיקה ולא מהמנוע.

פקודת פתיחה לדוגמה בסביבת בדיקה היא valkey-benchmark -h 127.0.0.1 -p 6379 -t set,get -n 200000 -c 40 -P 4 -r 10000 -d 1024 --csv. הערכים כאן מותנים: החליפו אותם בגודל הערכים, במספר החיבורים, בעומק ה־pipeline ובמרחב המפתחות של היישום שלכם. SET ו־GET נבדקות כאן כבדיקות נפרדות, לא כתמהיל קריאה וכתיבה; כדי לפרש את תוצאת הקריאה יש להכין מראש נתונים מתאימים ולבדוק גם החטאות.

כאשר העבודה האמיתית אינה מורכבת רק מ־SET ו־GET, אפשר למדוד גם פקודה מותאמת, למשל valkey-benchmark -h 127.0.0.1 -p 6379 -n 200000 -c 40 -P 4 -r 10000 -d 1024 SET item:__rand_int__ __data__. הריצו את אותן פקודות מול שני היעדים והשוו קצב, זמני תגובה ושגיאות תחת עומס דומה. הבדיקה מספקת נתון על הפקודות שנמדדו; התנהגות היישום המלא, ובייחוד שימוש במודולים ובגיבויים, עדיין דורשת בדיקה נפרדת.

קראו גם:

• ייצוא Slack אינו גיבוי מלא: הקבצים נשארים מאחורי קישורים
• הסתרתם מיקום ב־Google Photos? הקובץ שהורדתם עדיין עלול לחשוף אותו
• Ragas או DeepEval: אותו ציון אמינות לא מודד את אותו הכשל