שיטות מומלצות

בדף הזה מפורטות שיטות מומלצות להשגת הביצועים, העמידות והזמינות הכי טובים ב-Cloud SQL.

אם מתרחשות בעיות במכונה של Cloud SQL, כדאי לבדוק את הדברים הבאים במהלך פתרון הבעיות:

הגדרה וניהול של מופע

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

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

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

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

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

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

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

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

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

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

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

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

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

אבטחה

שיטה מומלצת מידע נוסף
העדפה של כתובת IP פרטית אלא אם נדרשת גישה באמצעות כתובת IP ציבורית, מומלץ להשתמש בכתובת IP פרטית. כך תוכלו לצמצם את הסיכוי לחיבורים לא מורשים לרשת למסד הנתונים.
איך להימנע משימוש ב-0.0.0.0/0 ברשתות מורשות לא מומלץ לכלול את 0.0.0.0/0 ברשתות מורשות, כי זה מאפשר גישה מהאינטרנט הגלובלי ללא הגבלה.
מומלץ להימנע מרשתות מורשות גדולות מדי מומלץ להימנע משימוש בקידומות CIDR קטנות ברשתות מורשות, כי זה מאפשר גישה ממספר רב מדי של מארחים. מומלץ להשתמש בקידומת CIDR בגודל ‎ /16 לפחות, ועדיף בגודל ‎ /19 ומעלה.
הפעלת מדיניות לסיסמאות כדי למנוע הגדרה של סיסמאות חלשות, להגדיר זמן תפוגה ולהגדיר נעילת חשבון במקרה של ניסיונות התחברות שנכשלו, צריך להשתמש במדיניות סיסמאות של מופע MySQL או PostgreSQL כדי לציין מדיניות סיסמאות מתאימה למופע מסד הנתונים. זה חשוב במיוחד אם אתם מגדירים את המופע לכתובת IP ציבורית.

ארכיטקטורת נתונים

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

הטמעת האפליקציה

שיטה מומלצת מידע נוסף
להשתמש בשיטות טובות לניהול חיבורים, כמו איגום חיבורים (connection pooling) והשהיה מעריכית לפני ניסיון חוזר (exponential backoff). השימוש בטכניקות האלה משפר את השימוש במשאבים באפליקציה ועוזר לכם להישאר במסגרת מגבלות החיבור של Cloud SQL. למידע נוסף ולדוגמאות קוד, אפשר לעיין במאמר בנושא ניהול חיבורים למסדי נתונים.
בודקים את התגובה של האפליקציה לעדכוני תחזוקה, שיכולים להתבצע בכל שלב במהלך חלון הזמן לתחזוקה. אפשר לנסות תחזוקה בשירות עצמי כדי לדמות עדכון תחזוקה. במהלך התחזוקה, המופע שלכם לא יהיה זמין לפרק זמן קצר, והחיבורים הקיימים ינותקו. בדיקה של השקות תחזוקה מאפשרת לכם להבין טוב יותר איך האפליקציה מטפלת בתחזוקה מתוזמנת וכמה מהר המערכת יכולה להתאושש.
בודקים את התגובה של האפליקציה למעבר לגיבוי, שיכול לקרות בכל שלב. אפשר להפעיל מעבר לגיבוי ידני באמצעות המסוף Google Cloud ,‏ ה-CLI של gcloud או ה-API. מידע נוסף מופיע במאמר בנושא התחלת מעבר לגיבוי בשעת כשל.
מומלץ להימנע מעסקאות גדולות. העסקאות צריכות להיות קטנות וקצרות. אם צריך לעדכן מסד נתונים גדול, עדיף לבצע את העדכון בכמה עסקאות קטנות ולא בעסקה גדולה אחת.
אם אתם משתמשים בשרת proxy ל-Cloud SQL Auth, ודאו שאתם משתמשים בגרסה העדכנית ביותר. איך מעדכנים את שרת ה-Proxy ל-Cloud SQL Auth

ייבוא וייצוא של נתונים

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

גיבוי ושחזור

שיטה מומלצת מידע נוסף
הגנה על הנתונים באמצעות הפונקציונליות המתאימה של Cloud SQL.

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

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

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

הגנה על המופע ועל הגיבויים מפני מחיקה בטעות.

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

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

המאמרים הבאים

למידע נוסף על שיטות כלליות לפי המנוע של מסד הנתונים, אפשר לעיין במאמרים הבאים: