המלצות כלליות

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

סטטוס המכונה במסוף Cloud de Confiance לא משקף אם פעולה כלשהי פועלת. סימן הווי הירוק מציין רק שהמכונה נמצאת במצב RUNNABLE. כדי לבדוק אם פעולה מסוימת פועלת, עוברים לכרטיסייה Operations ובודקים את הסטטוס של הפעולה האחרונה.

אם ההגדרה enable automatic storage increases מושבתת במכונה, או אם ההגדרה automatic storage increase limit מופעלת, ודאו שיש לכם לפחות 20% נפח אחסון פנוי כדי לאפשר פעולות תחזוקה קריטיות של מסד הנתונים ש-Cloud SQL עשוי לבצע.

כדי לקבל התראה כשהמקום בכונן יורד מתחת ל-20%, יוצרים מדיניות התראות שמבוססת על מדדים למדד disk utilization, עם מיקום above threshold וערך של ‎.8. מידע נוסף זמין במאמר יצירת מדיניות התראות מבוססת-מדדים.

בדף הפרטים של המכונה במסוף Cloud de Confiance אפשר לראות את אחוז המעבד (CPU) הזמין שבו המכונה משתמשת. מידע נוסף זמין במאמר מדדים. אפשר גם לעקוב אחרי השימוש ב-CPU ולקבל התראות על סף מסוים באמצעות יצירת מדיניות התראות על סף מדדים.

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

כשמחפשים סימנים לניצול יתר של הזיכרון, צריך להשתמש בעיקר במדד usage. כדי למנוע שגיאות של מחסור בזיכרון, מומלץ שהמדד הזה יישאר מתחת ל-90% במכונות עם 16GB או פחות, ומתחת ל-95% במכונות עם יותר מ-16GB.

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

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

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

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

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

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

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

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

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

במכונה של Cloud SQL שיוצרים במסוף Cloud de Confiance או באמצעות Terraform, מניעת מחיקה בטעות מופעלת כברירת מחדל.

כדי להגן על הנתונים, אתם יכולים להשתמש בתכונת הייצוא ב-Cloud SQL. משתמשים ב-Cloud Scheduler עם ה-API בארכיטקטורת REST כדי להפוך את ניהול הייצוא לאוטומטי. בתרחישים מתקדמים יותר, Cloud Scheduler עם פונקציות Cloud Run לאוטומציה.