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

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

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

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

אפשר גם להשתמש במדד 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 ציבורית.
שימוש בתבניות סכימה מאובטחות כדי למנוע התקפות של חטיפת נתיב חיפוש, חשוב לוודא שלמשתמשים עם הרשאת אדמין יש נתיב חיפוש מאובטח. אנחנו ממליצים להגדיר את הפרמטר search_path לערך pg_catalog למשתמשים עם הרשאות גבוהות. שימוש בנתיב חיפוש מאובטח
הגדרת log_statement לערך none הדגל log_statement הוא none כברירת מחדל. אם הוא לא מוגדר לערך none, יכול להיות ש-PostgreSQL יתעד הצהרות שמכילות סיסמאות. מומלץ להשתמש ב-pgAudit לביקורת של מסד הנתונים במקום ב-log_statement.

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

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

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

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

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

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

גיבוי ושחזור

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

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

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

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

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

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

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

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

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