הגדרת Cloud SQL: היכן שהפרודקשן מתפרק
לאחר ההשקה, Cloud SQL נראית כמו מסד נתונים בריא: ערכי ברירת המחדל מתמודדים עם התעבורה, הגרפים יציבים, אין התראות. אבל הם מיועדים לפיתוח ולזרימה קטנה, ולא לפרודקשן — עם פרופיל עומס אמיתי הם מתפרקים בדיוק כשכבר מאוחר מדי לבנות מחדש.
נקודת הכשל הראשונה — מיצוי החיבורים. האפליקציה פותחת חיבור עבור כל בקשה, מספר העותקים שלה בשיא גדל, ומסד הנתונים מפסיק לקבל סשנים חדשים: הבקשות נכנסות לתור, זמן התגובה עולה, וחלק מהקריאות נופלות עם שגיאה. מאגר חיבורים ומגבלה מפורשת בצד האפליקציה פותרים את הבעיה — אבל רק אם הוגדרו מראש.
הידרדרות בעומס שיא בנויה בעדינות רבה יותר. סטטיסטיקה מיושנת או תוכנית ביצוע שהשתנתה מובילות את השאילתה לקרוא את כל הטבלה, רוחב הפס של הדיסק מפסיק להספיק, והתור גדל כבר ברמת הקלט/פלט. אינדקסים, איסוף סטטיסטיקה סדיר והוצאת הקריאה לרפליקה שומרים על זמן תגובה צפוי.
תרחיש נפרד — כשל בעת מיתוג הרפליקה. המופע עובר לאזור אחר, האפליקציה ממשיכה להחזיק חיבורים מתים במאגר, וחזרות על בקשות יוצרות סערה על הצומת שזה עתה עלה. בלי פסקי זמן נכונים ולוגיקת התחברות מחדש, המיתוג הופך להשבתה מורגשת.
כל אחד מהכשלים האלה צפוי מראש ונסגר בשלב ההגדרה של מסד הנתונים המנוהל. להלן — מה בדיוק אנחנו בודקים ומגדירים לשם כך.
מה נותן מסד נתונים מנוהל בפרודקשן בעת גידול בעומס
מסד נתונים מנוהל ללא הגדרה מחזיק את הפרודקשן רק עד הגידול הרציני הראשון בעומס. המופע חי באזור אחד, בעת כשל של המארח מסד הנתונים עולה ידנית, ומשך ההשבתה של השירות נמדד בשעות, ולא בשניות של זמן תגובה.
עמידות בפני כשלים של מסד הנתונים היא לא סימון תיבה בפאנל, אלא רפליקה סינכרונית באזור אחר, מיתוג אוטומטי ופרוקסי חיבורים לפני המופע.
Cloud SQL בהגדרה נכונה נותנת זמן התאוששות לאחר כשל בגבולות מיתוג אחד: האפליקציה שורדת אותו בהתחברות מחדש של מאגר החיבורים, בלי פעולות ידניות של התורן ובלי אובדן טרנזקציות מאושרות.
גיבוי מסד הנתונים סוגר את המחצית השנייה של הסיכונים: צילומים אוטומטיים יחד עם יומן השינויים מאפשרים לחזור לדקה שלפני עדכון שגוי, ולא לגיבוי הלילי האחרון. השחזור נבדק באופן סדיר על מופע נפרד — גיבוי שלא נבדק אינו נחשב לנקודת שחזור.
האפקט השלישי — מהירות הרכבת סביבות: שיבוט של מופע הפרודקשן נותן סביבת בדיקה תוך דקות, ולכן מיגרציות סכימה ואינדקסים חדשים נבדקים על נפחי נתונים אמיתיים לפני העלייה לאוויר.
בסך הכל משתנה לא מדד בודד, אלא מחלקה שלמה של כשלים: נעלמים העלאה ידנית של מסד הנתונים, אובדן נתונים בעת כשל דיסק ושחזור חירום מגיבוי.
אפשרויות פריסה של מסד הנתונים: השוואת מצבים
מצב הפריסה נבחר לפי פרופיל העומס, ולא לפי הרגל. כל עוד מדובר בטרנזקציות קצרות עם מספר חיבורים צפוי, מסד נתונים מנוהל בענן (Cloud SQL) מסיר מהצוות את הגיבוי, העמידות בפני כשלים והעדכונים.
ברגע שמופיעה לצידו מערכת דיווחים, אותו מופע מחלק את מטמון הבאפר ואת קלט/פלט הדיסק בין האנליטיקה לפרודקשן — וזמן התגובה של שניהם יורד.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מסד נתונים טרנזקציוני מנוהל | טרנזקציות קצרות, פרופיל שאילתות יציב, נדרש מעבר אוטומטי לרפליקה | אין גישה למשתמש-על ולמערכת הקבצים, חלק מההרחבות אינן זמינות, התחזוקה מתבצעת לפי לוח הזמנים של הספק, האנליטיקה מתחרה בטרנזקציות על זיכרון וקלט/פלט דיסק |
| מנוע אנליטי לצד הטרנזקציוני | הדיווחים והאגרגציות קוראים את אותם נתונים כמו הפרודקשן, אך לא אמורים להאט אותו | מופע נפרד עם ניטור ועדכונים משלו, השהיית רפליקציה, חלק מהשאילתות דורשות כתיבה מחדש להתאמה לביצוע קולונרי |
| מכונה משלנו עם מערכת ניהול מסד נתונים | נדרשות הרחבות לא סטנדרטיות, כיוונון עדין של הליבה, שליטה מלאה בגרסה ובתוכניות השאילתות | גיבוי, עמידות בפני כשלים, פאצ'ים ושחזור — כולם בצד שלנו; טעות בהגדרה עולה בהשבתת הפרודקשן |
לרוב משאירים את הליבה הטרנזקציונית על מסד נתונים מנוהל, את הדיווחים מוציאים למנוע אנליטי, ומכונה משלנו נלקחת רק כאשר הדרישות להרחבות ולכיוונון הליבה עולות על עלות התחזוקה. המעבר חזרה קשה יותר: תפקידים, הרשאות וחלק מהשאילתות יהיה צורך לכתוב מחדש.
סדר ההגדרה של מסד נתונים מנוהל תחת עומס
העומס על מסד נתונים מנוהל גדל בצורה לא אחידה: תחילה נתקל במספר החיבורים, אחר כך בפעולות הדיסק, ואחר כך בתוכנית השאילתות שמפסיקה להתאים להתפלגות הנתונים האמיתית. תצורה שנבנתה כברירת מחדל ונבדקה על תעבורת בדיקה מחזיקה מעמד עד השיא הראשון. לכן סדר העבודה קבוע — מאיסוף העובדות ועד לנהלי התפעול.
- אודיט של תצורת מסד הנתונים: אוספים את הפרמטרים של המופע, את סטטיסטיקת המתכנן, ואת השאילתות המובילות לפי זמן מצטבר ולפי קריאה מהדיסק. בפלט — רשימת צווארי בקבוק עם הערכה מה ייתן את התוצאה הגדולה ביותר בשיא הקרוב.
- תרשים הרפליקציה: קובעים אילו קריאות עוברות לרפליקה, איזה מרווח השהיה מותר לדיווחים, ואיזה מצב סינכרוניות נדרש לטרנזקציות קריטיות. בנפרד מתעדים את ההתנהגות בעת אובדן צומת.
- הגדרת המופע והתפקידים: מטמון עבור מערך הנתונים העובד, ספי ניקוי אוטומטי, מגבלות חיבורים ומאגר חיבורים לפני מסד הנתונים. מפרידים בין הגישה של האפליקציה, של האנליטיקה ושל המנהל.
- גיבויים ושחזור: חלון הגיבוי, עומק השמירה, נקודת שחזור לנקודת זמן. את השחזור בודקים על עותק, ולא לפי עצם קיומם של גיבויים.
- בדיקת עומס: הרצה עם פרופיל שחוזר על זה של הפרודקשן ביחס שבין קריאות לכתיבות, בנפרד שיא והידרדרות איטית. אוספים את זמן התגובה ואת שיעור הבקשות שמחוץ לזמן היעד.
- העברת מסד הנתונים לתפעול: מדדים והתראות, נהל לשינוי פרמטרים, סדר החזרה לתצורה ולגיבוי הקודמים. האחראי מטעם הלקוח מקבל מסמך, ולא סיכומים בעל פה.
כל שלב מסתיים בארטיפקט שאפשר לבדוק: דוח, תרשים או פרוטוקול הרצה. זה מאפשר לשנות את התצורה בהמשך בלעדינו ולא לאבד את ההיגיון של ההחלטות שהתקבלו.
ארטיפקטים של הפרויקט: תרשימים, מדיניות גישה, נהלים
הפרויקט נסגר לא בדוח, אלא בסט של ארטיפקטים שלפיהם אפשר לפתח ולתחזק את מסד הנתונים בלעדינו. הכול נשמר במאגר של הלקוח: התצורה מתוארת באופן דקלרטיבי, השינויים עוברים בדיקה לפני יישום, היסטוריית העריכות והשיוך נשמרים. להלן — מה בדיוק נשאר בידי הצוות שלכם.
- תרשים תשתית מסד הנתונים — מופעים, רפליקות, מקטעי רשת, אזורי פריסה ונקודות החיבור של השירותים. ממנו רואים מה ייכשל בעת אובדן אזור ולאן יעבור התעבורה.
- מדיניות גישה ותפקידים — הפרדה בין בעלים, מנהל, מפתח וחשבונות שירות. האפליקציות פונות תחת משתמשים נפרדים עם הרשאות מינימליות, וגישה ישירה של אדם לפרודקשן חסומה ומתועדת בלוג.
- נהל גיבוי — לוח זמנים של צילומים, עומק שמירה, ובדיקת שחזור מחייבת בסביבה נפרדת. מתועד מי ובאיזה פרק זמן מעלה את מסד הנתונים בעת אובדן נתונים.
- תיעוד מסד הנתונים — פרמטרים של המופע, גרסת המנוע, ההרחבות המחוברות, מגבלות חיבורים, וסדר יישום המיגרציות.
- הוראות לפעולות שגרתיות — הרחבת האחסון, החלפת מחלקה של המופע, מיתוג מתוכנן לרפליקה, הוספת אינדקס לטבלה גדולה בלי לחסום כתיבה.
- ניטור והתראות — גרפים של השהיית שאילתות, מספר החיבורים והמקום הפנוי, ספי הפעלה וסדר הטיפול באירוע.
יכולת הבדיקה היא התכונה העיקרית של סט כזה: המהנדסים שלכם פורסים את התצורה מאפס ומשווים את התוצאה למצב המתואר, בלי לפנות אלינו להסברים.
מקרה בוחן: זמן השחזור של מסד הנתונים קוצר פי שלושה
מצב התחלתי: פרודקשן על Cloud SQL עם כתיבה אינטנסיבית — הזמנות, סטטוסי משלוח, היסטוריית תשלומים. כל החיבורים, כולל הדיווחים וההתאמה הלילית, עברו למסד הנתונים הראשי: כ-400 סשנים במקביל, autovacuum לא הספיק לעמוד בקצב עדכון הטבלאות החמות, והגיבוי נלקח במלואו לפי לוח זמנים.
השחזור לאחר כשל ארך עד 75 דקות: להעלות את הגיבוי, להשלים ידנית חלק מהטרנזקציות ולבדוק פערים — לכך הוקדשו כ-12 שעות עבודה של מהנדס תורן בחודש.
מה שינינו
הפרדנו את הסביבות: קריאות חמות ואנליטיקה עברו לרפליקות דרך מאגר חיבורים נפרד, והכתיבה נשארה על המופע הראשי. הפעלנו יומן רציף ושחזור לנקודת זמן עם חלון שמירה של 30 יום — החזרה הפסיקה להיות תלויה בלוח הזמנים של הגיבויים.
היסטוריית ההזמנות והתשלומים הועברה ל-AlloyDB, תוך השארת הליבה הטרנזקציונית ב-Cloud SQL, והמיתוג בעת כשל אוטומט לפי בדיקת בריאות.
מה היה לתוצאה
זמן השחזור קוצר מ-75 ל-25 דקות: המהנדס בוחר נקודה לפני הכשל, מסד הנתונים עולה לפי היומן, ואין צורך בהשלמה ידנית. שיעור האירועים עם השבתה מלאה של הפרודקשן ירד פי כמה — ירידות בקריאה מכובות כעת על ידי מיתוג לרפליקה.
עלויות העבודה של המשמרת על עבודות שחזור פחתו מ-12 שעות ל-1.5 בחודש, והדיווחים הפסיקו להשפיע על זמן התגובה של מסד הנתונים הראשי.
מה לעשות אם מסד הנתונים כבר פרוס על מכונה משלנו?
אין צורך להעביר מסד נתונים שכבר עובד לשירות מנוהל דרך ייצוא והשבתה. התרשים העובד — להעלות את מסד הנתונים היעד לצד הנוכחי ולהפעיל רפליקציה רציפה של שינויים, תוך השארת השרת המקורי כראשי: האפליקציה ממשיכה לעבוד על התשתית שלה ואינה מבחינה בהכנות. זו בדיוק מיגרציה הדרגתית, שבה המיתוג הוא שלב נפרד וקצר, ולא תחילת העבודה.
בזמן שהסנכרון מתבצע, בצד המנוהל נפרסת העתקה מלאה, ואנחנו עוקבים אחרי השהיית יישום השינויים. בנפרד מריצים השוואת סכומי ביקורת לפי טבלאות, כדי שפערים יצופו לפני המיתוג ולא בפרודקשן, וסביבת הבדיקה של האפליקציה עובדת על מסד הנתונים החדש תחת פרופיל עומס אמיתי.
לקראת מיתוג התעבורה מפחיתים מראש את זמן החיים (TTL) של רשומות ה-DNS, כדי שהכתובות הישנות יפסיקו להישמר במטמון.
את המיתוג עצמו מבצעים בחלון של עומס נמוך: עוצרים את הכתיבה למסד הנתונים המקורי, ממתינים להשהיית רפליקציה אפסית, מעבירים את האפליקציה לכתובת החדשה, ורק לאחר מכן פותחים את הכתיבה כבר על מסד הנתונים המנוהל.
תוכנית החזרה לאחור מוכנה מראש, ולא תוך כדי: בזמן התצפית, הרפליקציה פועלת בכיוון ההפוך, ולכן החזרה אורכת דקות. טריגרים לחזרה הם מדידים — שיעור שגיאות, השהיית יישום מעל הסף, סטייה של זמן תגובת השאילתות מרמת הבסיס. את השרת המקורי איננו מכבים: הוא נשאר נקודת חזרה מוכנה.
משך המעבר נקבע לא לפי גודל מסד הנתונים, אלא לפי הזמן שלוקחת השוואת הנתונים וכמה מהר מתאפסת השהיית הרפליקציה תחת שיא. תארו את התצורה הנוכחית ואת חלון אי-הזמינות המותר לכתיבה — נחזור עם סדר העבודה.
שאלות טכניות נפוצות על מסדים מנוהלים
ההתלבטויות לגבי מסדים מנוהלים רק לעיתים נדירות נוגעות ליכולות — לרוב מדובר בערבויות: מה יקרה בעת כשל אזור, כמה ייארך עדכון, כיצד לבדוק שחזור וכמה קשה לעבור לספק אחר. להלן — תשובות קצרות לכל תרחיש.
מה יקרה בעת כשל אזור?
את המופע פורסים בתצורה אזורית: רפליקה סינכרונית יושבת באזור אחר ומקבלת את תפקיד הראשי באופן אוטומטי. האפליקציה שורדת את המיתוג דרך מאגר החיבורים — חזרות על בקשות מוגדרות, ולכן המשתמש רואה השהיה קצרה, ולא שגיאה.
כיצד מתבצעים עדכונים בלי השבתה?
את הפאצ'ים מתקינים בחלון מוסכם ועל רפליקה אחת בכל פעם: בזמן שאחת מתעדכנת, הקריאה עוברת דרך האחרות, ואז ממיתוגים את הראשית. לפני החלון ואחריו אוספים מדדי השהיה — בעת הידרדרות חוזרים לגרסה הקודמת.
כיצד ניתן לוודא שהגיבוי תקין?
משחזרים את הגיבוי למופע נפרד לפי לוח זמנים ומשווים את מספר הרשומות וסכומי הביקורת. בנפרד בודקים שחזור לנקודת זמן שרירותית — בלי חזרה כזו, הגיבוי קיים רק פורמלית.
עד כמה גדולה התלות בספק הענן?
את התרשים שומרים על ניידות: SQL סטנדרטי, מיגרציות במאגר, ייצוא בפורמטים פתוחים. את המעבר לסביבה אחרת מבצעים ברפליקציה לוגית — המקור ממשיך לשרת בקשות, ואת התעבורה ממיתוגים לאחר השוואת הנתונים.
נדון במשימה ונחזור עם הערכה ותוכנית
הערכה ותוכנית עבודה מתקבלות מדויקות כשיש עובדות, ולא ניסוחים כלליים. כדי לדון במשימה באופן ענייני, די בתיאור קצר — את הפרטים נבהיר בשיחה, בלי שאלון של עשרים סעיפים.
- אילו שירותים עובדים עם מסד הנתונים ואיזה עומס הוא צריך לשאת: שאילתות שיא, נפח הנתונים, הגידול הצפוי;
- התרשים הנוכחי: היכן מסד הנתונים פרוס, כיצד בנויים הרפליקציה, הגיבוי והעמידות בפני כשלים;
- דרישות לזמינות ולחלונות תחזוקה — מה מותר לעצור ומה לא;
- מגבלות הסביבה: כללי רשת, נהלים, מי מאשר שינויים בסביבת הייצור;
- נקודות הכאב הידועות — שאילתות איטיות, מיגרציות כבדות, אירועים בחודשים האחרונים.
זה מספיק כדי להתכונן לתחילת הפרויקט. בתגובה נחזור לא עם הערכה «בעין», אלא עם חבילה: תרשים של הארכיטקטורה היעד עם רפליקות, מאגר חיבורים והיקפים רשתיים; תוכנית עבודה לפי שלבים עם תלויות; הרכב הצוות ולוחות זמנים; רשימה של מה שיידרש מצדכם — הרשאות, תפקידים, סביבת בדיקה, חלון למיתוג.
אחר כך — שיחה של 30–40 דקות: עוברים על התרשים, סדר השלבים והסיכונים. תארו את המשימה בשני-שלושה פסקאות, ונחזור עם הערכה ותוכנית.