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

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

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

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

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

אי אפשר לשלוח בקשות חדשות לפעולות במופעי 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, צריך לפצל את מסד הנתונים לכמה מופעים.
למנוע מצב של חוסר זיכרון.

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

אפשר גם להשתמש במדד 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 ומעלה.
הפעלת מדיניות לסיסמאות שימוש במדיניות סיסמאות של מופעים, הגדרת מדיניות סיסמאות מתאימה למופע מסד הנתונים כדי למנוע הגדרה של סיסמאות חלשות, הגדרת זמן תפוגה והגדרת נעילת חשבון במקרה של ניסיונות כניסה שנכשלו. זה חשוב במיוחד אם אתם מגדירים את המופע לכתובת IP ציבורית.

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

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

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

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

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

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

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

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

גיבוי ושחזור

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

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

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

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

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

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

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

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