הגדרת מסדי נתונים מנוהלים Selectel Managed Databases

היכן הגדרה ידנית של קלאסטר נשברת בעומס שיא

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

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

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

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

נפרק כיצד זה נסגר במסדי נתונים מנוהלים Selectel — ולמה חלק מהכשלים המפורטים שם פשוט לא מתרחשים.

מסדי נתונים מנוהלים Selectel: מה משתנה בפועל

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

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

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

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

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

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

אפשרויות פריסה: קלאסטר ייעודי, מאגר משותף, רפליקה

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

ב-Selectel פורסים מסדי נתונים מנוהלים בכמה אפשרויות, והגבולות ביניהן עוברים לפי בידוד, פיגור רפליקות והתנהגות בעת כשל צומת.

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

שלבי יישום: מביקורת עומס ועד מסירה לתפעול

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

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

1. ביקורת עומס על מסד הנתונים. אוספים דירוג שאילתות, נעילות, זינוקים, גידול טבלאות ואינדקסים, מרווח בדיסק ובחיבורים. בפלט — פרמטרים רצויים לקלאסטר ורשימה של מה שמתקנים לפני המעבר.
2. סכימת עמידות לתקלות. קובעים טופולוגיה: צומת ראשי ורפליקה באזור זמינות אחר, מעבר אוטומטי בעת כשל, תקופות שמירת גיבויים משל עצמם ושחזור לנקודת זמן.
3. פריסת הקלאסטר. מקימים קלאסטר מנוהל Selectel Managed Databases, מגדירים תפקידים, גישות רשת, הצפנה ולוח זמנים לגיבוי — לפי הפרופיל הנמדד, ולא לפי ברירת מחדל.
4. הגירה ללא השבתה. מעבירים נתונים ברפליקציה לוגית: המינוי מדביק את מסד הנתונים הראשי, שומרים על הפיגור בשליטה, ואז מעבירים את האפליקציה — ההשבתה נכנסת לשניות ונוגעת רק לכתיבה.
5. בדיקת מעבר. מארגנים כשל תרגול: מכבים צומת ובודקים אם השחזור נכנס לזמן הרצוי, אם שלמות הנתונים נשמרה, ואם האפליקציה המשיכה לעבוד. חוזרים על כך עד שהתוצאה הופכת לניתנת לשחזור.
6. נראות. מגדירים התראות על פיגור רפליקה, מיצוי חיבורים, מקום בדיסק וגידול בזמן השאילתות, עם ספי תגובה מוגדרים במפורש.
7. מסירה לתפעול. מוסרים תיעוד על הקלאסטר ומאמנים את הצוות: כיצד להפעיל מעבר, לשחזר מגיבוי, לפעול בזמן הידרדרות. בהתחלה מנתחים תקלות יחד עם המהנדסים שלכם.

מה מוסרים לידיים: תצורות, סכימות ונוהלים

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

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

מקרה בוחן: כיצד קיצרנו את זמן השחזור לאחר כשל צומת

לפני: התאוששות מכשל צומת נעשתה ידנית

מתאר העבודה של חנות מקוונת חי על שלושה צמתי שרת, אבל את המעבר בעת כשל ביצעו ידנית. התורן נודע על הנפילה מהתראה, העלה רפליקה, תיקן את שורת החיבור בתצורת האפליקציה והפעיל מחדש את השירותים — בממוצע 40–60 דקות של אי-זמינות מסד הנתונים, שבמהלכן הזמנות לא בוצעו.

מה שינינו ומה יצא

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

השארנו ידניות רק פעולות מתוכננות — הרחבה, שינוי פרמטרים — וכל אחת מהן מתבצעת לפי נוהל עם בדיקה מוקדמת של הרפליקות.

זמן השחזור לאחר כשל צומת בקלאסטר הצטמצם ל-60–90 שניות, חלק הפעולות הידניות בשחזור ירד מכמעט מערך שלם של צעדים לכמה אישורים בודדים. הזמינות של מסד הנתונים ברבעון עלתה מ-99.3% ל-99.95%, ולא היו השבתות בגלל שגיאה במעבר.

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

מה לעשות אם מסד הנתונים כבר פרוס על שרתים משלכם?

כן, מסד נתונים פרוס מועבר ללא עצירת השירות — אבל לא בצילום מלא אחד בחלון לילה, אלא בשלבים. אנחנו מפעילים רפליקציה לוגית בין ההתקנה שלכם לקלאסטר המנוהל Selectel Managed Databases, ומשאירים את האפליקציה כותבת למסד הנתונים הרגיל. השינויים עוברים לענן כזרימה מיומן הטרנזקציות, ולכן העומס על שרת העבודה נשאר כשהיה.

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

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

המעבר מתבצע בשלבים. קודם הרפליקה מדביקה ועובדת במצב קריאה בלבד: עליה מריצים אנליטיקה ומשווים תוכניות הרצה של שאילתות כבדות.

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

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

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

ספקות טכניים נפוצים: גישות, גיבויים, השבתה

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

מסד נתונים מנוהל הוא לא «שרת שקיבלו אליו גישה», אלא אוסף של גבולות רשת, מדיניות ונראות. אנחנו מגדירים אותם לפי הסכימה שלכם ומוסרים יחד עם התיעוד, כדי שהתפעול לא יהיה תלוי במהנדס מסוים.

איך לבדוק שהגיבוי באמת ישוחזר?

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

מה קורה בזמן מעבר בעת כשל?

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

האם מתועד מי ומה שינה במסד הנתונים?

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

נדון במשימה: מה לשלוח להערכה ולתוכנית עבודה

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

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

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

נדון במשימה בנוגע למסד הנתונים — נחזור עם הערכה, תוכנית עבודה וחלוקת אחריות.