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

בדף הזה מפורטות שיטות מומלצות להשגת הביצועים, העמידות והזמינות הכי טובים ב-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%.

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

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

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

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

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

כדי לראות את השימוש במזהה העסקה במופע שלכם, מגדירים את Resource Type כ-Cloud SQL Database ואת Metric כ-Percentage of instance's transaction IDs consumed בדף Metrics Explorer במסוף Google Cloud . מידע נוסף זמין במאמר יצירת תרשימים באמצעות Metrics Explorer.

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

אבטחה

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

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

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

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

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

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

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

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

גיבוי ושחזור

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

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

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

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

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

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

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

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

כוונון ומעקב

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

לפעולה VACUUM יש וריאציות שונות עם רמות שונות של נעילה: VACUUM סטנדרטי ו-VACUUM FULL. האפשרות VACUUM FULL יכולה לפנות יותר מקום בדיסק, אבל היא נועלת את הטבלה באופן בלעדי ופועלת לאט. במקום זאת, צריך להשתמש בטופס הרגיל של VACUUM, שיכול לפעול במקביל לפעולות במסד הנתונים של הייצור. כשמשתמשים בפעולה VACUUM, פקודות כמו SELECT, INSERT, UPDATE, and DELETE ימשיכו לפעול כרגיל. לא תוכלו לשנות את ההגדרה של טבלה באמצעות פקודות כמו ALTER TABLE בזמן שהיא עוברת דחיסה.

ריכזנו כאן כמה המלצות שיעזרו לכם לקצר את הזמן שנדרש להשלמת הפעולה VACUUM:

  • להגדיל את זיכרון המערכת ואת maintenance_work_mem. הפעולה הזו מאגדת יותר טאפלים בכל איטרציה ומסיימת את העבודה כמה שיותר מהר. שימו לב שכאשר מופעלת הפונקציה autovacuum, יכול להיות שיוקצו עד autovacuum_max_workers פעמים יותר זיכרון, לכן חשוב לא להגדיר את ערך ברירת המחדל גבוה מדי.
  • הפעולה VACUUM יוצרת הרבה רשומות של יומן WAL (יומן כתיבה מראש). אם אפשר לצמצם את מספר הרשומות ב-WAL, למשל אם לא מוגדרים עותקים משוכפלים למופע הזה, הפעולה תושלם מהר יותר.
  • אם הטבלה הגיעה למגבלה של שני מיליארד מזהי טרנזקציות כי אף אחד מהטופלים לא קפוא, כדאי לנסות לצמצם את כמות העבודה שמתבצעת במצב של משתמש יחיד. אפשרות אחת היא להגדיר את הערך של vacuum_freeze_min_age=1,000,000,000 (הערך המקסימלי המותר, במקום ברירת המחדל של 50,000,000). הערך החדש הזה מצמצם את מספר הטופלים הקפואים עד פי שניים.
  • ב-PostgreSQL מגרסה 12.0 ואילך יש תמיכה בניקוי נתונים ובפעולות VACUUM בלי לנקות את רשומות האינדקס. זהו שלב קריטי, כי כדי לנקות את האינדקס צריך לבצע סריקה מלאה של האינדקס, ואם יש כמה אינדקסים, משך הזמן הכולל תלוי בגודל האינדקס.
  • אינדקסים גדולים צורכים כמות משמעותית של זמן לסריקת האינדקס, לכן עדיף להשתמש ב-INDEX_CLEANUP OFF כדי לנקות במהירות ולהקפיא את נתוני הטבלה. בגרסאות PostgreSQL לפני 12.0, צריך לשנות את מספר האינדקסים. כלומר, אם יש אינדקסים לא קריטיים, יכול להיות שכדאי להסיר את האינדקס NON-CRITICAL כדי להאיץ את פעולת הניקוי.